BIMI and DMARC

Every other part of BIMI — the logo, the certificate, the DNS record — rests on one foundation: DMARC at enforcement. If your domain's DMARC policy is not set to quarantine or reject, no supporting inbox will show your logo, no matter how perfect the rest of the setup is. Understanding why makes the requirement much easier to work with, so it is worth starting there.

Why BIMI insists on DMARC

BIMI's whole value is that a logo means the mail is really from you. The mechanism that proves "really from you" is DMARC, which ties together the two older authentication methods and tells receivers what to do when mail fails. If a domain published a BIMI logo without enforcing DMARC, anyone could spoof the domain and ride on its logo — the opposite of a trust signal. So the standard requires the domain to be defended first. In effect, the logo is the visible reward for closing your domain to spoofing.

The authentication chain, in order

BIMI eligibility is the top of a short stack. Each layer depends on the one below it:

1. SPF and DKIM — the two ways a receiver can authenticate a message. SPF lists which servers may send for your domain; DKIM adds a cryptographic signature that proves a message was sent by your domain and not altered in transit.
2. Alignment — DMARC does not just ask whether SPF or DKIM passed, but whether the domain they authenticated matches the domain shown in the message's From: address. A message passes DMARC when SPF or DKIM passes and is aligned with the visible sender.
3. DMARC policy — a DNS record at _dmarc.yourdomain.com that states your policy and where to send reports. This is where you move from merely observing failures to acting on them.
4. BIMI — once DMARC passes and the policy is at enforcement, the receiver will look up and display your logo.

What "enforcement" actually means

A DMARC record looks like this:

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s"

The parts that matter for BIMI:

• p= — the policy. This must be quarantine or reject. A policy of p=none — which only monitors and takes no action — is not enforcement, and will not qualify for BIMI. reject is the strongest and the ideal end state.
• pct= — the percentage the policy applies to. If present, some mailbox providers expect it to be 100 (its default when omitted). A partial policy such as pct=50 with quarantine is generally treated as not fully enforced for BIMI purposes, so leave pct at 100 — or simply omit it.
• Where the record lives. The policy must be published for the organisational domain your mail is sent from, and applied so that the streams you care about are covered. Watch the subdomain policy tag sp=: if you send from subdomains, make sure they inherit an enforcing policy rather than falling back to none.

Getting to enforcement safely

The reason so many domains sit at p=none is fear — moving straight to reject without preparation can cause legitimate mail to be quarantined or bounced. The safe path is gradual, and it is the same path that makes your domain genuinely harder to spoof:

1. Authenticate every legitimate source. Make sure all your sending services — your mail platform, marketing tools, ticketing systems, and so on — are covered by SPF and signing with DKIM under your domain.
2. Publish p=none with reporting and monitor. Add rua=mailto:… to collect DMARC aggregate reports. These show you which sources are passing, which are failing, and which you did not know about. Do not treat none as a destination — it is a listening phase.
3. Fix the gaps. Bring any failing legitimate sources into alignment. This is the real work, and it is worth doing carefully.
4. Move to quarantine, then reject. Once reports show only genuine mail passing, tighten the policy. At this point your domain is protected — and eligible for BIMI.

Only after DMARC is enforcing does it make sense to publish your BIMI record, logo and certificate. Adding them earlier simply produces no logo and can send you hunting for a fault that is really just the missing prerequisite.

Reading the reports along the way

The rua address is what makes a safe rollout possible, so it is worth knowing what arrives there. DMARC aggregate reports are XML files sent daily by receiving providers, summarising the mail they saw from your domain: the sending IP addresses, how many messages each sent, and whether they passed SPF, DKIM and DMARC alignment. Raw XML is hard to read by eye, so most people feed it into a DMARC reporting tool that turns it into a plain table. What you are looking for before you tighten the policy is simple: every legitimate source passing and aligned, and nothing failing that you actually recognise. Anything failing that you do recognise is a source to fix; anything failing that you do not recognise is exactly what enforcement is meant to stop.

Common pitfalls

• Policy still p=none — the single most common reason a BIMI logo never appears.
• A partial pct — treated as not fully enforced by strict receivers.
• Enforcing on the wrong domain — the policy must cover the domain in your From: address, including subdomains via sp=.
• An unmonitored jump to reject — safe only once reports confirm legitimate mail is aligned.

Check where you stand

To see your current position across all of these signals at once, run your domain through the email deliverability checker, which reads MX, SPF, DKIM and DMARC together and flags a none policy. When DMARC is enforcing, the BIMI checker confirms eligibility and previews the logo. For deeper checks of the individual records, DKIM Studio inspects signing keys and DNS Studio's email validator covers MX, SPF and DMARC.

Related guides

• What is BIMI? — the standard and what it needs.
• VMC and CMC certificates — the next step after DMARC.
• BIMI SVG logo requirements — the logo itself.
• Email deliverability checker — check SPF, DKIM and DMARC in one place.