This free BIMI check reads the default._bimi record on your domain and tells you whether it is set up to put your brand logo in the inbox: the l= logo URL, the optional a= Verified Mark Certificate, the new avp= avatar-preference tag, and – most importantly – whether your DMARC policy is enforced, because without that no mailbox provider will ever show the logo. Check your domain → Need a record? The free BIMI generator builds it, including the new avp tag.
BIMI (Brand Indicators for Message Identification, specified by the AuthIndicators Working Group) lets you publish your logo in DNS so participating mailboxes – Gmail, Apple Mail, Yahoo and others – can display it next to your messages. The scanner looks up the TXT record at default._bimi.<domain>, confirms it starts with v=BIMI1, and parses each tag:
A minimal record looks like this:
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"The scanner surfaces the logo URL and any VMC or avp preference it finds. BIMI is treated as informational when it is set up correctly: a well-configured record earns a positive note without inflating the score, and a missing one is never penalised. It becomes a warning whenever a record could work but does not verify: an unfetchable logo, an SVG carrying active content or without the SVG Tiny P/S declaration, a mark certificate that is missing, not https, unreachable, unreadable, expired or not from a listed Mark Verifying Authority, a served logo that differs from the one bound into that certificate, or an invalid avp= value. It becomes a failure when the record cannot display anything at all: an l= URL that is not https, more than one v=BIMI1 record, no l= tag, or an empty l= published next to a mark certificate. An explicit opt-out – v=BIMI1; l=; a=; – is a valid configuration and is only noted, never marked down. The one exception to the weight-zero rule is a BIMI record published while DMARC is not yet enforced, which the scanner flags as a warning (see below).
The l= tag must point at an https:// URL that serves an SVG Tiny Portable/Secure (SVG P/S) image. This is a deliberately locked-down profile of SVG Tiny 1.2: no scripts, no external references, no animation and a single fixed viewBox, so the file cannot become an attack vector or pull in tracking. Mailbox providers additionally expect a square logo that renders cleanly at small sizes, typically with a solid background rather than transparency.
The check does not just read the l= tag: it fetches the file over HTTPS – up to 64 KB; a larger file is reported as exceeding this check's download limit and is not analysed, rather than as a logo that would not load – and looks at it: whether a complete SVG arrives, whether it carries active content (script, foreignObject, javascript: URLs or inline event handlers), and whether it declares the SVG Tiny P/S profile (baseProfile="tiny-ps") that Gmail and Apple Mail require. It does not validate every rule of that profile, and it does not re-encode or repaint your artwork – converting a normal SVG or a raster logo into a compliant SVG P/S file is a one-time design task. If you do not have a compliant file yet, the BIMI generator helps you assemble the record around it once the SVG is ready.
The optional a= tag references a Verified Mark Certificate (VMC) – an X.509 certificate, delivered as a PEM file over HTTPS, that binds your logo to a trademark you have registered. Gmail and Apple Mail show your logo only when the record carries a mark certificate; Yahoo displays it without one. The two certificate types are not interchangeable. A Verified Mark Certificate (VMC) requires a registered trademark, is accepted by both Gmail and Apple Mail, and is the only one that earns Gmail’s verified checkmark. A Common Mark Certificate (CMC) is open to senders without a trademark and gets the logo displayed in Gmail – but without the checkmark, and Apple Mail does not accept it. The scanner does not stop at the tag. Whenever the logo URL is https, it fetches the PEM over HTTPS and checks the certificate itself: the BIMI extended key usage (id-kp-BrandIndicatorforMessageIdentification, OID 1.3.6.1.5.5.7.3.31), which the Mark Certificate Guidelines require of a VMC and a CMC alike, the validity window, whether the chain terminates at one of the Mark Verifying Authority roots the BIMI Group lists (DigiCert, GlobalSign, SSL.com – a pinned set of its own, separate from the web PKI), and whether the logo you serve is byte-for-byte the image the CA bound into the certificate (logotype extension, RFC 9399, which obsoletes RFC 3709). If our own fetch fails, the report says so rather than blaming your record. What it cannot check is the trademark registration behind the certificate – that is the certificate authority’s job, and you can inspect the PEM directly.
The avp= tag is a more recent addition to the BIMI specification. Its value is case-sensitive: avp=brand is the default and asks providers to prefer your brand logo, while avp=personal asks them to prefer the individual sender's personal avatar (for example a profile photo) over the logo. The scanner reads the preference and shows it; any value other than personal or brand is flagged as invalid; receivers ignore it, and a mailbox provider may additionally treat an invalid value as a failing record, in which case no logo is shown at all.
BIMI only works on top of a strong authentication posture. A logo is displayed only when your DMARC policy is at enforcement – that means p=quarantine or p=reject, without a testing flag t=y, and with a subdomain policy sp that is not none. With p=none the record is valid but purely observational, and no provider will render the logo.
The pct tag is a separate matter, and the sources disagree about it. The BIMI draft requires pct=100 only where the policy is p=quarantine; for p=reject it accepts the record “with any percentage value”. The BIMI Group’s implementation guide draws no such distinction and states that a pct below 100 is not accepted at all. This scanner follows the stricter of the two and treats any pct below 100 as blocking, because the two ways of being wrong do not cost the same. Removing the tag is not free – receivers on the current specification already ignore pct, but receivers still on RFC 7489 apply your policy to only part of your mail, and deleting it lifts them to full enforcement, so align every sending path first. That is work you owe anyway; a logo that never appears has already cost you a certificate.
Because of that, the scanner cross-checks your BIMI record against your live DMARC policy. If BIMI is published but DMARC is not enforced, it raises a warning that the record is currently ineffective, with the exact reason. When DMARC is enforced and a logo is present, the BIMI finding is positive. The practical order of work is always the same: get DMARC to p=quarantine or p=reject with full coverage first, then publish the BIMI record and, if you want the verified badge, add the VMC. If you are still working out how to get there, the DMARC reference walks through the rollout, the tags and the reports in detail.
The most common reason is DMARC. BIMI only displays the logo when your DMARC policy is at enforcement – p=quarantine or p=reject, applied to all mail, without t=y and with sp not set to none. With p=none the record parses fine but no mailbox provider will render the logo. Bring DMARC to enforcement first, then re-test.
Not for every provider. A BIMI record with just an l= logo URL and enforced DMARC is enough for some inboxes to show your logo. A Verified Mark Certificate, referenced with the a= tag, is what unlocks the blue verified badge in providers like Gmail. The free check tells you whether an a= tag is present, but it downloads the certificate, checks the BIMI extended key usage (id-kp-BrandIndicatorforMessageIdentification) that both certificate types carry and the validity window, verifies that the chain terminates at a listed Mark Verifying Authority root, and compares your served logo with the image bound into the certificate. It cannot confirm the trademark registration behind it.
avp is the avatar-preference tag. avp=brand is the default and asks providers to prefer your brand logo, while avp=personal asks them to prefer the individual sender's personal avatar over the logo. The value is case-sensitive, and anything other than personal or brand is treated as brand. The check reads this preference and shows it in the result.
BIMI Group ↗ · draft-brand-indicators-for-message-identification (BIMI specification) ↗ · RFC 9989 (DMARC) ↗
← All security tests by topic · Run the full domain security check