BIMI requirements explained

Requirement 1: DMARC at enforcement

BIMI requires the domain's DMARC policy to be at p=quarantine or p=reject, applied to all mail, and with no sp=none exempting subdomains. A domain still at p=none does not meet the prerequisite, even if every other BIMI requirement is technically satisfied. RFC 9989 removed the pct tag from DMARC, but a record that still carries one below 100 also fails the prerequisite, because BIMI validators continue to read the tag. A t=y test-mode tag fails it too: the policy you publish is not the one receivers apply, so the strong policy BIMI asks for is not in force.

This is a deliberate design choice, not an incidental restriction. BIMI is meant to reward domains that have already proven, through DMARC enforcement, that they block unauthenticated mail impersonating them; it is not meant as a shortcut to a trusted-looking logo for a domain that has not yet done that underlying work.

Requirement 2: the BIMI DNS record

The record itself is a TXT record at default._bimi.example, in the form v=BIMI1; l=https://example.test/logo.svg;, where l= points to the logo's HTTPS URL. An optional a= tag can point to a Verified Mark Certificate's URL when one exists.

The selector default is used unless the domain publishes a different selector for a specific purpose, such as varying the displayed logo by sending source; most domains only ever need the default selector.

Requirement 3: the logo file format

The logo must be an SVG file in the restricted SVG Tiny Portable/Secure (SVG Tiny PS) profile, not a general-purpose SVG export from an ordinary design tool. This profile deliberately excludes scripts, external references, and several other general SVG features, since the file is rendered directly inside recipients' inboxes and needs to be safe to parse without executing arbitrary content.

The file must be served over HTTPS, and is typically expected to be square with the logo roughly centered. Most logos created in mainstream design software need to be specifically re-exported or converted to meet the restricted profile; a normal SVG export usually will not validate as-is.

Requirement 4 (provider-dependent): the Verified Mark Certificate

A Verified Mark Certificate (VMC) is a certificate, issued by a small number of authorized certificate authorities, that cryptographically ties the BIMI logo to a registered trademark owned by the domain. Obtaining one requires an active trademark registration and is a paid, provider-external process entirely separate from anything in DNS.

Support for BIMI without a VMC varies by mailbox provider: some display the logo from a valid SVG and enforced DMARC policy alone, while others, notably Gmail, require a VMC before they will display it. A domain without a VMC can still publish a technically complete BIMI record; it will simply display in fewer inboxes until a VMC is obtained.

Putting it together: a checklist

• DMARC policy at p=quarantine or p=reject, applied to all mail, with no sp=none, no leftover pct tag and no t=y

• BIMI TXT record at default._bimi.example pointing to the logo's HTTPS URL

• Logo file in the SVG Tiny PS profile, served over HTTPS, without scripts or external references

• Verified Mark Certificate obtained and referenced via the a= tag, if display in providers that require one matters

Meeting every item on this list does not guarantee display in every inbox, since provider support and requirements can differ and change over time, but it satisfies every requirement documented in the specification and by the major participating providers as of this writing.

How BIMI fits alongside other trust signals

BIMI is a visual signal shown after a message has already been delivered to the inbox; it does not itself change whether a message is delivered, quarantined, or rejected, which is decided entirely by SPF, DKIM and DMARC. A domain can have flawless DMARC enforcement and still choose not to implement BIMI at all, with no effect on deliverability either way.

Because BIMI depends entirely on the DMARC prerequisite being met first, and because provider support for it continues to evolve, it is best treated as a finishing touch applied once the underlying authentication is solid, rather than as an early priority in an authentication rollout. A domain still working through the DMARC staged rollout described elsewhere in this catalogue should generally finish that rollout before spending time on BIMI's logo and certificate requirements.

Troubleshooting a logo that will not display

When every piece looks correct but the logo still does not appear, work through the requirements in order rather than assuming the most complex piece, the VMC, is automatically the cause. First confirm the DMARC policy is genuinely at enforcement — p=quarantine or p=reject, no sp=none, no t=y, and no leftover pct tag, which BIMI validators still read even though RFC 9989 removed it — since this is the single most common oversight, especially on a domain still mid-rollout toward full enforcement.

Next confirm the logo file itself is reachable over HTTPS at exactly the URL in the DNS record's l= tag, and that it validates against the SVG Tiny PS profile rather than being a general SVG export that merely looks similar. Finally, check whether the specific mailbox provider you are testing against is one that requires a VMC; a logo that displays correctly in one provider's inbox but not another's is frequently explained by exactly this difference in provider requirements rather than a fault in the record.

BIMI's status as an evolving specification

BIMI is documented through an Internet-Draft maintained by the Authindicators Working Group rather than a finalized RFC at the time of this writing, which means some details, particularly around VMC requirements and provider-specific behavior, have shifted before and may shift again. Domains implementing BIMI should expect to periodically revisit their configuration against current provider documentation, rather than treating a working setup as permanently fixed.

This evolving status does not make BIMI unreliable to implement; the core mechanism, a DNS record pointing to a logo, gated behind DMARC enforcement, has been stable in practice for a long time. It mainly means checking a provider's current published requirements before troubleshooting an unexpected display issue, since the specific behavior can differ from what older documentation described.