How BIMI Inspection Works: DNS Records, Selectors, SVG Logos and DMARC

Overview

BIMI configuration lives in the DNS TXT namespace under a selector: the conventional record sits at default._bimi.example.com, and a non-default selector produces a different name, <selector>._bimi.<domain>. The selector is not something an inspector can safely guess by trying common values — it is a value the sending platform puts in a message's own BIMI-Selector header, so checking the wrong selector can look identical to 'no BIMI configured' even when a record exists under a different name.

At that DNS name, a compliant record starts with v=BIMI1 and typically carries an l= tag pointing to an HTTPS SVG logo and an optional a= tag pointing to an HTTPS evidence document such as a Verified Mark Certificate or Common Mark Certificate. Finding more than one record at the same selector is itself a problem: BIMI expects exactly one record per selector, and a receiver faced with multiple candidates has no defined way to pick between them.

Why it happens

Each layer of a BIMI inspection exists to answer a narrow question, and the layers are deliberately independent so that a failure in one does not get misread as a failure in another. DNS resolution answers whether a record exists at the selector actually in use. Record parsing answers whether that record is syntactically valid BIMI1 with usable HTTPS tags. Fetching the logo answers whether the l= URL is publicly reachable at all — a completely separate question from whether the bytes returned are a compliant SVG. DMARC discovery answers whether the domain is enforcing authentication, which BIMI treats as a prerequisite rather than something it checks itself: BIMI does not authenticate mail, so it depends on DMARC having already done that job at enforcement strength, not merely in monitoring mode.

How to fix it

Work through the layers in order and stop at the first real failure, rather than jumping ahead to provider-specific questions before the structural chain is clean:

1. Selector — confirm the selector the sending platform actually uses (default, or the value from a real message's BIMI-Selector header). Checking the wrong selector produces a false 'not configured' result.
2. DNS record — resolve <selector>._bimi.<domain> and confirm exactly one record is returned, with a valid v=BIMI1 tag and an HTTPS l= tag.
3. Logo — fetch the l= URL directly, outside a browser, and confirm it succeeds without a login wall, redirect loop or wrong content type. Reachability is a DNS/hosting question, separate from step 4.
4. SVG compatibility — check the fetched file itself against the SVG Tiny PS profile: baseProfile, a square viewBox, a title element, and the absence of scripts, external references or animation. A file that opens fine in a browser can still fail this step, because browsers accept a far broader SVG feature set than the constrained profile mailbox renderers expect.
5. Evidence document — if an a= tag is present, fetch it separately from the logo and check that the returned bytes are a structurally parseable certificate. This step is about the file's structure, not about the logo, and not about whether the certificate is trusted.
6. DMARC prerequisite — confirm the domain's effective DMARC policy is actually enforced (quarantine or reject, not none), not merely published in monitoring mode.
7. Provider-specific policy — only after every earlier step is clean does it make sense to look at an individual mailbox provider's own eligibility, reputation and display rules, since those decisions happen after every structural check has already passed.

The BIMI Inspector runs this exact sequence and reports the DNS record, selector, logo and evidence findings, and DMARC readiness in one pass. For a faster read on just the record and DMARC prerequisite without a full logo and evidence fetch, the BIMI Checker covers that narrower first slice.

DNS record example

Examples

A domain can have a perfectly valid v=BIMI1 record with a reachable l= URL, and still fail inspection because the SVG lacks baseProfile="tiny-ps" — a file that renders correctly in every browser but was never exported for the constrained profile. Separately, a domain can have a compliant record and logo but DMARC still at p=none: the DNS layer and the SVG layer both pass, and the configuration is still not ready, because the DMARC layer is an independent prerequisite, not something a valid BIMI record can substitute for.

Common mistakes

Common inspection mistakes include checking default._bimi when the real mail stream uses a different selector, treating a successful logo fetch as proof the SVG is BIMI-compatible, treating a parseable evidence certificate as proof it is trusted, treating DMARC p=quarantine with pct below 100 as full enforcement, and treating a fully structurally ready result as a promise that a logo will display in any specific inbox.

Checklist

• The selector checked matches the one the sending platform actually uses.
• Exactly one BIMI1 TXT record exists at <selector>._bimi.<domain>.
• The l= logo URL is HTTPS, publicly reachable, and returns the SVG itself.
• The fetched SVG passes SVG Tiny PS structural checks, not just 'opens in a browser'.
• Any a= evidence document is checked separately from the logo, and only for structural validity.
• DMARC is confirmed enforced (quarantine or reject) rather than assumed from a published record.
• Provider-specific eligibility is treated as a separate, later question — not a DNS or SVG fix.

DNS validity is not the same as asset validity

A logo URL resolving over HTTPS and returning a 200 response only confirms that the location is reachable. It says nothing about whether the file at that location is a compliant SVG. Keeping these as two separate checks — can the URL be fetched, and is the fetched content valid — avoids the common error of treating 'the link works' as 'the logo is ready'.

The evidence document is not the logo

The a= evidence document and the l= logo are separate files serving separate purposes, fetched and checked independently. An inspection of the evidence document is limited to whether the returned bytes structurally parse as a certificate — subject, issuer, validity dates and similar fields read from the certificate's own content. That is not the same as verifying the certificate against a trust store, checking revocation, checking Certificate Transparency, or confirming legal trademark ownership. Structural parsing and trust are different questions, and a tool that only does the former should say so plainly rather than implying the latter.

Publishing BIMI is not the same as enforcing DMARC

A BIMI record can be published correctly on a domain whose DMARC policy is still p=none — monitoring only, not enforcement. BIMI treats DMARC enforcement as a prerequisite it depends on rather than something it establishes itself, so a structurally valid BIMI record on a monitoring-only domain is not ready, regardless of how correct the record and logo are.

Structurally ready is not guaranteed display

Every check described here — DNS, selector, record syntax, logo reachability, SVG structure, evidence-document structure, DMARC enforcement — describes what a domain has published and whether it is internally consistent. None of it obligates any mailbox provider to display anything. Participating providers apply their own eligibility, sender-reputation, certificate and interface-specific policy on top of a structurally ready configuration, and that layer sits outside what DNS and asset inspection can observe.