BIMI Record Explained: Logo in Gmail, Requirements, Limits

BIMI (Brand Indicators for Message Identification) is a TXT record that tells mailbox providers where to find your logo, so they can show it next to messages that passed DMARC. The record itself is one line. The work is in the prerequisites: DMARC at enforcement (p=quarantine or p=reject), a logo in a restricted SVG profile, and, for the providers most people care about, a mark certificate issued by a certificate authority. Even with all of that in place, whether the logo appears is the receiver's decision.

One thing to have straight from the start: BIMI is not an RFC standard. It is a specification by the AuthIndicators Working Group (the BIMI Group), published as IETF Internet-Drafts. Providers implement it to different degrees, and their requirements change.

What the record looks like

$ dig +short TXT default._bimi.example.com
"v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Tag	Meaning
v=BIMI1	Version, must come first
l=	HTTPS URL of the logo (SVG)
a=	HTTPS URL of the evidence document: the mark certificate in PEM format

default is the selector. A sender can publish further selectors (for example newsletter._bimi.example.com) and choose one per message with a BIMI-Selector header. Most domains only ever need default.

Subdomains inherit: for mail from news.example.com, a receiver that finds no record at default._bimi.news.example.com falls back to the organisational domain's record. A subdomain can publish its own record to show a different logo.

Requirement 1: DMARC at enforcement

This is where most BIMI projects really start, and where most of the time goes.

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

• The policy on the organisational domain must be p=quarantine or p=reject. p=none does not qualify.
• sp=none (a relaxed subdomain policy) and a pct value below 100 can disqualify the domain.
• The individual message must pass DMARC: SPF or DKIM passes, with the authenticated domain aligned to the From domain.

The logic is straightforward. A logo is a trust signal, and a receiver will only attach it to mail from a domain that has told the world to reject forgeries. Getting there safely means an inventory of every system that sends as you, aligned DKIM on each, and weeks of reading reports before tightening the policy; the rollout order is in MX, SPF, DKIM and DMARC explained. You can see where a domain stands today with the OrbitProbe DMARC checker, and the DMARC generator assembles the record syntax.

Requirement 2: the logo as SVG Tiny PS

Receivers do not accept arbitrary SVG files. The logo must follow the SVG Tiny Portable/Secure profile (SVG Tiny PS), a cut-down profile defined for BIMI:

• no scripts
• no external references (no linked images, fonts or stylesheets): everything is embedded in the one file
• no animation
• square aspect ratio
• a solid background is recommended, because providers crop the image to a circle or rounded square and show it on light and dark themes
• served over HTTPS

The root element declares the profile, and a <title> is expected:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny-ps" viewBox="0 0 100 100">
  <title>Example Ltd</title>
  …
</svg>

An export straight from a design tool almost never complies: it carries editor metadata, the wrong baseProfile and often an embedded bitmap. Plan for a manual clean-up or a dedicated conversion step, and keep the logo centred with room around it so the circular crop does not cut into it.

$ curl -I https://example.com/bimi/logo.svg
HTTP/2 200
content-type: image/svg+xml

A 200 response, the image/svg+xml content type and no redirect to a login or consent page: check those three.

Requirement 3: a mark certificate

The a= tag points at a certificate that binds the logo to your organisation. It is issued by a certificate authority after validating your identity and your right to the logo, and the logo is embedded in the certificate. Only a small number of CAs issue them. Two kinds exist:

	VMC (Verified Mark Certificate)	CMC (Common Mark Certificate)
Registered trademark	Required	Not required
Basis for the logo	The trademark registration	For example, demonstrated prior use of the logo
Identity validation by the CA	Yes	Yes

These are not TLS certificates. They do not go on your web server and have nothing to do with the HTTPS certificate that serves the files.

Provider support, as of September 2026

Support differs between mailbox providers and has changed more than once. As known at the time of writing:

• Gmail requires a VMC or a CMC. Google announced CMC support in 2024; its blue verified checkmark is tied to a VMC.
• Apple Mail requires a VMC.
• Some providers may display a logo without any certificate, at their own discretion (a "self-asserted" record with only the l= tag).
• Some large providers do not support BIMI at all.

Before paying for a certificate, read the current documentation of the mailbox providers your recipients actually use. If most of your audience sits with a provider that ignores BIMI, no record will put your logo there.

What BIMI does not do

• Display is always the receiver's decision. A valid record, a valid certificate and a DMARC pass make you eligible. Providers also look at the reputation of the domain and the sending source, and can decline without telling you why.
• It is not a deliverability boost by itself. BIMI does not move mail from spam to the inbox. The DMARC work you did to qualify is what helps; a logo is shown on mail that was already going to be delivered. If your mail is landing in spam, start with the DNS checklist for mail going to spam.
• It is not an anti-phishing guarantee. A lookalike domain can go through the same process with its own logo, and recipients whose mail client does not show BIMI see nothing either way. Absence of a logo proves nothing.
• Logos are cached. Receivers fetch the SVG and the certificate on their own schedule. A new or changed logo can take days to show up, and a removed one can linger.

The path, in order

1. Get SPF and DKIM aligned for every service that sends as your domain. Aligned DKIM matters most, because it survives forwarding.
2. Publish DMARC with p=none and a rua address, and read the reports.
3. Move to p=quarantine, then to p=reject, at pct=100, with no sp=none.
4. Prepare the SVG Tiny PS logo and host it over HTTPS at a stable URL.
5. Obtain the certificate (VMC if you have a registered trademark and want the widest support, CMC otherwise) for exactly that logo file.
6. Publish the BIMI record at default._bimi.
7. Send real mail to mailboxes at the providers you care about, and wait.

Steps 1 to 3 usually take months in an organisation with many sending systems. Steps 4 to 6 take days, plus the CA's validation time.

Checklist

• _dmarc on the organisational domain: p=quarantine or p=reject, no pct below 100, no sp=none
• Every sending service passes DMARC with alignment (check the reports, not a single test message)
• Logo is SVG Tiny PS: square, self-contained, no scripts, no animation, baseProfile="tiny-ps"
• Logo URL and certificate URL answer with 200 over HTTPS, without redirects to other content
• The logo in the certificate is the same logo the l= tag points to
• One TXT record at default._bimi, starting with v=BIMI1
• Certificate expiry date noted in a calendar: mark certificates expire like any other

You can look up a domain's published BIMI record with the BIMI checker.

Common mistakes

• Publishing a BIMI record while DMARC is still at p=none and waiting for a logo that cannot come.
• Setting p=reject on the main domain and leaving sp=none or pct=50 in the record from an earlier rollout stage.
• Uploading the designer's SVG export unchanged.
• Putting the record at _bimi.example.com instead of default._bimi.example.com.
• Hosting the logo behind a redirect, a cookie wall or a CDN rule that blocks non-browser clients.
• Changing the logo file after the certificate was issued. The certificate contains a specific logo; a different file at l= no longer matches.
• Buying a certificate first and starting the DMARC project second.
• Expecting the logo in every inbox. Provider support is partial, and display is discretionary.
• Treating BIMI as a security control. The security comes from DMARC enforcement; BIMI is the visible reward for it.

Check it with OrbitProbe

Since everything in BIMI depends on DMARC, start there. The OrbitProbe DMARC checker looks up the record at _dmarc for a domain, shows which policy it publishes (none, quarantine, reject) and flags a record that is missing, duplicated or invalid. Run it for the organisational domain first and then for any subdomain you send from. A DNS check shows the published policy at that moment. It cannot tell you whether individual messages pass with alignment (that is in your DMARC aggregate reports), and no lookup can predict whether a mailbox provider will choose to display the logo.