Why Is My BIMI Logo Not Showing?
A BIMI logo can be absent even when the DNS record looks plausible. Work from structural checks to provider policy: record discovery, DMARC enforcement, SVG fetch and profile, evidence document, DNS cache, then sender eligibility and reputation.
First confirm one valid BIMI record at the expected selector. Then verify DMARC p=quarantine or p=reject with pct=100, a reachable HTTPS SVG Tiny PS logo, and any evidence certificate required by the receiving provider. After structural issues are clear, allow for DNS caching and check provider-specific reputation and eligibility. Structurally ready never means guaranteed display.
Overview
BIMI display is a chain of independent decisions. DNS must return the intended record. DMARC must protect the organizational domain and aligned messages. The logo and evidence URLs must be safe to fetch. The SVG must fit the required profile. The certificate, when required, must be acceptable to the provider. Finally, the mailbox provider applies its own reputation, sending-history and user-interface policy.
A failure near the start of the chain usually prevents later checks from mattering. Diagnose in order so that a provider-policy question is not used to explain a basic DNS or HTTPS failure.
Why it happens
The most common structural causes are no record at default._bimi, a typo in the selector, multiple BIMI TXT records, invalid tag syntax, DMARC at p=none, pct below 100, a logo URL that returns HTML or redirects badly, a TLS or DNS failure at the asset host, and an SVG that is not Tiny PS compatible. Evidence documents add their own fetch and provider-acceptance requirements. Even after all of those pass, providers can withhold display because the sender is new, inconsistent, low-volume, high-complaint or otherwise outside their program.
How to fix it
Run the BIMI Inspector and fix the first concrete failure it reports. If the record is missing, verify the selector and DNS name. If DMARC is not enforced, use the DMARC Policy Visualizer to review p, sp and pct before tightening policy safely. If the SVG cannot be fetched, test the exact l= URL without browser cookies and fix HTTPS, redirects, MIME type or availability. If the SVG is fetched but incompatible, re-export it as SVG Tiny PS. If an evidence document is required, follow the issuer and provider instructions for the a= URL.
After publishing a correction, wait for the relevant DNS TTL and provider caches. Retest from public DNS, then review the provider's current BIMI program and sender-reputation requirements. MXFend can show structural readiness, but it cannot force cache refreshes or predict a provider's final display decision.
Examples
Example 1: the record and logo pass, but DMARC is p=quarantine; pct=25. The domain is not at full enforcement, so raise pct safely after reviewing DMARC reports. Example 2: every structural check passes but one provider still shows no logo. Treat that as an eligibility or reputation investigation, not evidence that the DNS must be changed again.
Common mistakes
Avoid repeatedly changing a correct record before caches expire, testing the wrong selector, validating only the apex domain instead of default._bimi, assuming p=quarantine is enough when pct is below 100, using a signed or expiring asset URL, checking the SVG in a browser but not its response headers, and buying a certificate with the expectation that it guarantees display.
Checklist
- Exactly one record is returned from the selector actually used by the message.
- The record has valid v, l and any required a tags.
- DMARC is enforced at p=quarantine or p=reject with pct=100 and aligned mail passes.
- The SVG and evidence URLs are public, stable HTTPS resources with successful fetches.
- The SVG passes Tiny PS structural checks and remains legible in a square or circular crop.
- DNS TTL and provider caches have had time to refresh.
- The receiving provider supports the certificate type and the sender meets its reputation policy.
Evidence certificate problems
A missing, unreachable, expired or provider-unsupported evidence document can block display where a certificate is required. The domain coverage and logo represented by the document must also fit the issuer and provider rules. MXFend can report fetch and parsed structural metadata, but it does not make a complete trust, revocation, Certificate Transparency or legal-validity determination.
DNS propagation and cache
Authoritative DNS changes are not instantly visible everywhere. Recursive resolvers can retain the old record until TTL expiry, and mailbox providers may cache BIMI assets or eligibility decisions on their own schedule. Confirm the new record from multiple public resolvers before assuming the provider has evaluated the latest version.
Structurally ready versus guaranteed display
Structurally ready means the public record, DMARC posture and referenced files satisfy the checks the tool can perform. Guaranteed display does not exist: the receiver remains free to reject the indicator, delay it, show it only in some interfaces, or remove it when reputation or policy changes.
Frequently asked questions
How long does BIMI take to appear after a DNS change?
There is no universal delay. First wait at least for the published DNS TTL, then allow for provider-specific caching and eligibility review. A long delay does not by itself prove that the record is wrong.
Is p=quarantine enough if pct is below 100?
No for the usual BIMI enforcement baseline. The policy must apply at full percentage; pct below 100 means part of the stream is not covered by enforcement.
Why does MXFend say structurally ready when the logo is still missing?
The tool can verify public structure and observable fetch results. It cannot evaluate every provider's private reputation, account, certificate and display rules, so readiness is not a display promise.
Should I keep changing DNS until the logo appears?
No. Once the record is structurally correct, wait for TTL and provider caches, verify provider support and review sender reputation. Unnecessary repeated changes can prolong troubleshooting.