BIMI record: syntax, requirements and which inboxes show the logo

A BIMI record is a DNS TXT record at default._bimi.example.com that tells supporting inboxes where to find your brand logo, an SVG file named in the l= tag, and optionally where to find evidence for it, such as a mark certificate, in the a= tag. It only takes effect once your domain's DMARC policy is at enforcement: the BIMI Internet-Draft↗ (opens in a new tab) requires quarantine or reject. Publish one record, keep DMARC enforced, then check the rules of each inbox below.

What a BIMI record looks like#

The BIMI Internet-Draft↗ (opens in a new tab) places the record in a TXT record at default._bimi.example.com for the domain example.com. default is the default selector, and the record uses the tag-value syntax that DKIM key records use.

The main tags are:

• v=BIMI1 identifies the record as BIMI and must be the first tag.
• l= is the HTTPS address of the logo file, or empty.
• a= is the HTTPS address of a BIMI evidence document; a mark certificate is one type of evidence document. An empty value means the domain does not wish to publish evidence or has none to disclose, and a missing a= counts as empty.

The general shape, with your own HTTPS addresses in place of the placeholders, is:

v=BIMI1; l=<HTTPS address of your SVG logo>; a=<HTTPS address of your evidence document>

A real record, checked against live DNS, sits at default._bimi.cnn.com: it starts with v=BIMI1, its l= points to an .svg file and its a= to a .pem file, both over HTTPS. The same domain's DMARC record at _dmarc.cnn.com is at p=reject. Leave a= out until you have a certificate.

Receivers must not try to fix syntax or capitalization errors in the record. When more than one record is found, BIMI processing stops for that message, so keep exactly one v=BIMI1 record at default._bimi.

Declining BIMI on purpose#

A record with both l= and a= empty is an explicit refusal to participate, which the BIMI Internet-Draft↗ (opens in a new tab) treats as different from publishing no record at all:

v=BIMI1; l=; a=;

Use it when you do not want a logo shown for a domain or subdomain. Nothing needs fixing if that is the intent.

What has to be true before a logo shows#

A valid record is only one of the conditions. Google's BIMI setup guide↗ (opens in a new tab) lists the rest for Gmail:

• DMARC at enforcement. The policy must be quarantine or reject; BIMI does not support p=none. The percent option must be pct=100, which applies the policy to all outgoing mail from your domain. For the DMARC side, see DMARC policy not enabled and DMARC record tags.
• An SVG logo in the right profile. The file format is SVG Tiny Portable/Secure (SVG Tiny PS). Google recommends a file of 32 KB or smaller.
• HTTPS hosting. The web server that hosts your BIMI files must use HTTPS.
• A mark certificate. Gmail needs a Verified Mark Certificate (VMC) or a Common Mark Certificate (CMC), and supports BIMI only with PEM files.

After you add the record, it can take up to 48 hours for the logo to show in recipients' mailboxes.

The BIMI Internet-Draft↗ (opens in a new tab) sets the same DMARC floor in its own terms: quarantine or reject on both the organizational domain and the From domain, no quarantine policy below pct=100, and no BIMI processing when the policy is p=none or the subdomain policy is sp=none. Only SVG and SVGZ logos are accepted in l=. Even with everything in place, mail clients have final control over what they display and may show a different indicator or none at all.

Need an enforcing DMARC record first? Start with the DMARC record generator.

Which inboxes show the logo#

Gmail. Google's BIMI setup guide↗ (opens in a new tab) accepts a VMC or a CMC, and Gmail shows a checkmark next to senders verified with a VMC.

Yahoo. Yahoo's BIMI page↗ (opens in a new tab) asks for a record pointing to a valid SVG logo and a DMARC policy of quarantine or reject. It shows logos on bulk mail only, not personal email, and only when it sees sufficient reputation and engagement for the sending address. Yahoo does not currently require a VMC.

Apple Mail. Apple's developer page↗ (opens in a new tab) says Apple Mail supports BIMI from macOS Ventura 13, iOS 16 and iPadOS 16. The checks are done by the recipient's mail provider on its server, which must have verified a BIMI evidence document, for example a VMC it trusts, and added the required headers. If the provider has not done this, Apple Mail shows no logo. Spam Resource↗ (opens in a new tab) reported in November 2024 that CMC was supported only by Google, so treat a CMC as unverified for Apple.

Microsoft. The same Spam Resource overview listed Microsoft as not supporting BIMI as of November 2024.

Common BIMI record problems#

These are the causes covered by the BIMI Internet-Draft↗ (opens in a new tab) and Google's BIMI setup guide↗ (opens in a new tab):

• More than one record at default._bimi. With multiple records, BIMI processing stops. Merge them into one.
• v=BIMI1 not first. The version tag must be the first tag in the record.
• Logo not over HTTPS. HTTPS is the only supported transport for l=.
• Logo is not SVG. Only SVG and SVGZ are accepted, and Google expects the SVG Tiny PS profile.
• Logo file too large. Google recommends 32 KB or smaller.
• DMARC at p=none, or pct below 100. BIMI is not processed below enforcement, so move DMARC first.

Then run the BIMI checker and the domain check on your domain.

Sources#

• BIMI Internet-Draft, revision 14 (IETF)↗ (opens in a new tab)
• Set up BIMI (Google Workspace Admin Help)↗ (opens in a new tab)
• BIMI (Yahoo Sender Hub)↗ (opens in a new tab)
• BIMI support in Apple Mail (Apple Developer)↗ (opens in a new tab)
• BIMI mailbox provider support in November 2024 (Spam Resource)↗ (opens in a new tab)