Inputs
Example
default._bimi.example.com -> v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem.
Check BIMI records, DMARC readiness, logo and certificate URLs, and generate a conservative BIMI TXT draft.
Use it to check a BIMI record, the DMARC enforcement context, and a generated DNS draft before publishing.
default._bimi.example.com -> v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem.
BIMI is the visible payoff for invisible work: a brand logo next to your mail, granted by receivers only after a domain has proven itself. That proof is the part people underestimate — the logo display generally depends on an enforced DMARC policy, and often on a Verified Mark Certificate as evidence for the logo's legitimacy. The BIMI TXT record itself is almost trivial; the deployment fails or succeeds on everything it points at and everything it presumes.
This checker reads a domain's BIMI readiness as a whole: the record under its selector owner name, tag syntax, the logo URL and its reachability, optional VMC or CMC evidence, and — because nothing works without it — the DMARC dependency. It also drafts a conservative DNS value, so the record you publish is derived from checked inputs rather than assembled from a blog post.
Start with domain and selector — default._bimi is the usual owner name — and fetch the current BIMI and DMARC records, or paste both when working from zone data. Read the DMARC readiness verdict first: with p=none, most receivers will not display a logo regardless of how perfect the rest is, so tightening DMARC is usually the actual project and BIMI is its final step.
Then review what the record points at. The logo must be an SVG in the Tiny Portable/Secure profile, served over HTTPS from a stable URL — treat that URL as production infrastructure, because receivers fetch it on their own schedule. Publish the a= evidence tag only when a real certificate exists; an evidence URL that returns errors is worse than no evidence tag at all. When the findings are clean, take the generated DNS value, publish it, and re-run the check against live DNS to close the loop.
Pasted records stay in the browser. Live DNS queries only the BIMI and DMARC owner names, using DNS-over-HTTPS first with the same-origin DNS helper as fallback, and only when you request them. SVG profile conformance and VMC/CMC evidence are assessed as readiness signals, not cryptographically verified — final logo display remains each receiver's decision, applying its own policy on top of everything this page can see.
selector._bimi.domain — with default as the customary selector, so default._bimi.example.com in most deployments. Multiple selectors are possible when different mail streams should present different marks.
Because the logo is a trust statement, and receivers only extend it to domains that enforce authentication. An enforced DMARC policy — quarantine or reject — is the practical entry ticket; p=none rarely results in logo display.
The optional a= tag can point to a Verified Mark Certificate or Common Mark Certificate that attests your right to the logo. Some large receivers require it for display; without it, BIMI remains self-asserted and treated more cautiously.
Because receivers render it in security-sensitive mail contexts and demand a strict profile: no scripts, no external references, no animations. An ordinary SVG export usually fails the profile even though it looks identical.
No. The record and URLs are analyzed, and the browser loads a preview only when the URL is public and reachable. Nothing is stored or submitted anywhere by the page.
Because display is the receiver's decision, not the record's. Common causes: DMARC not enforced, missing VMC where required, an unreachable or non-conformant SVG, or a sender reputation that has not earned display yet. The record is necessary, never sufficient.