BIMI · Internet-Draft, version 14

BIMI record check: the logo record and the DMARC it depends on

Type a domain to read its BIMI record and the DMARC record beside it. The page says whether the record is valid, and whether the domain's DMARC policy lets a mail client use it.

Check a domain All seven records at once The email doctor grades them

The BIMI record check

BIMI

default._bimi.<domain> · TXT

Not checked yet

The BIMI record, its logo and evidence locations, and whether the DMARC policy meets the conditions BIMI sets.

DMARC

_dmarc.<domain> · TXT

Not checked yet

The DMARC policy that applies to the domain, tag by tag, with the report addresses and whether outside receivers have agreed to them.

What a BIMI record is

BIMI, Brand Indicators for Message Identification, lets a domain publish the location of a logo that a mail client may show beside its authenticated messages. The record is a TXT record at default._bimi.<domain> that begins with v=BIMI1 (BIMI draft 14 §4.3). BIMI is not an RFC. It is described in an Internet-Draft; this page reads records against version 14 of that draft, dated 1 May 2026, which expires on 2 November 2026. A later version may differ.

v=BIMI1; l=; a=;

An explicit refusal to take part: both locations empty. The record of BIMI draft 14 §4.3.1.

How to read it

v=BIMI1 is the version, required and first.
l= is the location of the logo: a single https address, or empty. The only formats the draft accepts are SVG and SVGZ (BIMI draft 14 §4.3.2).
a= is the location of the evidence document, where a mark certificate is published. It is optional and must be an https address when present.
avp= says whether the domain prefers its logo (brand, the default) or the sender's personal avatar (personal); lps= turns parts of the address before the @ into selectors.
Both l= and a= empty is a statement, not an error: the domain declines BIMI for that selector.

Receivers "MUST NOT attempt to fix syntactical or capitalization errors" in a BIMI record (BIMI draft 14 §4.3), so a small mistake switches BIMI off completely.

The DMARC conditions

A logo is only considered for a message that passes DMARC, and only if the domain's DMARC policy has teeth. The draft rules BIMI out when the policy of the domain or of its Organizational Domain is p=none, when a subdomain policy is sp=none, and when the policy is p=quarantine with a pct tag other than pct=100 (BIMI draft 14 §7.1). The checker reads the DMARC record that applies to the domain and says which of these conditions, if any, stands in the way. The DMARC checker shows that record in full.

The draft was written before RFC 9989 added the test flag t=y, and says nothing about it. These pages, and the email doctor's grade, read it the way RFC 9989 tells receivers to apply it: one level lower, for p= and sp= alike (RFC 9989 §4.7). So a p=quarantine marked t=y counts as a policy of none here, as pct=0 once did, and rules BIMI out; a p=reject marked t=y is applied as quarantine and still qualifies. A receiver may read the flag differently while the draft is silent on it.

Where the record is looked for

A mail client asks for default._bimi.<domain>, or for another selector if the message names one in a BIMI-Selector header. If nothing is published there it asks once more at the Organizational Domain (BIMI draft 14 §7.2). The checker does the same for the selector default.

The common mistakes

A logo served over http, or as PNG or JPEG. Only https and SVG or SVGZ are accepted.
DMARC at p=none. The record is published and no client may use it.
Two records at the same selector. With more than one, BIMI is not applied.
A wildcard TXT record in the zone. It answers for default._bimi with something that is not a BIMI record; such answers are discarded.
Expecting the record alone to show a logo. Mail clients "have final control over the user interface" and may show another image or none (BIMI draft 14 §4.1).

What this checker does not tell you

It does not fetch the logo or the evidence document, so it cannot say whether the SVG meets the profile mail clients require or whether the certificate is genuine and current. And it cannot say which mail clients will show the logo: each sets its own requirements.

Method, sources and privacy

How this page reads the record.

Where the answers come from

Each question goes from your browser to two public DNS-over-HTTPS resolvers: Google Public DNS, at https://dns.google/resolve, and Cloudflare, at https://cloudflare-dns.com/dns-query, asked with Accept: application/dns-json. Both answer live, at the moment you ask, from their own caches: a record changed a moment ago can still be served in its old form until its time to live runs out (RFC 2181 §8). The answers are compared. When they differ both are shown; when one does not answer within 8 seconds the page names it; when neither answers, the card says so and concludes nothing. The panel This run dates the reading to the second, in UTC.

What is computed here

Everything else happens in your browser: the record is read against version 14 of the BIMI draft, first at the name and then at its Organizational Domain, and the DMARC record beside it is checked for the conditions the draft sets; the logo and its certificate are not fetched. Every finding links to the section of the document it rests on. The documents this page was written against are listed here, each with the date it was read; all seventeen are on the method page.

What happens to what you type

The domain goes to those two resolvers and to no one else: not to labs.llc's server, not into the page address, not into your browser's storage, and not to analytics, whose tag records this page's address, which never holds it. Of an email address only the part after the @ is used; the rest is dropped in your browser. The two resolvers see the question and the Origin header of labs.llc, and handle it under their own policies (Google Public DNS, Cloudflare). Changing the edition, paper or dark, reloads the page as it does everywhere on labs.llc, and clears the reading on screen: nothing of it is kept to bring back.