BIMI: The Definition, How It Is Checked, and Where It Breaks
BIMI lets a domain publish a logo in a DNS record that participating mailbox providers can show beside its messages. It requires an enforcing DMARC policy first, a tightly constrained SVG, and at several providers a verified mark certificate. It changes how delivered mail looks, never whether it was delivered.
Key takeaways
- A p=none DMARC policy does not qualify: the domain must publish quarantine or reject.
- The logo must be a constrained SVG profile, which most brand exports do not satisfy.
- Several major providers additionally require a paid, audited verified mark certificate.
- It is not a deliverability feature, and unbranded cold-email sending domains gain nothing from it.
BIMI (Brand Indicators for Message Identification) is a specification that lets a domain publish a logo in DNS so participating mailbox providers can display it beside messages from that domain. The logo is an SVG hosted by the sender and named in a DNS TXT record at default._bimi.<domain>. Crucially, a mailbox provider only looks for it once the domain is already passing DMARC at an enforcing policy. Details and the current implementation status are maintained by the BIMI Group.
The one-line summary people repeat is that BIMI puts your logo in the inbox. That is what it does. What it is for is narrower and more interesting: it turns a technical achievement nobody can see, an enforced DMARC policy, into a visible signal a recipient can recognise, which gives an organisation a commercial reason to finish an authentication project it would otherwise leave at p=none.
How the pieces fit together
Three things have to be true before a logo appears.
DMARC has to be enforcing. A p=none policy does not qualify. The domain must publish p=quarantine or p=reject, and the mail in question must actually pass DMARC with alignment. This is the gate, and it is deliberate: a logo attached to a domain anyone could spoof would be worse than no logo at all.
The logo has to be in a constrained SVG profile. BIMI does not accept an arbitrary SVG. The profile is a tightly restricted subset with no scripting, no external references and no animation, square, with a defined title. Most brand SVGs need rebuilding rather than resizing.
Some providers require a verified mark certificate. A VMC is issued by a certification authority after checking that the mark is a registered trademark held by the organisation. It is a paid, audited artefact with an annual lifecycle, and it is what several major mailbox providers check before displaying anything. Providers differ, the requirements move, and the BIMI Group's own pages are the surface to check rather than any summary written a year ago.
- Step 1Authenticate
SPF and DKIM correct, and aligned with the visible From: domain.
- Step 2Enforce DMARC
Move the published policy from none to quarantine or reject, and keep mail passing.
- Step 3Publish the mark
Host a conforming SVG and name it in a TXT record at default._bimi.<domain>.
- Step 4Certify, where required
Obtain a verified mark certificate for the providers that require one, and reference it in the record.
Where the textbook definition misleads
BIMI is not a deliverability feature. It changes what a message looks like once it has already been delivered to an inbox. It does not influence whether that happened. A domain that qualifies for BIMI has usually done the underlying work that helps placement, so the two are correlated, and reading that correlation as cause leads people to buy a certificate to fix a spam-folder problem it cannot touch.
The gate is the value. Almost everything BIMI is credited with is a property of enforced DMARC, which the standard requires as a precondition. If you are weighing whether BIMI is worth it, the honest framing is that you are being paid, in logo pixels, for finishing an authentication project that was worth finishing anyway.
It does not apply to the mail most outbound programmes send. BIMI attaches to a domain that has a registered trademark and an enforcing DMARC policy. Cold outbound is generally sent from separate sending domains that exist to keep sending risk away from the company's primary domain, and those domains hold no trademark and are not the brand anyone would recognise. Applying for a certificate for a domain a recipient has never seen buys nothing.
The record is trivial and the SVG is not. The DNS half is one TXT record naming two URLs. The logo half is a constrained profile that forbids most of what a designer's export contains: no embedded raster images, no external font references, no scripts, no animation, a fixed aspect ratio and a required title element. A brand SVG lifted from a website almost never conforms, and the work of rebuilding it sits with whoever owns brand assets, not with whoever owns DNS. Rollouts stall there far more often than they stall on the certificate.
A logo does not survive a change of visible sender. BIMI keys on the From: domain. Mail sent on your behalf by a third party under its own domain, forwarded mail whose From: is rewritten, and any message that fails alignment, all lose the logo, because none of them is the authenticated domain the record belongs to. This is the same alignment question that governs DMARC, arriving in a place people do not expect it.
Display is a per-provider decision, and it is not guaranteed. Publishing a valid record entitles you to nothing. Each provider decides whether to display, under its own additional criteria, and those criteria include reputation signals the standard says nothing about. A correct record with a poor sending reputation can simply not render.
- Displays a logo beside your mail at participating providers
- Signals visually that the domain is DMARC-enforcing
- Gives an authentication project a visible finish line
- Applies to the corporate domain a recipient recognises
- Improve inbox placement or spam-folder rates
- Guarantee display anywhere, at any provider
- Apply usefully to unbranded cold-email sending domains
- Substitute for reputation, list quality, or a message worth reading
What this means when you are running outbound
There is a clean split here, and getting it right saves both money and a false expectation.
Your corporate domain is a good candidate. It is the one recipients recognise, it is the one worth defending against impersonation, and it should be at enforcing DMARC regardless. If it already is, BIMI is a modest incremental step that makes the investment visible in the inbox, and it is a sensible ask of whoever owns brand and IT.
Your outbound sending domains generally are not. They exist precisely so that sending activity does not accumulate against the primary domain. They are new, unbranded, and often numerous. The trademark requirement alone rules most of them out, and the per-domain certificate cost makes the arithmetic worse with every domain added.
Where the effort genuinely belongs, for an outbound programme, is the layer underneath: correct records on every sending domain, DMARC moved past monitoring on the corporate domain, and aggregate reports read often enough to catch a source failing quietly. That is the work BIMI is a reward for, and it is worth doing whether or not the reward interests you.
If a leadership team is asking about BIMI, the useful reframing is to treat the question as a request for the authentication project. Enforce DMARC first, measure what breaks, fix it, and then decide about the logo with the hard part already finished.
The order of operations that actually works
Most BIMI projects fail in the same place, and it is not the place people brace for. They begin with the logo, because the logo is the visible deliverable and the part a stakeholder asked for, and they arrive at the DMARC gate months later with a rebuilt SVG and a certificate quote in hand, only to discover that moving the corporate domain to enforcement will break a legacy system that has been sending unauthenticated mail as the company for years.
Reversing that order costs nothing and removes the surprise. Publish DMARC at p=none with a reporting address. Read the aggregate reports for a month and enumerate every source sending as the domain, which is a list nobody in the organisation can produce from memory. Fix or retire each one. Move to quarantine, then to reject, watching the reports at each step. At that point the entire remaining BIMI project is one TXT record, one conforming file, and possibly a certificate.
The reports are the reason this works. They are the only inventory of who sends as you, and the discoveries in them are consistently the same: a billing platform, an applicant tracking system, a monitoring tool, and a marketing product somebody trialled in 2021. Each is a live authentication failure, each is a small drag on the domain, and none is visible from any dashboard the marketing or sales team ever opens.
- Yes: Recipients recognise this domain as the brand
- Yes: DMARC is published at quarantine or reject, and mail passes
- Yes: The organisation holds a registered trademark for the mark
- Depends: A conforming SVG exists, or a designer is available to build one
- Depends: Someone owns the annual certificate renewal
- No: Buying a certificate for an unbranded cold-email sending domain
The short version
The specification itself is still moving, which is a reason to check a primary source rather than a summary. Provider support, the certificate types accepted, and the exact profile constraints have all changed since BIMI first appeared, and secondhand write-ups age badly. The BIMI Group publishes the current position, and it is the surface to read before committing budget.
BIMI is a logo in DNS, gated on an enforcing DMARC policy and, at several providers, on a verified mark certificate. It is a visibility feature attached to an authentication achievement, and the achievement is the part that matters.
For the domain your customers know, it is a reasonable finishing touch on work that should already be done. For the sending domains an outbound programme runs on, it is a distraction with a per-domain cost. Either way, no BIMI record has ever moved a message from the spam folder to the inbox; that outcome is decided by authentication, by sending history and reputation, by domain warmup, and by whether the message deserved the attention. If placement is the actual problem, a deliverability audit will find more in an hour than a certificate will in a year, and why DMARC fails is the right place to start if enforcement is the blocker.
RevenueFlow runs cold email and LinkedIn outreach for B2B teams, on sending infrastructure we authenticate and monitor ourselves. See how the campaigns work.
Requirements verified as of August 2026 against the BIMI Group's published materials. Provider requirements change; verify current terms with the source before relying on them.
Frequently asked questions.
Frequently asked questions- Will BIMI improve my email deliverability?
- No. It changes what a message looks like once it has already reached an inbox. Domains that qualify have usually done the authentication work that does help placement, so the two correlate, and reading that correlation as cause leads people to buy a certificate to fix a spam-folder problem it cannot touch.
- Do I need a verified mark certificate?
- It depends on the provider. Several major mailbox providers check for one before displaying anything, and it is issued by a certification authority after verifying you hold a registered trademark for the mark. Requirements move, so the BIMI Group pages are the surface to check rather than any summary written a year ago.
- Should I set up BIMI for my cold email sending domains?
- Generally no. Those domains exist so sending activity stays away from your primary domain, which makes them new, unbranded and often numerous. The trademark requirement rules most of them out and the per-domain certificate cost worsens with every domain added. The corporate domain recipients actually recognise is the sensible candidate.
- I published a valid BIMI record and no logo appears. Why?
- Publishing a record entitles you to nothing. Each provider decides whether to display under its own additional criteria, which include reputation signals the specification says nothing about. Check first that DMARC is genuinely enforcing and that mail is passing with alignment, since that gate is where most non-display cases actually sit.