BIMI explained: the record, the logo and DMARC

Brand Indicators for Message Identification (BIMI) lets a domain publish a logo that mail clients can show next to messages that pass authentication. It is described in the Internet-Draft draft-brand-indicators-for-message-identification. BIMI does not authenticate anything itself. It builds on DMARC: a logo is only considered for mail that passes a DMARC policy the domain enforces.

The record

A BIMI record is a TXT record at <selector>._bimi.<domain>. The default selector is default:

default._bimi.example.com.  TXT  "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"

The tags are:

• v=BIMI1, the version, which must come first.
• l=, the HTTPS URL of the logo. The logo is an SVG file in the restricted "SVG Tiny Portable/Secure" profile that the draft describes.
• a=, the HTTPS URL of an authority evidence document, usually a Verified Mark Certificate (VMC) in PEM format. It is optional in the record, but many providers require it.

If there is no record for the domain at all, BIMI is not in use (BIMI_NOT_FOUND). A record that does not parse, or several records for the same name, is reported as BIMI_INVALID_RECORD.

Selectors and the organisational domain

A message can carry a BIMI-Selector header to ask for a specific record, for example brand2._bimi.example.com. Without the header the receiver uses default.

If there is no record for the domain in the From address, the draft tells receivers to look at the organisational domain, the registrable domain that DMARC also uses. A record at default._bimi.example.com therefore also covers mail from news.example.com, unless that subdomain publishes its own record. The BIMI record check follows the same rule and shows which name the record was found at.

Declining BIMI

A record with empty l= and a= tags, such as v=BIMI1; l=; a=;, says that the domain does not want a logo shown. This is useful for a subdomain that should not inherit the organisation's logo. The check shows such a record as declined and does not report the missing logo.

HTTPS and the logo format

Both URLs must use HTTPS. A logo or certificate on plain HTTP will not be used, and the check reports it as BIMI_INSECURE_URL.

The logo must be an SVG in the Tiny Portable/Secure profile: a square image, no scripts, no external references and no animation, among other restrictions. Raster images such as PNG or JPEG are not accepted. The check cannot see the content without downloading it, but a URL that does not end in .svg is often a sign of the wrong file and is reported as BIMI_LOGO_NOT_SVG.

The DMARC requirement

BIMI only makes sense for a domain that prevents others from using its name. The draft requires a DMARC policy that is enforced:

• p=quarantine or p=reject on the organisational domain;
• no partial rollout: pct must be 100, or absent, which means 100;
• the subdomain policy must not weaken it: an sp=none makes the domain unsuitable.

A domain whose DMARC does not meet these conditions is reported as BIMI_DMARC_NOT_ENFORCED, and receivers will not show its logo. Moving DMARC to enforcement is a project of its own: first make sure, with DMARC reports, that all legitimate mail passes. See DMARC explained.

Each message must then also pass DMARC itself, through an aligned SPF or DKIM result. A logo is never shown for a message that fails.

Mark certificates

A Verified Mark Certificate (VMC) links the logo to a registered trademark. It is issued by a certificate authority after checking the trademark and the organisation, and its URL goes in a=. A Common Mark Certificate (CMC) also exists. It does not require a registered trademark, and some mailbox providers accept it alongside a VMC. Some large providers only show logos with such a certificate, while others show logos without one for senders with a good reputation. A record without a= is reported as BIMI_NO_VMC for information: it is valid, but many clients will not use it.

If you get a certificate, check that your CAA records allow the certificate authority to issue it. Mark certificates are governed by the issuevmc CAA property rather than issue, so a policy that lists only issue records may not cover them. CAA is explained in CAA records explained.

What receivers do

A receiver that supports BIMI does roughly this for each message:

1. Check that the message passes DMARC and that the domain's policy is enforced.
2. Look up the BIMI record for the selector, falling back to the organisational domain.
3. Fetch the logo and, if present, the certificate, and validate them.
4. Decide, by its own rules, whether to show the logo.

Steps 3 and 4 differ between providers, and they are not visible from DNS.

Getting ready, in order

1. Bring SPF and DKIM in line for every service that sends mail as your domain, so that legitimate mail passes DMARC. The SPF guide and the DKIM guide cover the details.
2. Move DMARC from monitoring to enforcement in steps, guided by the aggregate reports.
3. Prepare the logo as an SVG Tiny Portable/Secure file and host it on HTTPS.
4. Decide whether you need a mark certificate for the providers that matter to you.
5. Publish default._bimi.<domain> and check it.

Because the DMARC step usually takes the longest, many domains publish the BIMI record last.

Common mistakes

• Publishing a BIMI record while DMARC is still at p=none.
• A logo on HTTP, or a PNG instead of an SVG.
• A logo that is a normal SVG export with scripts or external fonts, not the Tiny Portable/Secure profile.
• Expecting the logo to appear immediately; providers cache and apply reputation rules.

Use the BIMI record check to read the record and check the DMARC requirement, the DMARC check for the policy itself, or the domain health check for BIMI together with SPF, DKIM and DMARC.