What Is a BIMI Record?

Published 2026-08-21

A BIMI record is a DNS entry that tells participating mailbox providers where to find your brand’s logo, so that logo can appear beside authenticated messages you send. It is a marketing and trust feature — but it is bolted onto a security prerequisite that most domains do not meet. BIMI only functions when your domain publishes an enforcing DMARC policy, and the August 2026 defaults.exposed census graded 376,928,750 domains and found only 9.3% — 34,983,618 — do. The other 90.7% (341,945,132) are ineligible for BIMI no matter how good their logo is, because they have no enforcing DMARC to build it on. This guide explains what a BIMI record contains, the one hard requirement behind it, whether you actually need a VMC certificate, and how to check if your domain qualifies today.

Most people meet BIMI as a marketing item: “get your logo in the inbox.” That framing hides the real work. The logo is the last step, not the first — and it is gated by an email-authentication posture that fewer than one domain in ten has reached. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What Is a BIMI Record and How It Works

BIMI stands for Brand Indicators for Message Identification. It is a published standard, maintained by the AuthIndicators Working Group, that lets a domain owner tell mailbox providers where to find a machine-readable version of their brand logo — and, optionally, cryptographic proof that they are entitled to use it. When a message passes authentication, supporting inboxes fetch that logo and display it in the sender avatar slot.

The record itself is a single DNS TXT entry at a fixed location: the default._bimi subdomain of your domain (default._bimi.yourbusiness.com). Like SPF and DMARC, it lives in public DNS, so anyone — including an assessor checking your posture — can read it without access to your systems. A minimal enforcing example looks like this:

v=BIMI1; l=https://yourbusiness.com/assets/logo.svg; a=https://yourbusiness.com/assets/vmc.pem

Each tag does a job:

v=BIMI1 — the version tag. It must be present and first, exactly as shown. A missing or malformed version makes the record invalid and receivers ignore it.
l= — the location of the logo. This is an HTTPS URL pointing to your logo file in SVG Tiny Portable/Secure (SVG P/S) format — a locked-down SVG profile with no scripts, external references, or animation. The image must be square, and it must be served over HTTPS.
a= — the authority evidence. This is an HTTPS URL to a certificate (a VMC or CMC, covered below) in PEM format that proves you own the mark. The spec makes a= optional, but the major mailbox providers treat it as mandatory before they will display anything.

The flow at delivery time is straightforward. A receiving server authenticates the message, confirms it passes DMARC with an aligned domain, then looks up the sender’s BIMI record. If the record is valid, the domain enforces DMARC, and (where required) the certificate checks out, the provider renders your logo next to the message. Get any link in that chain wrong and the slot silently falls back to a generic initial or monogram.

BIMI is not a universal standard baked into every mail client. It works because a set of large mailbox providers chose to support it — Gmail, Apple Mail (from iOS 16 and macOS Ventura onward), Yahoo, Fastmail, and La Poste are the most widely used. Each decides its own display rules on top of the shared spec, which is why the same BIMI record can show a logo in one inbox and nothing in another. Any provider that does not participate simply ignores the record; it never harms delivery.

The logo format is stricter than most people expect, and it is a common reason a valid-looking record shows nothing. The l= tag must point to an SVG Tiny Portable/Secure (SVG P/S) file: a square image, with a defined viewBox and no scripts, no external references, no embedded raster images, and no animation. A logo exported straight from a design tool almost never conforms without conversion, and an oversized or non-square file is silently rejected. The image must also be served over HTTPS from a certificate that validates.

It is worth being clear about what BIMI does not do. It adds no new authentication check and stops no forgery on its own — the anti-spoofing work is done entirely by SPF, DKIM, and DMARC underneath. BIMI is the visible reward for having done that work: a logo the recipient can see, and on some providers a verified badge, both of which raise open rates and make impersonation attempts stand out by their absence. For the grading logic beneath it, see the DMARC policy methodology.

The One Hard Requirement: An Enforcing DMARC Policy

Everything about BIMI hangs on a single precondition. Your domain must publish a DMARC policy at p=quarantine or p=reject, applied to 100% of your mail. A domain at p=none — the monitor-only setting — does not qualify, and neither does a domain with no DMARC record at all.

The reasoning is deliberate. BIMI attaches a brand’s identity to its mail. If a provider showed your logo before you had committed to an enforcing policy, an attacker who spoofed you could ride your own logo into your customers’ inboxes — the exact opposite of the trust signal BIMI is meant to be. So the standard refuses to display a logo for any domain that has not first told the world’s mail servers to reject or quarantine forgeries of it. The logo is a privilege earned by enforcement.

