How BIMI Inspection Actually Works: DNS Records, Selectors, SVG Logos and DMARC
BIMI looks simple at first glance: publish a DNS record, point it at a logo, and wait for mailbox providers to display it.
In practice, there are several independent pieces that have to line up:
- the BIMI Assertion Record must exist at the expected DNS name;
- the correct selector has to be queried;
- the logo location has to be reachable;
- the SVG has to meet BIMI-specific constraints;
- the optional evidence document has to be valid for the intended use;
- DMARC must meet BIMI's enforcement prerequisite;
- and even then, mailbox providers can still apply their own eligibility, reputation, and policy checks.
This article walks through the inspection process from the DNS query outward.
1. Start with the BIMI DNS name
The conventional BIMI selector is default.
For a domain such as:
example.com
the first DNS name to inspect is:
default._bimi.example.com
A BIMI implementation can use a non-default selector, but it should not blindly guess or enumerate selectors. A specific selector is normally relevant when the message or sender configuration actually requests one.
That distinction matters because "no record at default" and "BIMI is not configured anywhere for this domain" are not necessarily the same statement.
2. Inspect the published BIMI Assertion Record
A BIMI record is published as DNS TXT.
A simplified record may look like:
v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/evidence.pem;
The important parts are:
-
v=— BIMI version; -
l=— logo location; -
a=— evidence document location, when present.
An inspector should not stop at "a TXT record exists." It should also check whether the record is structurally usable and whether there are ambiguous or conflicting records.
Multiple BIMI records for the same selector are especially important to surface rather than silently merging or choosing one.
3. The selector is part of the inspection
The selector is not just a UI detail.
It changes the DNS name being queried:
<selector>._bimi.example.com
For example:
default._bimi.example.com
marketing._bimi.example.com
Those are two different DNS records.
A useful BIMI inspector should therefore show the selector it actually queried and the resulting DNS name, so the operator can verify that the inspection matches the sender's intended configuration.
4. Follow the logo location
The l= value points to the logo asset.
An inspector can check things such as:
- whether the URL is present;
- whether it is reachable;
- whether the response is actually an SVG;
- whether the SVG is structurally compatible with BIMI expectations;
- whether obvious asset problems make the BIMI setup unusable.
This is where many apparently "valid" DNS configurations fail in practice.
The DNS record may parse correctly while the referenced logo is unavailable or unsuitable.
5. SVG Tiny PS is not the same as "any SVG"
A normal SVG that renders perfectly in a browser is not automatically suitable for BIMI.
BIMI expects a restricted SVG profile. That means an inspection step should treat "valid XML/SVG" and "BIMI-compatible SVG" as separate questions.
This distinction is useful when troubleshooting a setup that looks correct from DNS alone but still does not satisfy BIMI requirements.
6. Inspect the evidence document separately
The a= location is conceptually separate from the logo.
Depending on the BIMI setup, it may point to an evidence document such as a certificate-related artifact.
A robust inspector should report the evidence location independently rather than treating the logo and evidence document as one combined resource.
This also makes troubleshooting easier:
DNS record: OK
Logo: OK
Evidence location: problem
is much more actionable than a generic "BIMI failed."
7. Check the DMARC prerequisite
BIMI does not operate in isolation from email authentication.
A domain may have a syntactically correct BIMI record and a valid logo, but still not meet BIMI's DMARC enforcement prerequisite.
That is why BIMI inspection should include DMARC state rather than only checking _bimi DNS.
The useful question is not merely:
Does this domain have DMARC?
but rather:
Does the DMARC configuration meet the enforcement prerequisite expected for BIMI?
This is an important difference for domains that are still in monitoring-only mode.
8. A technically correct setup still does not guarantee logo display
This is probably the most important operational point.
Passing all structural checks does not mean Gmail, Yahoo, Apple Mail, or another provider must display the logo.
Mailbox providers can apply additional requirements and their own reputation, eligibility, certificate, or policy rules.
So the result of an inspector should be interpreted as:
The published BIMI configuration is structurally ready
not:
Your logo is guaranteed to appear
That distinction avoids false confidence and makes the tool more useful for debugging.
9. A practical inspection flow
When troubleshooting BIMI, I prefer this order:
- Determine the selector.
- Query
<selector>._bimi.<domain>. - Confirm exactly one usable BIMI Assertion Record.
- Parse the logo and evidence locations.
- Check the logo resource and BIMI SVG compatibility.
- Check the evidence document location when present.
- Verify the DMARC enforcement prerequisite.
- Only then investigate provider-specific eligibility or reputation issues.
This order separates DNS/configuration failures from provider-side display decisions.
10. Inspect a real domain
I built a free BIMI Inspector in MXFend that follows this workflow and shows the queried selector, BIMI record, logo/evidence locations, SVG compatibility, and DMARC prerequisite in one place.
MXFend BIMI Inspector:
https://mxfend.com/bimi-inspector/
There is also a simpler BIMI Checker for a faster basic check:
https://mxfend.com/bimi-checker/
The distinction is intentional:
- BIMI Checker — quick configuration check;
- BIMI Inspector — deeper record, selector, logo/evidence, and DMARC inspection.
Closing thought
BIMI troubleshooting becomes much easier once you stop treating it as one binary DNS check.
It is really a chain:
selector
-> BIMI DNS record
-> logo
-> SVG compatibility
-> evidence document
-> DMARC prerequisite
-> mailbox-provider policy
Inspecting each layer separately gives you a much clearer answer to the only question that matters during debugging:
Which exact layer is preventing this BIMI configuration from being ready?
Originally published on MXFend.
