DMARC

What a BIMI Rollout Actually Requires — And Where It Breaks

August 28, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

A client asks for the blue checkmark logo they saw in a competitor's Gmail messages, and the request sounds like a five-minute DNS change. It rarely is. BIMI is the most visible payoff of email authentication work, which is exactly why it exposes every shortcut taken earlier in a DMARC rollout, and why MSPs who treat it as a quick add-on tend to spend more time explaining why the logo isn't showing than they spent implementing it.

BIMI requires three things working together before any inbox will display a logo: a DMARC policy enforced at quarantine or reject on the sending domain, a logo file built to the restrictive SVG Tiny PS profile, and, for most major providers, a third-party certificate that verifies the sender's right to that logo. Miss any one and the logo simply does not appear, with no error message pointing to why.

What does a BIMI rollout actually require?

At the specification level, BIMI is deliberately thin. The IETF draft that defines it describes it as a mechanism that lets domain owners publish a preferred brand indicator and lets mail transfer agents verify that indicator against existing authentication signals rather than inventing a new one. It explicitly leans on infrastructure MSPs should already have deployed for their clients.

The draft is direct about the gating condition: to participate in BIMI, domain owners must have a strong DMARC policy of quarantine or reject on both the organizational domain and the specific sending domain. That single sentence is where most rollouts either succeed or stall for months, because a domain still sitting at p=none while its SPF and DKIM get sorted out is not eligible for BIMI no matter how polished the logo file is.

Beyond DMARC, Google's own setup documentation for Workspace lays out the logo requirement plainly: logos used with BIMI must be in Scalable Vector Graphics file format, and senders applying for a certificate must submit that logo in SVG and meet the detailed formatting requirements Google links out to. That is not the same SVG a design team exports from Illustrator for a website header, and the gap between "valid SVG" and "valid BIMI SVG" is where a surprising amount of implementation time disappears.

Why does the logo file break so often?

Because BIMI does not accept a normal SVG export, and most design tools were never built to produce the restricted profile it demands. The BIMI Group's own guidance on building logo files is specific about this: the format is SVG Portable/Secure, a profile of SVG Tiny 1.2 that is stricter than the base standard, meaning an SVG Tiny 1.2 image will require modifications in order to be compliant with BIMI.

The same guidance notes that Adobe Illustrator's closest export option still leaves behind attributes that have to be manually stripped before the file will validate, which is a small but real detail that trips up teams who assume a designer's SVG export is ready to publish. The BIMI Group document also flags that the file must declare a strict baseProfile, include a title element naming the brand, and avoid any external references or scripting, all details that a generic SVG file passes a browser test on but fails a BIMI validator on immediately.

For an MSP managing logo assets across a dozen client brands, this means BIMI onboarding is not a design handoff. It is a technical QA step that belongs in the same checklist as DNS record verification, ideally run through a validator before anything gets published, since a cosmetically correct logo and a spec-correct logo look identical to a human eye and completely different to a receiving mail server.

Which certificate does a domain actually need?

That depends entirely on which inboxes the client cares about, and the honest answer is that certificate requirements are provider-specific rather than universal. Two certificate types currently exist: the Verified Mark Certificate, which requires a registered trademark on the exact logo, and the newer Common Mark Certificate, which widened access for brands without one.

Apple's own developer documentation confirms the stricter path for its client: a logo appears in Apple Mail only when the sending organization has verified a BIMI Evidence Document, for example a VMC trusted by the mail provider, and added the required headers vouching for that verification. That framing matters because it means Apple support is not simply "turn on BIMI and it works everywhere." A domain can be fully compliant for Yahoo or Fastmail and still show nothing in Apple Mail or Gmail without the certificate layer.

The certificate market itself is also narrower than most rollout guides suggest, and it got narrower recently. Entrust, historically one of only two authorities issuing VMCs, confirmed on its own site that as of May 12, 2025, customers can no longer issue Verified Mark Certificates or S/MIME certificates from Entrust Certificate Services, with the underlying public certificate business transitioning to Sectigo later that year. Any BIMI plan built on older documentation that still lists Entrust as an active issuance option needs a second look before a client is quoted a certificate timeline.

Where do MSPs get burned on timing?

Sequencing, almost every time. Certificate issuance, trademark validation for a VMC, and DMARC enforcement all run on different clocks, and treating them as parallel tasks instead of a dependency chain is the most common planning mistake.

A VMC application requires proof of a registered trademark tied to the exact logo being submitted, per the BIMI Group's own certificate guidance, which describes the Mark Verifying Authorities as verifying the association of logos with domains before issuing anything that can be referenced in a BIMI DNS record. If a client's trademark filing is still pending, or their registered mark does not exactly match the logo they want in the inbox, that discovery needs to happen in week one, not after DMARC enforcement is already live and the certificate order gets rejected.

The realistic order of operations looks like this for most client domains:

• Confirm SPF and DKIM pass consistently for every legitimate sending source, including marketing platforms and helpdesk tools that are easy to forget.
• Move DMARC from monitoring to enforcement (p=quarantine or p=reject) and hold it there long enough to confirm aggregate reports show no legitimate mail failing.
• Build and validate the SVG Tiny PS logo file independently of the certificate process, since a validator can catch format errors before money is spent on a certificate.
• Decide between VMC and CMC based on trademark status and which inboxes actually matter to the client, then order from a currently active issuer.
• Publish the BIMI DNS TXT record referencing both the logo and the certificate, then verify display across Gmail, Apple Mail, and any other provider in scope.

Doing these out of order is how a domain ends up with a paid-for certificate sitting unused because DMARC enforcement got walked back after a support ticket about a blocked marketing send. It is also how MSPs end up promising a logo in a client's next campaign without a realistic sense of how long trademark verification or certificate issuance can take once a filing needs to be corrected.

Making BIMI a checklist item instead of a fire drill

None of this makes BIMI a bad investment for the clients who actually want it. It does mean it belongs at the end of an authentication rollout, not the beginning, and that the SPF, DKIM, and DMARC work has to be genuinely stable before a logo file or certificate order enters the conversation. Domains that reach enforcement through a structured process, the kind laid out in ActiScan's getting-started guide, are in a far better position to add BIMI cleanly than domains where enforcement was rushed to satisfy a single client request.

For MSPs quoting this work across a client base, the practical move is separating the authentication baseline, which every client domain needs regardless of branding ambitions, from the BIMI add-on, which only a subset will pursue. ActiScan's pricing reflects that split, since continuous DMARC, SPF, and DKIM monitoring is the layer that has to exist before any certificate purchase makes sense. Technicians who want to see where a specific client domain currently stands against these prerequisites can run that check directly from the signup page before committing a client to a BIMI timeline that depends on prerequisites nobody has verified yet.

The logo in the inbox is a visible reward for authentication work that is otherwise invisible to clients. That visibility is useful for justifying the underlying DMARC project, but only if the sequencing holds. Sell BIMI as a five-minute DNS change and the eventual conversation about why the logo isn't showing will be a much longer one.