BIMI prerequisites for administrators: DMARC enforcement, DNS requirements, provider support, and logo readiness

If you are planning a BIMI rollout, the main mistake to avoid is treating it like a logo-upload project.

BIMI is really the last layer in a chain that starts with stable email authentication, moves through DNS and HTTPS hosting, and only then reaches logo display. If any earlier piece is weak, the logo usually does not show up no matter how polished the brand asset is.

If you need the broader background first, start with What is BIMI, how does it work, and what problem does it solve? and How BIMI relates to DMARC.

The short version

Before BIMI is realistic, an administrator usually needs all of this to be true:

1. the domain is already at DMARC enforcement, not p=none
2. production mail is passing DMARC consistently through aligned SPF and/or aligned DKIM
3. DNS can publish a valid BIMI TXT record at the correct name
4. HTTPS-hosted BIMI resources are reachable and valid
5. the logo is in a BIMI-acceptable SVG format
6. the brand is ready for the certificate and provider requirements that apply in the real world

1. DMARC enforcement is the non-negotiable prerequisite

The biggest gate is DMARC policy.

The BIMI Group implementation guide says the domain must be at enforcement, which means p=quarantine or p=reject, and pct cannot be below 100. The current BIMI Internet-Draft says the same thing in standards language: participating domains need a strong DMARC policy on the organizational domain and the visible From: domain, and quarantine cannot be partial.

That has two practical consequences for administrators.

p=none is not enough

If your DMARC record is still only in monitoring mode, BIMI is generally not ready.

The reason is straightforward: mailbox providers do not want to attach visible brand identity to mail unless the domain is already treating unauthenticated or misaligned use seriously.

Alignment has to work in production, not just in theory

It is not enough to publish SPF, DKIM, and DMARC records and call the job done.

BIMI depends on actual DMARC success across the mail streams that matter. That means checking whether:

• third-party platforms sign with your domain or an aligned subdomain
• bounce domains align when SPF is the path that passes
• important subdomains inherit or publish appropriate DMARC policy
• forgotten systems such as ticketing tools, CRMs, or marketing platforms are not still failing alignment

If you are still working through enforcement, DMARC policy modes explained is the right prerequisite reading.

2. Your DNS has to support a valid BIMI assertion record

Once DMARC is stable, DNS becomes the next checkpoint.

The core BIMI publication point is a TXT record at default._bimi.example.com. The BIMI draft defines a tag-value record format where v=BIMI1 identifies the record, l= points to the logo location, and a= can point to authority evidence such as a mark certificate.

A typical record looks like this:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/certificate.pem"

At an administrative level, the DNS requirements are not complicated, but they do need to be clean:

• publish the record at the exact _bimi name expected by the provider flow
• keep the syntax exact because receivers are not required to repair formatting mistakes
• make sure the referenced URLs are HTTPS, not HTTP
• make sure the DNS host is not mangling long TXT values or introducing quoting errors

Subdomain policy still matters

The implementation guide is explicit that DMARC enforcement needs to cover the organizational domain and subdomains.

That matters because many organizations send from multiple visible From: domains. If news.example.com or billing.example.com is part of the live mail flow, do not assume the organizational-domain record alone makes the whole estate BIMI-ready.

3. Provider support is real, but it is not uniform

This is the prerequisite many teams underestimate.

BIMI is not a switch that every mailbox provider treats the same way. The BIMI Group says participating mailbox providers use their own criteria for deciding when a logo may be displayed, and the Internet-Draft also leaves indicator display policy to receivers.

In practice, administrators should assume three things:

1. support is uneven across providers and clients
2. valid publication does not guarantee display everywhere
3. provider-specific certificate expectations may be stricter than the core DNS record format alone

Gmail is a good example of why "supported" needs detail

Google's current admin documentation says BIMI requires a third-party certificate for the domain and logo, specifically a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). It also requires DMARC at p=quarantine or p=reject with pct=100.

So for Gmail, "we published a BIMI TXT record" is not the same as "we completed the prerequisites."

