Email authentication
BIMI checker
Read a domain’s BIMI record, check the SVG logo against Tiny PS, and whether DMARC lets it count.
Free, no accountLive check
Result
The verdict and the record appear here once you press Check BIMI record.
What this is
This BIMI checker reads the TXT record at the default selector, fetches the SVG the record points at and checks it against the SVG Tiny Portable/Secure profile, then checks the DMARC policy behind it - because a logo whose domain is still at "p=none" is ignored no matter how good the file is.
BIMI publishes two things in DNS: where a brand's logo lives, as an HTTPS URL in the "l=" tag, and optionally where the certificate attesting the brand owns that logo lives, in the "a=" tag. Both sit in one TXT record at "default._bimi." plus the domain, written in the same tag-value syntax a DKIM key record uses.
The logo cannot be any SVG. It has to be an SVG Tiny Portable/Secure document: one <svg> root in the SVG namespace, carrying version="1.2" and baseProfile="tiny-ps", with a non-empty <title> and nothing scripted, animated, linked or externally referenced anywhere inside it.
Both documents behind all of this are Internet-Drafts rather than RFCs - draft-brand-indicators-for-message-identification-14 and draft-svg-tiny-ps-abrotman-12, both dated 1 May 2026 - so the rules quoted on this page are a draft's rules, and the two mailbox providers that publish their own requirement are quoted as themselves.
How to read the result
Read the DMARC finding first. It is the gate: the BIMI draft says processing MUST NOT happen at all when the policy is "p=none" or the subdomain policy is "sp=none", so a perfect record and a perfect logo behind a monitoring-only policy still shows nobody a logo.
The file facts under the findings are the raw answer - the size uncompressed, every top-level element, the three root attributes, the dimensions and whether a non-empty title is there - so a failure about the profile can be checked against the file by hand rather than taken on trust.
The provider table is the part worth acting on: a record with no "a=" tag is not broken, it is self-asserted, and that is the difference between a logo at Yahoo and no logo at Gmail.
Common mistakes
What goes wrong most often, and how to tell.
- Publishing the record before DMARC is at enforcementThis is the single most common reason a correct BIMI record shows nothing. The draft treats "p=none" as a hard stop, and BIMI Group makes quarantine or reject on the organizational domain and its subdomains step one of its implementation guide, before any logo exists.
- Pointing "l=" at the logo already on the websiteA marketing PNG, or an SVG exported from a design tool with a script, a link or an embedded bitmap in it, fails the Tiny PS profile - and the BIMI draft makes a non-SVG suffix in the tag a permanent error rather than something a receiver works around.
- Expecting a logo in Gmail without a certificateGoogle's own page says you need a VMC or CMC from a third-party certificate authority and that only PEM files are supported, so an "l="-only record is a Yahoo-and-AOL record. Yahoo says the opposite: it does not require a VMC today.
- Sizing the SVG in percentagesGmail asks for absolute pixels with a minimum height and width of 96, and explicitly says not to use relative dimensions like width="100%". A file that scales perfectly in a browser can still be refused on that rule alone.
Questions
What people ask about this tool.
- Check the DMARC policy before anything else: the BIMI draft stops processing when the policy is "p=none" or the subdomain policy is "sp=none". After that, Gmail needs a VMC or CMC in the "a=" tag, and Yahoo additionally wants bulk volume with sufficient reputation and engagement before it displays anything.
- For Gmail, yes - its documentation says you need a VMC or CMC from a third-party certificate authority and that only PEM files are supported. For Yahoo, no: its sender page says it does not currently require VMCs, though it will use one to inform eligibility if the record includes it.
- The BIMI draft and Google both say that where the policy is "p=quarantine" and a percentage tag is present, it must be "pct=100". RFC 9989, published in May 2026, lists "pct" as historic and replaces part of what it did with the "t" tag - so the two disagree, and the safe reading is not to add "pct" to a new DMARC record for BIMI's sake.
- One <svg> root element with xmlns set to the SVG namespace, version="1.2" and baseProfile="tiny-ps", a <title> that is present and not empty, nothing from the scripting, animation, linking, interactivity or multimedia parts of SVG, no <image> or <switch>, and a file that should stay under 32 kilobytes uncompressed.
- The BIMI draft permits SVGZ as well as SVG in the "l=" tag, but neither Google's nor Yahoo's documentation mentions SVGZ at all, so there is no published confirmation that either would render one. This checker reads the uncompressed file it is served.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “Brand Indicators for Message Identification (BIMI), draft-brand-indicators-for-message-identification-14” read 13 October 2026
- IETF, “SVG Tiny Portable/Secure, draft-svg-tiny-ps-abrotman-12” read 13 October 2026
- BIMI Group, “Creating BIMI SVG Logo Files” read 13 October 2026
- BIMI Group, “Implementation Guide” read 13 October 2026
- Google Workspace Admin Help, “Set up BIMI” read 13 October 2026
- Yahoo Sender Hub, “BIMI - senders.yahooinc.com” read 13 October 2026
- IETF, “RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.