BIMI Record Valid, Logo Missing? Check Your DMARC Policy.

The DNS records are perfect. The SVG is validated. The path in your BIMI record is correct. You send a test email to your Gmail account, pull to refresh, and… nothing. Just the same old default initial, staring back at you from the inbox avatar slot.

This is one of the most common and maddening scenarios for admins implementing Brand Indicators for Message Identification. You've followed every step, your BIMI checker gives you a green light, yet the logo stubbornly refuses to appear. The hours spent getting the SVG just right, the wrestling with DNS propagation—all for nothing.

The culprit probably isn't your BIMI record. It’s your DMARC policy. More specifically, your policy isn't at an enforcement level, and for mailbox providers like Gmail and Apple, that's a dealbreaker.

First, Eliminate the Obvious: Syntax and Path

Before we descend into the DMARC rabbit hole, let's confirm the basics. A simple typo can derail the whole process. Use a public BIMI record checker to validate your DNS TXT record for the `default._bimi` selector. It should look something like `v=BIMI1; l=https://your-cdn.com/logo.svg;`. The checker will fetch your record, verify the syntax, and then attempt to retrieve the SVG file from the URL specified in the `l=` tag.

This quick triage rules out common errors: a typo in the URL, an HTTPS-enabled server that's not publicly accessible, or a missing `v=BIMI1` tag. If you have a Verified Mark Certificate (VMC), the checker should also validate the `a=` tag, which points to the certificate file. But for most, the VMC is not the issue—it's optional for many providers, whereas DMARC enforcement is not.

A Valid Record Isn't an Accepted Record

This is a critical distinction. A checker tool confirms syntactic validity. It tells you that your record is formatted correctly according to the specification. It does not, and cannot, tell you if a specific receiving mail server like `mx.google.com` will actually accept it and display the logo.

A receiver's decision is based on a wider context of trust. Is the sending domain authenticating its mail? Does it have a history of sending legitimate email? And most importantly, has the domain owner committed to a policy that actively protects against spoofing? A green checkmark from a validator is step one, not the finish line.

The Real Gatekeeper: DMARC Enforcement

Here's the heart of the problem. DMARC, defined in RFC 7489, uses a policy tag (`p=`) to tell receivers what to do with mail that claims to be from your domain but fails SPF and DKIM alignment. There are three settings: `p=none`, `p=quarantine`, and `p=reject`.

The `p=none` policy is strictly a monitoring tool. It essentially says, "Dear receiver, please do nothing to failing messages, but send me reports about who is sending mail from my domain." It’s the email equivalent of installing security cameras but leaving the doors unlocked. You're gathering data, not taking action.

Why `p=none` Is a Non-Starter

Mailbox providers view BIMI as a reward for achieving a strong email authentication posture. Displaying your logo is a signal of trust to their users. Why would they grant that trust signal if you, the domain owner, haven't shown enough confidence in your own mail-sending infrastructure to enable enforcement?

A `p=none` policy signals that you're not sure you've identified all of your legitimate sending sources. It suggests that if the receiver were to block failing mail, it might block valid emails from your marketing team, your HR system, or a third-party partner. By requiring `p=quarantine` (send to junk) or `p=reject` (block outright), providers ensure that only domains willing to stand behind their identity get the visual benefit of BIMI. You have to have some skin in the game.

Reading the Tea Leaves in Email Headers

You don't have to guess if DMARC is the issue. The receiving server will tell you exactly why it didn't display your logo. The answer is buried in the email's raw message headers, specifically the `Authentication-Results` header.

To find this, open the email in your client (e.g., in Gmail, click the three dots and 'Show original'). You'll be presented with the full, unprocessed source of the message. Scan for the `Authentication-Results` header, which is added by the first major mail server to handle the message, like Google's or Microsoft's.

Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s1 ...;
spf=pass (google.com: domain of user@example.com designates 209.85.220.41 as permitted sender) ...;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com;
bimi=fail (DMARC policy is not at enforcement) — Example Authentication-Results Header