You also need the certificate workflow, the hosted files, and a logo that satisfies both BIMI-format rules and Google's compatibility expectations.

Self-asserted BIMI has limited real-world value

The BIMI Group still describes VMC or CMC as highly recommended and notes that self-asserted logos have limited support across mailbox providers.

That means a technically valid deployment without a mark certificate may still produce disappointing results. For many brands, the business question is not "Can I publish a BIMI record?" but "Will the providers that matter to us actually display the logo?"

4. Logo readiness is an operational requirement, not a design afterthought

Many first BIMI rollouts fail because the source logo file was created for web or print use, not for BIMI validation.

The BIMI Group implementation guide calls for an SVG Tiny PS version of the official logo. Google's setup guidance adds practical requirements and recommendations such as:

• minimum dimensions of 96 by 96 pixels
• width and height specified as absolute pixels
• no relative sizing such as percentages
• no scripts, animations, or external references
• a small, compatibility-friendly file

This is why "we already have an SVG" is not enough.

A normal marketing SVG often includes metadata, unsupported elements, transparency assumptions, or export settings that are fine for browsers but not suitable for BIMI validation.

Trademark and certificate readiness can be the longest lead-time item

Google's guidance says VMC eligibility depends on having a trademarked logo in a jurisdiction recognized by VMC issuers, and notes that trademarking can take 6 to 12 months. If the logo is not trademark-ready, a CMC may be the more realistic path depending on issuer support and your brand situation.

For administrators, this means BIMI may require coordination with legal and brand teams well before any DNS change window.

5. Your hosting has to be as ready as your DNS

BIMI resources are not only DNS records. Receivers also have to fetch the logo and, when used, certificate-related files from the web.

Google's documentation says the public web server hosting BIMI files must use HTTPS and support secure TLS connections. The BIMI draft also requires HTTPS for the l= and a= locations.

That leads to a simple hosting checklist:

• the logo URL resolves publicly without login or redirects that break fetching
• the certificate or PEM URL resolves publicly if your provider flow needs it
• the server certificate chain is valid
• the hosting path is stable enough that future website changes will not quietly break BIMI

Admins sometimes get the DNS right and then lose days to a broken asset URL, a redirect loop, or a CDN rule that blocks fetches from validation systems.

A practical readiness checklist for administrators

Before you open a BIMI project as "implementation," verify these questions first:

DMARC readiness

• Is the organizational domain already at p=quarantine or p=reject?
• Is pct=100?
• Are the active visible From: domains also covered appropriately?
• Are all legitimate senders passing DMARC alignment consistently?

DNS and hosting readiness

• Can you publish and verify default._bimi TXT records cleanly?
• Can you host the logo and, if needed, certificate materials over HTTPS?
• Do you control the relevant DNS and web changes without long vendor delays?

Provider-readiness questions

• Which mailbox providers actually matter to your audience?
• Do those providers expect VMC or CMC-backed BIMI rather than self-asserted publication?
• Are you prepared for logo display to differ by provider and client even when the setup is valid?

Brand-asset readiness

• Do you have a logo that can be exported as compliant SVG Tiny PS?
• Is the logo trademarked, or is a CMC path needed instead of a VMC path?
• Have legal, brand, and security stakeholders agreed on the exact indicator to publish?

The common admin mistake: starting with the wrong team

If a BIMI project starts with "design will send us the logo," it often stalls.

The better order is:

1. confirm DMARC enforcement and alignment across live senders
2. confirm which providers you care about and what they require
3. confirm certificate and trademark feasibility
4. prepare the BIMI-compliant logo asset
5. publish DNS and hosting changes last

That order reduces wasted work because it prevents the team from polishing a brand asset before the authentication and provider prerequisites are actually satisfied.

Bottom line

BIMI readiness is mostly about operational maturity.

Before the logo can appear, administrators need strong DMARC enforcement, clean aligned authentication, correct DNS publication, reliable HTTPS hosting, realistic provider expectations, and a logo that is actually ready for BIMI validation and certificate workflows. The visible logo is the outcome, but the real prerequisite is a well-controlled sending domain.