BIMI Checker

BIMI (Brand Indicators for Message Identification) lets mailbox providers such as Gmail, Yahoo and Apple Mail show your logo next to messages from your domain. The logo appears only when the message passes DMARC and your domain meets the provider's requirements, so BIMI builds on email authentication rather than replacing it.

A working BIMI setup has four parts:

This checker follows the steps a receiving mail server takes: it looks up the record at the default selector (and at your organizational domain if the domain itself has none), reads the DMARC policy that applies, downloads the logo and the certificate over HTTPS, checks the logo against the SVG Tiny PS profile, verifies the certificate chain up to a BIMI certificate authority and compares the logo inside the certificate with the one at l=.

What it cannot see: your sending reputation, which providers also weigh, and a custom selector chosen per message with a BIMI-Selector header. It does not check whether a certificate has been revoked; the result says so.

The verdict is Pass, Warning, Fail or Could not check. BIMI is optional, so a domain without a record gets a warning, not a failure. Once a record exists, problems that stop the logo from showing are failures.

Pass: BIMI is set up correctly

The record is valid, DMARC is at enforcement, the logo is a valid SVG Tiny PS file and the mark certificate checks out for this domain and logo. Whether a provider then shows the logo also depends on things we cannot see from outside, such as your sending reputation or, at Yahoo, whether the message is bulk mail. Google says a new record can take up to 48 hours to show.

No BIMI record

We found no TXT record starting with v=BIMI1 at default._bimi.<domain> or at the organizational domain. Nothing is broken; the logo just is not shown. The fix under the result gives a record template. Before you publish it, get DMARC to enforcement and prepare the logo (see how to set up BIMI). While there is no record, DMARC problems are shown as warnings.

The BIMI record

• Valid (Pass): starts exactly with v=BIMI1; and has an HTTPS logo URL in l=.
• Look-alike record (Fail): v=bimi1, V=BIMI1, v=BIMI1 without the ; after it, or v= not first. Receivers must not fix such records, so they ignore them. Next to a valid record, a look-alike is only a warning.
• More than one record (Fail): with two v=BIMI1 records at the name, receivers use neither. Keep one.
• Missing or invalid l= (Fail): l= is required and must be one https:// URL of an SVG file. A .png or .jpg URL is an error. Tag names are case-sensitive: L= is not l=.
• Empty l= with a certificate in a= (Warning): this is the form in Gmail's example, but the BIMI draft says the logo must not be shown without a valid l=, and Yahoo asks for a record that points to an SVG logo. Put the logo URL in l= as well.
• Invalid a= (Fail): a= must be one https:// URL with a full domain name. A URL that does not end in .pem is a warning.
• Repeated tags or broken syntax (Fail): a tag written twice makes the whole record invalid. Tag names in capitals (A=, Avp=) are a warning: receivers treat them as unknown tags.
• Declined (Warning): v=BIMI1; l=; a=; is a deliberate “do not show a logo”. proton.me, for example, had such a record when we checked on 22 September 2026.

Selectors and lps=

A sender can choose a record other than default per message with a BIMI-Selector header, for example to show a different logo for one brand. This page checks the default selector, which is what receivers use without that header. The optional lps= tag lists local-part prefixes (the part of the address before the @) that use their own selector; it may contain only letters, digits and hyphens, and we warn if it contains anything else. With lps= and empty l= and a=, the record declines BIMI only for the addresses that do not match a prefix.

DMARC must be at enforcement

BIMI requires a DMARC policy of quarantine or reject on your domain and on its organizational domain. Gmail states that BIMI does not support p=none and that pct must be 100. Findings you may see:

• No DMARC record, or p=none (Fail once a BIMI record exists): publish or raise the policy. The fix shows your record rewritten; move to enforcement only when your DMARC reports show that all your real mail passes.
• t=y: the testing flag of RFC 9989 lowers the policy one step, so p=quarantine; t=y counts as none (Fail) and p=reject; t=y as quarantine (Warning: the draft accepts quarantine, but whether mailbox providers show logos for a domain in test mode we have not verified).
• pct below 100: a failure with quarantine; a warning with reject, because the draft allows it but Gmail does not.
• sp=none (Fail): a subdomain policy of none on your domain or its organizational domain stops BIMI.
• The organizational domain has no DMARC (Warning): for mail.example.com the draft also requires a policy on example.com.
• Several DMARC records (Warning): receivers ignore all of them (receivers on the older DMARC rules then apply no DMARC policy at all). Keep one.

The logo: SVG Tiny PS

The logo at l= must be an SVG file in the SVG Tiny PS profile, a restricted form of SVG without scripts, animation, links, embedded images or external references. The root element needs baseProfile="tiny-ps" and version="1.2", and the file needs a non-empty <title>. We check the file against the profile's closed list of elements and attributes and name each problem. Export tools often add things the profile does not allow: x and y on the root element, style attributes, <style>, <clipPath> or editor metadata.