This is why the enforcement distinction matters so much, and why publishing a DMARC record is not the same as qualifying for BIMI. A record at p=none is valid, will show up in a checker as “found,” and does nothing to stop forgery — so it earns no logo. Only quarantine and reject count. In the census, 53.6% of the domains that publish DMARC at all — 40,541,896 of them — sit at p=none, published but not enforcing, and every one of those is a domain that thinks it “has DMARC” but cannot use BIMI until it moves up.

There is a further wrinkle that trips up domains at the boundary. Several providers require the policy to cover 100% of mail — meaning pct=100, or the pct tag omitted (which defaults to 100). A record like p=reject; pct=25 reads as enforcing to a casual glance but applies the policy to only a quarter of mail, and BIMI-supporting inboxes treat that as non-qualifying. The census found 476,000 records watering down enforcement with a reduced pct; we quantified them in the pct tag report. If yours is one of them, fix the pct before you invest in a logo.

In practice, providers also expect the message to authenticate via DKIM, not SPF alone, because DKIM survives forwarding and mailing lists where SPF breaks. That makes a fully protected posture — SPF, DKIM, and an enforcing DMARC together — the realistic foundation. Only 2.9% of domains (10,902,284) have reached it. For the building blocks, see the DKIM and SPF methodology pages, and the sibling explainer What Is DMARC?.

Why Only 9.3% of Domains Qualify for BIMI Today

Because BIMI’s floor is an enforcing DMARC policy, the census gives an unusually precise read on the size of BIMI’s real addressable market. It is not a matter of who has designed a logo — it is a matter of who has done the security work underneath, and that is directly measurable.

Of the 376,928,750 domains graded for email authentication in the August 2026 census, only 34,983,618 — 9.3% — publish an enforcing DMARC policy. That 9.3% is the ceiling for BIMI eligibility. Every other domain is locked out at the door: the remaining 90.7% (341,945,132) have no enforcing policy to attach a logo to, and no certificate, logo format, or record syntax changes that until the DMARC policy moves to quarantine or reject.

Break the ineligible 90.7% down and the shape of the problem appears:

Just 20.0% of domains (75,571,248) publish any DMARC record at all. Four in five have none — so before BIMI is even a conversation, most of the internet has to publish a first DMARC record.
Of the publishers, 53.6% (40,541,896) sit at p=none. They have taken the first step but stopped on the monitoring runway. They are the closest cohort to BIMI eligibility — one policy edit away — yet still disqualified today.
Only 2.9% of domains (10,902,284) are fully protected across SPF, DKIM, and DMARC. This is the group that not only enforces but authenticates the way providers prefer, and it is the most credible near-term BIMI population.

Even the headline 9.3% is a slight overcount for BIMI purposes. Some of those enforcing domains carry a reduced pct (part of the 476,000 watered-down records) or enforce via SPF in ways that break under forwarding, and would fail a provider’s 100%-coverage or DKIM expectation. The true qualifying set sits a shade below 9.3% — the point being that BIMI’s addressable market is small, sharply defined by security posture, and not something a marketing team can unlock without the domain’s DMARC being fixed first.

There is a more encouraging way to read the same numbers. The 40.5 million domains at p=none are not far away. They have already published DMARC, already receive (or could receive) reports, and need only to confirm their legitimate senders align and then tighten the policy. For a large share of them, BIMI is one careful DNS change plus a certificate away — the gap is procedural, not architectural. That “one record from safety” cohort is exactly what our twin report measures in DMARC Gap: 87 Million Domains One Record From Safety.

If you are weighing a BIMI project, the first thing to establish is which side of the 9.3% line your own domain is on. Check your domain free at defaults.exposed — it reads your live DMARC policy from public DNS and tells you instantly whether you already enforce, whether you are stuck at p=none, or whether you have no record at all.

VMC Certificates: Do You Actually Need One?

The most common practical question about BIMI is whether it requires a Verified Mark Certificate — a VMC — and the honest answer is: it depends on which inboxes you care about.

A VMC is a specialised certificate, issued by a small set of certificate authorities, that binds your logo to a registered trademark you own. Getting one involves organisational validation similar to an EV certificate plus proof that the exact logo in your BIMI record is a trademark registered with a recognised authority (such as the USPTO, EUIPO, or UKIPO). It is referenced in your BIMI record via the a= tag, renews annually, and typically costs on the order of a thousand-plus per year — a real budget line, not a free DNS edit.

Whether you need one splits along provider lines:

