BIMI, short for Brand Indicators for Message Identification, is an email standard that lets a sending domain publish its logo in a DNS record so that participating mailbox providers can display it beside authenticated messages. In email infrastructure, BIMI sits on top of the authentication stack: it works only for domains whose mail passes DMARC with an enforcement policy.
BIMI is not an authentication protocol in its own right. It is a reward for strong authentication: a visible signal that tells recipients the message comes from a domain that has secured its mail with SPF, DKIM and DMARC and, at most providers, has proven its right to use the logo through a mark certificate.
How BIMI works from DNS record to inbox
BIMI begins with a TXT record at a fixed location: default._bimi.example.com. The record contains a version tag and up to two URLs, for example v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem. The l= tag points to the logo file and the a= tag points to the evidence document, a mark certificate.
When a message arrives, the receiving provider first evaluates DMARC. Only if the message passes and the domain’s policy is enforced does the provider look up the BIMI record, fetch the logo, validate the certificate if it requires one, and cache the result. The logo then appears in the inbox list or message view, typically in the round avatar slot.
Senders can publish selector-specific records such as marketing._bimi.example.com and choose one per message with a BIMI-Selector header, which lets different brands under one domain show different logos.
| Tag | Example value | Purpose |
|---|---|---|
| `v=` | BIMI1 | Version, must come first |
| `l=` | HTTPS URL of an SVG file | Location of the logo |
| `a=` | HTTPS URL of a PEM file | Location of the mark certificate |
| Empty `l=` | v=BIMI1; l=; | Declines BIMI for the domain |
Prerequisites for a working BIMI setup
BIMI has strict entry requirements, and missing any one of them means no logo is shown. The central condition is a DMARC policy of quarantine or reject applied to all mail, because a logo next to unauthenticated or spoofable mail would mislead recipients.
| Requirement | Required setting | Why it matters |
|---|---|---|
| DMARC policy | p=quarantine or p=reject | Ensures spoofed mail is not shown with a logo |
| DMARC coverage | pct=100, subdomain policy not none | Partial enforcement is not accepted |
| Alignment | SPF or DKIM aligned with the From domain | DMARC must actually pass |
| Logo format | SVG Tiny Portable/Secure profile | Safe, scalable rendering |
| Logo shape | Square aspect ratio, centered mark | Displayed inside a circle or square |
| Mark certificate | VMC or CMC, depending on provider | Proves the right to use the logo |
The SVG Tiny Portable/Secure profile is a restricted form of SVG that forbids scripts, external references, animation and raster images. Ordinary SVG exports from design tools usually fail validation until they are converted to this profile and given a baseProfile="tiny-ps" attribute and a title element.
Mark certificates and logo verification
Anyone can place a logo URL in DNS, so providers that care about impersonation require independent proof of logo ownership. This proof takes the form of an X.509 certificate issued by a qualifying certificate authority after identity and trademark checks, with the SVG logo embedded in the certificate itself.
| Evidence type | What the issuer verifies | Typical effect |
|---|---|---|
| Verified Mark Certificate | Organization identity and a registered trademark | Logo plus a verified checkmark at some providers |
| Common Mark Certificate | Organization identity and prior public use of the logo | Logo shown, usually without the checkmark |
| No certificate | Nothing beyond DNS control | Logo shown only by a few providers, if at all |
Certificates are issued for about one year and must be renewed. Because the logo is embedded in the certificate, changing the logo means reissuing the certificate, not just replacing the SVG file on the web server.
How BIMI relates to SPF, DKIM and DMARC
BIMI depends entirely on the authentication layers beneath it. SPF authorizes sending servers, DKIM signs messages cryptographically, and DMARC ties both to the visible From domain and states the policy for failures. BIMI adds no new check of its own; it only consumes the DMARC result.
| Standard | Question it answers | Visible to recipient |
|---|---|---|
| SPF | Is this server allowed to send for the domain | No |
| DKIM | Was the message signed and left unaltered | No |
| DMARC | Do SPF or DKIM align with the From domain | No, but affects delivery |
| BIMI | Which logo represents this authenticated domain | Yes, as the sender logo |
In practice, the hardest part of a BIMI project is rarely the BIMI record. It is the move to DMARC enforcement, which requires finding every legitimate service that sends mail for the domain and aligning it, a process that can take weeks or months.
Limitations and common mistakes
BIMI does not guarantee that a logo appears. Each mailbox provider decides whether to support it, which evidence it requires, and whether the sender’s reputation and volume are sufficient. Some providers ignore BIMI entirely, and display rules can change without notice.
- DMARC at `p=none`: the most common reason a logo never appears.
- Invalid SVG profile: a normal SVG with scripts or raster content is rejected.
- Logo mismatch: the SVG at
l=must match the logo embedded in the certificate. - Missing subdomain policy: an
sp=nonesetting disqualifies the domain at many providers. - Expectation of deliverability gains: BIMI does not bypass spam filtering; it affects only presentation.
Understanding it simply
BIMI is what puts a company logo next to its emails in your inbox. The logo is only shown when the company has proven two things. First, its emails are properly protected against forgery. Second, it really owns the logo.
You can think of it like a verified badge on a social network. Anyone can claim to be a brand. Only senders that pass the checks get the badge. For readers, the logo is a quick sign that a message is genuine, although it is not a complete guarantee of safety.
Applied in practice
An online retailer sends order confirmations and newsletters from shop.example. Customers report phishing messages that imitate its shipping notices, and the security team decides to roll out BIMI so that genuine messages carry the brand logo.
The team first audits all senders, including a newsletter platform and a support desk, and aligns their DKIM signatures. Over eight weeks it moves DMARC from p=none through p=quarantine to `p=reject` with full coverage. A designer converts the logo to SVG Tiny Portable/Secure, and the company obtains a Verified Mark Certificate based on its registered trademark.
After the BIMI record is published, the logo appears beside the retailer’s messages at supporting providers. Support staff can now tell customers that a genuine message shows the logo, while forged messages fail DMARC and are rejected outright.