• Could not fetch: a 404 or a host that does not exist is a failure; a timeout, HTTP 5xx or 429 is “could not check”.
• Size: the profile says the file should not exceed 32 KB (Warning). Above 128 KB we stop reading and cannot check the profile, which shows as a size warning and “could not check”.
• DOCTYPE or ENTITY declarations: we do not parse such files, for safety. SVG Tiny 1.2 needs no DOCTYPE; remove it.
• Content-Type other than image/svg+xml is a warning.

Gmail requires the logo to be at least 96 by 96 pixels, with the size given in absolute pixels, and recommends centering it in a square on a solid background.

The mark certificate (VMC or CMC)

The file at a= is a PEM file: your mark certificate first, then the certificate of its issuer. We check that every signature leads to a recognized BIMI certificate authority, that no certificate in the chain has expired, that it is a mark certificate (it carries the BIMI key usage), that it names your domain, and that the logo inside it is the same file as the logo at l=.

• No a= (Warning): Gmail needs a certificate; Yahoo says it does not currently require one, but sets other conditions (see below). Apple Mail shows the logo with a VMC (iOS 16 and macOS Ventura and later); whether Apple accepts a CMC, Apple does not say.
• Expired, wrong order, missing intermediate (Fail): renew the certificate, or publish the full chain in the order your issuer delivered it.
• Issued for another domain (Fail): the certificate must name this domain or its organizational domain.
• Logo mismatch (Fail): put exactly the SVG your certificate was issued for at l=.
• A private key in the file (Fail): anyone can download it. Revoke the certificate with your issuer and publish the certificates only.
• Expires within 30 days (Warning): renew it in time.

A passing certificate result says that the signatures, dates, BIMI key usage, domain and logo check out. We do not check revocation or Certificate Transparency signatures; the certificate rules require receivers to check both.

Could not check

A DNS lookup failed or timed out, a web server did not answer in time or returned a temporary error, or one of our safety limits stopped part of the check (the result lists it). This is not a pass and not a fail. Try again in a minute.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to [email protected] with the address of the result page, and we will fix it.

1. Get DMARC to enforcement. Publish p=quarantine or p=reject at _dmarc.example.com, without pct below 100. Do it only after your DMARC reports show that all the services sending as your domain pass DMARC.
2. Prepare the logo as a square SVG in the SVG Tiny PS profile. Plain SVG exports from design tools usually need cleaning up first; this check names every element and attribute the profile does not allow.
3. Get a mark certificate if you want the logo in Gmail: a VMC, which needs a registered trademark for the logo, or a CMC. The BIMI Group lists the certificate authorities that issue them.
4. Host both files over HTTPS, for example https://example.com/bimi/logo.svg and https://example.com/bimi/vmc.pem, on a server with a valid certificate.
5. Publish the TXT record at default._bimi:

   v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem

   Without a certificate, leave out a=: v=BIMI1; l=https://example.com/bimi/logo.svg.
6. Check it here. Google says the logo can take up to 48 hours to appear.

What Gmail, Yahoo and Apple require

• Gmail: DMARC p=quarantine or p=reject with pct 100, a VMC or CMC, and a record that points to the PEM file. Google's own example leaves l= empty; we recommend filling it, because other receivers read the logo from there. Google also warns that the number 1, capital I and lower-case l look alike in record values: copy, do not retype.
• Yahoo: shows a logo only when all of these hold: the BIMI record points to a valid SVG logo, the DMARC policy is quarantine or reject, the message is bulk mail (Yahoo does not show brand logos on personal email), and Yahoo sees enough reputation and engagement for the sending address. A VMC is not currently required; if the record includes one, Yahoo uses it when deciding eligibility.
• Apple Mail: shows the logo with a VMC (iOS 16 and macOS Ventura and later) when the sender meets Apple's requirements; whether Apple accepts a CMC, Apple does not say.

Google Workspace, Microsoft 365, SendGrid, Mailgun, Amazon SES, Zoho

BIMI does not depend on which service sends your mail: the record, the logo and the certificate belong to your domain. What each sending service must do is pass DMARC for your domain, which means an aligned DKIM signature (or aligned SPF). Check that with each service before you raise DMARC to enforcement.

Cloudflare

1. Open the domain's DNS Records page and select Add record.
2. Type TXT, Name default._bimi, Content your record, for example v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem.
3. Select Save. Cloudflare adds the quotes around the value itself.

GoDaddy

1. In your Domain Portfolio, select the domain, then DNS and Add New Record.
2. Type TXT, Name default._bimi, Value your record. Keep the default TTL and select Save.

Namecheap

1. Open Domain List, Manage, the Advanced DNS tab and Add New Record.
2. Choose TXT Record, Host default._bimi (without your domain), Value your record, then Save all changes.

The record and the DMARC policy it depends on are ordinary TXT records:

dig +short TXT default._bimi.paypal.com
dig +short TXT _dmarc.paypal.com

On 22 September 2026 they returned (the DMARC record shortened):

"v=BIMI1; l=https://www.paypalobjects.com/marketing/web/logos/paypal_ppe.svg; a=https://www.paypalobjects.com/marketing/web/logos/PPE_UK_DE_paypal_inc.pem"
"v=DMARC1; p=reject; rua=mailto:…"

A command-line lookup shows only the record. Whether the logo passes the profile and the certificate matches it needs the checks above.