The BIMI standard itself does not strictly require a certificate. A record with only l= (the logo) and no a= is valid, and a handful of early adopters displayed logos on that basis.
The major mailbox providers do require one to display anything. Gmail and Apple Mail — between them the inboxes most senders actually care about — will not render a BIMI logo without valid authority evidence in the a= tag. For those inboxes, no certificate means no logo, full stop.

For domains whose logo is not a registered trademark — which is many small businesses, non-profits, and government bodies — a newer option lowers the barrier: the Common Mark Certificate (CMC). A CMC accepts marks that are not eligible for full trademark registration, including prior-use marks and government-issued insignia, and is generally cheaper than a VMC. Support for CMCs has been rolling out across providers, though it lags VMC support and, on some inboxes, a CMC shows the logo without the additional “verified” badge that a VMC unlocks.

The practical sequence, then, is: fix the security posture first, choose the certificate second. There is no point commissioning a VMC or CMC while your domain is still at p=none, because the certificate cannot make an ineligible domain display a logo — the enforcing DMARC policy is what the provider checks before it ever looks at your certificate. Do not let a certificate vendor sell you the last step before you have done the first.

How to Get BIMI-Ready: From p=none to p=reject

If your domain does not yet qualify, the route is the same well-trodden DMARC path — BIMI simply sits at the end of it. Each step is low-risk when done in order, and none of them requires a logo or a certificate until the very end.

Publish DMARC at p=none with a monitored rua= address. If you have no record, this is step one. It changes nothing about delivery and starts the flow of aggregate reports that show who sends mail as you. This is the only stage at which p=none is the right answer — a temporary listening post, not a destination. See how the reports are consumed in Who Reads the World’s DMARC Reports and the DMARC reporting methodology.
Read the reports and align your senders. Over two to four weeks the reports reveal every legitimate service sending in your name — your mail platform, CRM, invoicing tool, newsletter provider. Bring each into SPF and DKIM so that legitimate mail authenticates and aligns. Getting DKIM right here matters especially, because it is what providers prefer for BIMI.
Move to p=quarantine, then p=reject, at pct=100. Once legitimate senders align, tighten the policy. At p=quarantine your domain becomes BIMI-eligible on most providers; at p=reject you reach the strongest posture and the widest support. Keep pct at 100 and set a matching sp= so subdomains inherit the protection.
Only now, add the BIMI record. Produce your logo in SVG Tiny P/S format (square, HTTPS-hosted), obtain a VMC or CMC if you want it displayed in Gmail and Apple Mail, and publish the TXT record at default._bimi.yourdomain.com with v=BIMI1, l=, and a=.

The work is not the DNS editing — each change is a single TXT record. The work is the listening in step two, which is why starting today matters even if you cannot enforce today. A domain that reaches p=reject also closes almost all of its impersonation exposure, which is worth doing whether or not you ever add a logo. The two goals share the same road; BIMI is just the mile-marker at the end of it.

What This Means

For marketing and brand teams, BIMI is genuinely attractive — a verified logo in the inbox lifts recognition and open rates and makes your real mail visibly distinct from forgeries. But it cannot be bought or designed into existence. At a 9.3% enforcement rate across the internet, the default state for most domains is ineligible, and the blocker is a security setting your marketing budget cannot fix directly.

The productive move is to route the BIMI ask to whoever owns DNS and email authentication, get to p=reject, and then commission the logo and certificate. A BIMI project that starts with a VMC quote has started at the wrong end. If you want the enforcement gap closed properly first, see how the fix works.

For IT and security teams, BIMI is a useful forcing function. It gives the business a concrete, visible reason to care about a DMARC policy that has probably languished at p=none — the state 53.6% of DMARC publishers are stuck in. Treat the logo request as the lever it is: use it to justify the two-to-four-week alignment project, reach an enforcing policy with pct=100 and a matching subdomain policy, and deliver the logo as the reward. The security win — a domain that can no longer be freely spoofed — is the real prize; the inbox logo is the receipt. For the full posture picture, see The Locked Vault and The Google and Yahoo Deadline, Two Years On.

FAQ

What is a BIMI record? A BIMI (Brand Indicators for Message Identification) record is a DNS TXT entry published at default._bimi.yourdomain.com that tells participating mailbox providers where to find your brand logo and, optionally, a certificate proving you own it. When a message you send passes authentication and your domain enforces DMARC, supporting inboxes such as Gmail and Apple Mail display that logo beside the sender. It adds no new authentication of its own — it is the visible reward for having enforcing SPF, DKIM, and DMARC underneath. In the August 2026 census, only 9.3% of domains meet the enforcement floor BIMI requires.