Look closely at that last line. DKIM passed. SPF passed. DMARC even shows a 'pass' verdict, which only means the message was properly aligned with the `header.from` domain. But the `bimi` result is an explicit `fail`. And the reason is stated right there in the parentheses: `DMARC policy is not at enforcement`. This is your smoking gun. The server checked for BIMI, found the record, but rejected it because your DMARC policy was `p=none`.

The Safe Migration to DMARC Enforcement

The solution is to move to an enforcement policy. But flipping the switch from `p=none` to `p=reject` overnight is how you cause a self-inflicted mail outage. Any legitimate third-party service sending on your behalf—think Salesforce, a payroll provider, or your newsletter platform—that isn't properly configured for SPF/DKIM alignment will suddenly have its mail blocked. The business impact can be severe.

Your Safety Valve: The `pct` Tag

The DMARC specification provides a safety mechanism for this exact scenario: the percentage (`pct`) tag. It allows you to apply your policy to only a small fraction of failing messages, giving you time to analyze the impact before going all-in.

Start by changing your DMARC record to `v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc-reports@yourdomain.com;`. This policy tells receivers to move just 5% of failing emails to the spam folder. The other 95% are delivered normally, just as with `p=none`. The crucial element is the `rua` tag, which directs aggregate DMARC reports (XML files summarizing authentication results) to an address you control.

Analyze, Fix, and Increment

Now, the real work begins. Over the next few days and weeks, you analyze the incoming DMARC reports. You'll see which IP addresses and services are sending mail that's failing authentication. Your job is to identify the legitimate senders in that group and fix their configuration. This usually involves adding their sending domains to your SPF record via an `include:` mechanism or configuring DKIM signing for them within their platform.

As you resolve these issues and the volume of legitimate-but-failing mail in your reports drops, you can slowly increase the percentage: `pct=25`, then `pct=50`, and finally `pct=100`. Once you're at `p=quarantine; pct=100` and no critical services are breaking, you have reached DMARC enforcement. For the purposes of BIMI, `p=quarantine` is sufficient. You can move to `p=reject` for even stronger protection, but it's not a prerequisite for your logo to appear.

Post-Enforcement Checks and Final Gotchas

After you’ve been at `p=quarantine` or `p=reject` with `pct=100` for at least 48 hours to allow for DNS propagation and caching, it's time to re-run your test. Send a new email to your test account and inspect the headers again. This time, the `Authentication-Results` header should show a `bimi=pass` verdict, and with any luck, your logo will appear in the inbox.

Patience, Caching, and Reputation

If it doesn't show up immediately, don't panic. Mailbox provider systems have multiple layers of caching. It can sometimes take a day or two for a change in DMARC policy to be fully recognized across their entire infrastructure in relation to BIMI processing.

Finally, be aware of an unwritten rule: some providers, particularly Gmail, seem to factor in domain reputation and sending volume. Even with a perfect technical setup, a brand-new domain with very little sending history might not get a BIMI logo. BIMI is primarily designed for established brands to reinforce their identity. If your domain is new, focus on building a positive sending reputation over time. The logo will eventually follow.

The takeaway

BIMI isn't just another DNS record to set and forget. It's the final, visible reward for achieving a fully enforced DMARC policy. The enforcement requirement isn't a bug or an obstacle; it's the entire point. It separates brands that merely publish a policy from those that actively use it to protect their users and their identity from phishing and spoofing.

The logo is the carrot, but the security posture you build to get there is the real prize. As you analyze DMARC reports to identify failing third-party sources, parsing thousands of XML files can be a chore. Using a service to ingest and visualize those reports, like the tools we build at MailSleuth.AI, can turn weeks of manual analysis into hours, dramatically speeding up your journey to enforcement and, ultimately, to that coveted logo.