🛈 BIMI Checker
Check whether a domain's BIMI record is published correctly, whether the SVG logo it points to is reachable and valid, whether a VMC or CMC authority indicator is attached, and whether the DMARC enforcement BIMI depends on is actually in place.
What Is BIMI and What Does This Checker Actually Verify
BIMI (Brand Indicators for Message Identification) is an email specification that lets a domain publish its own logo so that supporting mailbox providers display it next to authenticated messages, in place of the generic sender avatar most inboxes fall back to. Unlike SPF, DKIM, or DMARC, BIMI adds no authentication of its own — it is a visual layer that only activates once a domain's underlying authentication is already fully enforced. BIMI is specified in an active IETF draft rather than a finalized RFC. This checker performs the same sequence a receiving mailbox provider effectively performs: it resolves the BIMI TXT record at the selector you specify, parses the l= and a= tags inside it, confirms the SVG logo file the l= tag points to is actually reachable over HTTPS, and separately checks whether the domain's DMARC record is enforced strongly enough for BIMI to even be eligible to display in the first place.
Because BIMI sits at the intersection of DNS, email authentication, trademark law, and strict file-format compliance, a record can look correct at a glance and still fail to render anywhere, for reasons that have nothing to do with DNS syntax. This tool is built to surface exactly which of those layers — the TXT record, the DMARC prerequisite, the logo file itself, or the certificate — is the one actually blocking display, rather than just confirming a record exists.
How the BIMI Checker Works
Enter a domain and, optionally, a non-default selector, then run the check. The tool issues a DNS-over-HTTPS TXT query for [selector]._bimi.yourdomain.com (defaulting to the selector default when none is provided), exactly matching how a real BIMI-supporting mailbox provider looks up the record on incoming mail. It then parses the returned string for the required v=BIMI1 version tag, the l= logo location tag, and the optional a= authority (certificate) tag. If an l= value is present, the checker attempts to fetch it directly to confirm it resolves over HTTPS, returns a file, and that the file at least superficially resembles a valid SVG document. In parallel, it queries _dmarc.yourdomain.com to confirm a DMARC record exists and is set to a policy of quarantine or reject at 100%, since a BIMI record published under a monitoring-only DMARC policy will not be honored by any provider regardless of how correctly it's formatted.
BIMI Record Requirements at a Glance
| Requirement | Detail | Checked by this tool |
|---|---|---|
| DMARC enforcement | p=quarantine or p=reject, pct=100, at the organizational domain | Yes |
| BIMI TXT record | Published at default._bimi.yourdomain.com (or a chosen selector), starting v=BIMI1 | Yes |
| l= logo tag | Fully qualified HTTPS URL pointing directly at an SVG Tiny PS file | Yes, including reachability |
| SVG format | Restricted SVG Tiny Portable/Secure profile — no scripts, no external references | Basic structural check |
| a= authority tag | Optional per spec; HTTPS URL to a VMC or CMC certificate file | Yes, when present |
| Certificate validity | Issued by an authorized CA, matching domain and logo, not expired | Reachability check only |
Why DMARC Enforcement Is a Hard Prerequisite, Not a Suggestion
BIMI's entire trust model is borrowed from DMARC. A mailbox provider only displays a BIMI logo because DMARC enforcement already guarantees, with reasonable confidence, that a message genuinely came from the domain it claims to be from — BIMI simply gives that already-trusted sender a visual reward. If DMARC is still at p=none, spoofed mail claiming your domain could theoretically be delivered right alongside your real mail, and no provider is willing to attach a trusted logo to a domain that hasn't actually locked that door yet. This is why every major BIMI implementation, without exception, requires enforced DMARC at or near full percentage before it will even consider looking at the BIMI record. Domains attempting to publish BIMI while still in a DMARC monitoring phase are effectively wasting the effort until enforcement catches up — use DMARC Lookup to confirm your policy status first, and if you haven't published a DMARC record yet, the DMARC Record Generator builds one in the correct format.
Reading Your BIMI Check Results
A clean result shows a resolvable TXT record beginning with v=BIMI1, a reachable l= logo URL that returns a valid SVG file, DMARC enforced at quarantine or reject with pct=100, and — for compatibility with the widest set of mailbox providers — a reachable a= certificate URL. Any one of these can fail independently while the others pass, which is exactly why partial results are common: a domain might have a perfectly valid record and logo but no certificate, meaning it will display correctly in providers that don't require VMC but not in Gmail; another domain might have a valid record and certificate but a logo file that fails strict SVG Tiny PS validation, meaning nothing displays anywhere despite looking complete on the surface.
Mailbox Provider Support Differences
| Provider | Displays BIMI without VMC? | Notes |
|---|---|---|
| Gmail / Google Workspace | No | Requires a valid VMC referenced in a= before displaying any logo |
| Yahoo / AOL | Partially | Has supported BIMI without a certificate in some periods; requirements have shifted over time |
| Apple Mail (iCloud) | No | Requires VMC; rolled out BIMI support later than Gmail and Yahoo |
| Fastmail | Yes | Has historically displayed BIMI logos without requiring a certificate |
Because provider policy changes independently and without much public notice, treat the table above as a general pattern rather than a permanent guarantee — the safest approach for broad compatibility is always publishing a valid VMC where you have a qualifying trademark, and re-checking your live record periodically with this tool.
Common BIMI Errors This Checker Flags
| Symptom | Likely Cause |
|---|---|
| No TXT record found at the selector | BIMI record was never published, or was published at a different selector than the one checked |
| Record found but doesn't start with v=BIMI1 | Malformed record — receivers will disregard it entirely, identically to having none |
| l= URL unreachable or times out | Logo file moved, hosting expired, or HTTPS misconfiguration on the logo's host |
| l= URL reachable but not valid SVG | File extension is SVG but content is HTML (a redirect page), corrupted, or a different image format entirely |
| DMARC not enforced | Policy is still p=none, or pct is below 100 — BIMI will not display in any supporting provider until this changes |
| a= present but certificate unreachable | Certificate file removed, expired hosting, or URL typo — logo may still show in non-VMC-requiring providers only |
BIMI Checker vs Manually Checking with dig or nslookup
Experienced administrators can certainly run dig TXT default._bimi.example.com themselves, and that command will show the raw record just as accurately as this tool does. What a manual DNS query doesn't do is follow through on the rest of the chain: it won't fetch the l= URL to confirm the logo actually loads, won't flag a script tag hiding inside an otherwise-valid-looking SVG, and won't cross-reference the domain's DMARC policy to tell you whether the record even has a chance of displaying anywhere. This checker exists specifically to collapse that multi-step manual process — DNS query, DMARC query, HTTPS fetch of the logo, HTTPS fetch of the certificate, and a structural SVG check — into a single pass, which is normally where the actual troubleshooting time goes once the DNS record itself is confirmed to exist.
Security Considerations
BIMI does not authenticate mail and provides no protection on its own — its entire value depends on the DMARC enforcement sitting underneath it actually being correct and actively blocking unaligned mail. Never treat a correctly displaying BIMI logo as evidence that your authentication setup is secure; verify SPF, DKIM, and DMARC independently with SPF Lookup, DKIM Lookup, and DMARC Lookup regardless of whether BIMI is displaying correctly.
Troubleshooting After Publishing
If this checker shows a fully valid record, reachable logo, and enforced DMARC, but the logo still isn't appearing in a specific inbox, the most common remaining causes are provider-side caching (give it several days), a missing VMC for a provider that requires one even though the record itself is otherwise complete, or that specific provider simply not supporting BIMI at all yet. Re-run the check after any DNS or hosting change, and confirm the certificate (if used) hasn't quietly expired, since an expired VMC commonly causes a logo that was working to stop displaying with no other symptoms. It's also worth re-checking after any CDN, hosting migration, or SSL certificate renewal on the domain serving your logo file, since any of those can silently change the response headers or availability of the SVG without anyone touching the BIMI record itself.
Real-World Use Cases for Checking BIMI Regularly
Marketing and brand teams use this checker before a major campaign launch to confirm the logo is actually going to appear in the inbox rather than assuming it once it was set up months ago — certificates expire and hosting changes silently break things that nobody notices until someone asks why the logo disappeared. Email deliverability teams run it as part of a broader authentication audit alongside SPF, DKIM, and DMARC whenever onboarding a new sending domain or subdomain for a product line. Security teams use it defensively too: confirming that a domain's DMARC enforcement genuinely meets the BIMI threshold is a useful, concrete way to verify that authentication rollout claims match reality, since BIMI eligibility is essentially an external, provider-checked confirmation that enforcement is real. Agencies managing BIMI on behalf of multiple client domains use the custom selector field to test a redesigned logo on a staging selector before cutting the live default record over, avoiding any risk to a brand's currently working setup while a new certificate or logo file is being finalized.
Related Reading
For the foundational concept, start with What Is BIMI?. For every requirement laid out in full technical detail, read BIMI Requirements. For building a compliant logo file, see SVG Logo for BIMI. For the certificate process end-to-end, read Verified Mark Certificate (VMC). To understand exactly how BIMI and DMARC relate to and depend on each other, see BIMI vs DMARC.