What are the requirements for BIMI? Four things must be true. First, your domain must publish an enforcing DMARC policy — p=quarantine or p=reject, applied to 100% of mail (pct=100); p=none does not qualify. Second, your legitimate mail must authenticate and align, in practice via DKIM. Third, you need a logo in SVG Tiny Portable/Secure format, square and HTTPS-hosted. Fourth, for Gmail and Apple Mail you need a VMC or CMC certificate referenced in the record’s a= tag. The DMARC requirement is the real gate: only 9.3% of domains (34,983,618) clear it, and 90.7% are locked out until they enforce.

Do I need a VMC for BIMI? It depends on which inboxes you want the logo to appear in. The BIMI standard itself does not strictly require a certificate, but the providers that matter most — Gmail and Apple Mail — will not display a logo without one. A VMC (Verified Mark Certificate) requires a registered trademark of your exact logo and costs roughly a thousand-plus per year. If your logo is not trademarked, a Common Mark Certificate (CMC) is a cheaper alternative that accepts prior-use and government-issued marks, though provider support for CMCs is narrower. Either way, do not buy a certificate until your domain already enforces DMARC — it cannot make an ineligible domain show a logo.

Is BIMI a security feature or a marketing feature? Both, but in that order of dependency. BIMI adds no authentication and blocks no forgery by itself; the anti-spoofing work is done entirely by SPF, DKIM, and DMARC. What BIMI adds is visibility — a logo, and on some providers a verified badge, that makes authenticated mail recognisable and makes impersonation stand out by its absence. The security value is indirect but real: because BIMI demands an enforcing DMARC policy first, it pushes domains to do the anti-spoofing work they had been putting off. The logo is marketing; the prerequisite is security.

How do I check whether my domain qualifies for BIMI? Start by checking your DMARC policy, because that is the gate. Enter your domain into a free scanner such as defaults.exposed; it reads your published DMARC record from public DNS and tells you whether you already enforce (p=quarantine or p=reject), whether you are stuck at p=none, or whether you have no record at all. If it shows enforcement at pct=100 with aligned senders, you meet BIMI’s floor and can move on to the logo and certificate. If it shows p=none or no record, that is the work to do first. The check takes about 30 seconds and needs no account.

Why isn’t my logo showing even though I published a BIMI record? Almost always because a link earlier in the chain is missing. The commonest causes are a DMARC policy still at p=none or below pct=100; a message that authenticated via SPF but not DKIM; a logo that is not valid SVG Tiny P/S or not served over HTTPS; or, on Gmail and Apple Mail, a missing or invalid VMC/CMC certificate in the a= tag. A valid BIMI record on top of a non-enforcing domain displays nothing, because providers check the DMARC policy before they ever fetch your logo. Confirm enforcement first, then work outward.

Data to cite

“BIMI requires an enforcing DMARC policy, so only 9.3% of domains (34,983,618 of the 376,928,750 graded in the August 2026 census) currently qualify for it.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“90.7% of domains (341,945,132) are ineligible for BIMI because they lack an enforcing DMARC policy to attach a brand logo to.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“53.6% of DMARC publishers (40,541,896) sit at p=none and must move to quarantine or reject before BIMI will display their logo.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Only 2.9% of domains (10,902,284) are fully protected across SPF, DKIM, and DMARC — the practical foundation BIMI is built on.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Just 20.0% of domains (75,571,248) publish any DMARC record at all, so most of the internet has not even taken BIMI’s first prerequisite step.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

BIMI is only worth planning once you know which side of the enforcement line your domain sits on. For 90.7% of domains the honest answer is not eligible yet — and most owners have never had it stated plainly, because the logo is pitched as a marketing add-on rather than the end of a security project.

Check your domain free at defaults.exposed — it reads your live SPF, DKIM, and DMARC records from public DNS and tells you instantly whether your policy actually enforces, whether you are stuck at p=none, and whether your domain is BIMI-ready or still spoofable. Takes 30 seconds. No account needed. If your check comes back short of enforcement and you want the gap closed properly — SPF, DKIM, and an enforcing DMARC policy done right — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from 432,127,908 scanned. All figures are counts of graded domains. References: BIMI (AuthIndicators Working Group draft specification), RFC 7489 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM).

How to cite this report

Press / blog: defaults.exposed (2026). What Is a BIMI Record? (And Why Only 9.3% of Domains Qualify). defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-a-bimi-record

Academic: defaults.exposed. (2026, August 21). What Is a BIMI Record? In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-a-bimi-record

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 graded domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →