BIMI Email Setup Guide: Dependency Chain Over DNS

Most BIMI email setup guides start with DNS. That's the wrong place to start. By the time you're editing a TXT record, you should have already satisfied a strict dependency chain, DMARC enforcement, compliant SVG, and in most cases a cryptographic certificate from an authorized third party. Skip any layer, and the logo never appears. No error message tells you why.

This BIMI email setup guide works through every layer in order: what each dependency requires, how receiving mail transfer agents verify it, and where implementations silently fail. Understanding how SPF, DKIM, and DMARC interact is the prerequisite for everything that follows.

What BIMI Actually Is (and What It Depends On)

Brand Indicators for Message Identification: the protocol in plain terms

Brand Indicators for Message Identification (BIMI) is a standard that lets a domain owner publish a logo for display in supporting email clients, Gmail, Yahoo Mail, Apple Mail, and a growing list of others. The logo appears in the sender avatar slot before a recipient opens the message.

The mechanism is straightforward: a DNS TXT record points to an SVG logo file and, for providers that require it, a Verified Mark Certificate. The receiving MTA fetches that record, validates the chain, and signals the client to render the image.

What vendor marketing consistently undersells is the word validates. BIMI does not simply read a DNS record and show a logo. It verifies a complete authentication stack before the record is even consulted.

The dependency chain: why BIMI is the last layer, not the first

BIMI is the terminal node in a trust chain. Each layer gates the next:

1. SPF and DKIM must pass and align with the RFC5322 From domain.
2. DMARC must be published with an enforcing policy (p=quarantine or p=reject) covering 100% of mail.
3. The SVG logo must conform to the SVG Tiny P/S (Portable/Secure) profile.
4. A Verified Mark Certificate (VMC) must be issued by an authorized CA and cryptographically bind the logo to the domain, required by Gmail, Yahoo, and Apple Mail.
5. The BIMI DNS record must point to both assets with correct syntax.

BIMI is best understood not as a feature you configure, but as visible proof of a well-maintained authentication stack. If the logo isn't showing, the problem is almost never the BIMI record itself.

BIMI DMARC Requirement: Enforcement Is Non-Negotiable

Why p=none kills BIMI before it starts

A DMARC record at p=none, even one that passes alignment for every message, does not satisfy the BIMI prerequisite. Receiving MTAs that implement BIMI verification reject p=none as insufficient enforcement, so the BIMI record is never evaluated.

This is a deliberate design decision. BIMI's purpose is to surface trustworthy senders visually. A domain under p=none has declared it is still monitoring rather than enforcing, so spoofed messages from that domain face no consequence. Displaying a logo under those conditions would make the indicator meaningless.

The required minimum is p=quarantine or p=reject. The pct tag, which scopes policy application to a percentage of failing messages, must equal 100. A record like p=quarantine; pct=50 covers only half the failing mail and fails the BIMI prerequisite.

Validating your DMARC policy before touching BIMI

Query your DMARC record before any other BIMI work:

dig TXT _dmarc.yourdomain.com

Confirm three things:

• p= is quarantine or reject
• pct= is 100 (or absent, the default is 100)
• The record applies to the exact domain in the RFC5322 From header, not just an organizational parent

Receiving MTAs check DMARC alignment, not just the presence of a DMARC record. A subdomain sending mail must have its own enforcing DMARC policy, or the parent's policy must cover it via the sp= tag. For DMARC failure troubleshooting via the Authentication-Results header, the failure will appear before BIMI is ever evaluated.

BIMI SVG Requirements: Why Your Logo Will Fail the Profile Check

BIMI requires the SVG Tiny P/S (Portable/Secure) profile, a constrained subset of SVG 1.2 Tiny defined by the AuthIndicators Working Group. The constraints exist to prevent the logo from being used as an attack vector inside an email client renderer.

The profile forbids:

• Raster image embeds, no <image> elements referencing PNG, JPEG, or other bitmap data, whether inline or external
• External URI references, no xlink:href or href pointing to off-document resources
• Scripts, no <script> elements or event handler attributes
• Animation, no SMIL animation elements (<animate>, <animateTransform>, etc.)
• Non-square aspect ratios, the viewBox must describe a square (equal width and height values)

The profile also requires a specific XML declaration and namespace, and the root <svg> element must include baseProfile="tiny-ps" and a valid version attribute.

The practical consequence: most SVGs exported directly from Adobe Illustrator or Figma fail this check without post-processing. Illustrator embeds raster data silently. Figma exports include unsupported filter effects. Neither tool exports the baseProfile attribute by default.

Run any candidate SVG through a BIMI-specific validation tool before attempting DNS publication, the BIMI Group publishes a validator at bimigroup.org. A non-conforming SVG causes the logo to silently not render, with no DNS-level error to catch.

BIMI VMC Certificate: What It Is, Who Issues It, and When You Need It

VMC issuance: the Verified Mark Certificate process

A Verified Mark Certificate (VMC) is an S/MIME-adjacent X.509 certificate issued by an authorized Certificate Authority. It cryptographically binds a trademarked logo (in the form of a hash of the SVG file) to the domain that sent the message. The certificate is hosted at a public HTTPS URL referenced by the a= tag in the BIMI DNS record.

DigiCert is the safe default choice for a new VMC purchase in 2026. The CA landscape shifted significantly in late 2024: Entrust, historically the other major VMC issuer alongside DigiCert, suffered a series of compliance failures that led Google Chrome and Apple to distrust new Entrust-issued certificates (including BIMI VMCs) issued after November 15, 2024. Entrust subsequently exited the public certificate business entirely, selling it to Sectigo, which has since begun issuing VMCs as a newer entrant to the market. If you already hold an Entrust VMC issued before the November 2024 cutoff, it continues to function for now, but will stop working in Apple Mail once you renew it, so plan a migration to DigiCert (or Sectigo) before that renewal date rather than after.

Regardless of which authorized CA you use, all require:

1. Evidence of a registered trademark covering the logo in the relevant jurisdiction, pending trademarks are not accepted
2. Logo validation against the BIMI SVG Tiny P/S profile
3. Domain control verification

The VMC process is not fast. Trademark evidence review and logo validation typically take several weeks. Factor that into any implementation timeline.

Once issued, the VMC is hosted at a stable HTTPS URL. The a= tag in the BIMI record points to that URL. The certificate embeds the logo via a logotype extension, so the receiving MTA can verify that the SVG it fetches matches the certificate.

Which mailbox providers require a VMC and which don't

Gmail has required a VMC for logo display since 2023, meaning domains with self-asserted BIMI records (l= tag only, no a= VMC pointer) show no logo in Gmail inboxes regardless of how well-formed the record is. Yahoo Mail and Apple Mail apply the same requirement.

Some smaller or European mailbox providers still honor self-asserted BIMI, a record with only the l= tag and no VMC. A domain can publish a basic BIMI record and see logo display in those clients before going through the VMC process. Coverage of the major consumer mailbox providers, however, requires a VMC. For most senders, self-asserted BIMI alone is not worth the implementation effort.

Notably, Microsoft has not adopted BIMI at all for Outlook, instead building a proprietary "brand cards" mechanism. A complete BIMI rollout in 2026 realistically covers Gmail, Apple Mail, Yahoo, and Fastmail, not Outlook, regardless of how correctly every layer is configured.

BIMI DNS Record Syntax: Selectors, Structure, and Common Errors

BIMI record syntax and the default selector

A BIMI DNS record is a TXT record published at:

default._bimi.<domain>

The minimum valid record for self-asserted BIMI:

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

With a VMC:

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

Tag reference:

Common syntax errors that cause silent failures:

• Trailing slash on the l= URL when the server doesn't expect it, the MTA fetches a 404, logo fails
• HTTP (not HTTPS) URL in l= or a=, both must be served over TLS
• Mismatched VMC URL, the a= tag points to a different domain or path than the VMC was issued for
• Missing semicolon after the last tag value, some DNS implementations are lenient, others are not; include it

BIMI selector record: when and why to use named selectors

The default selector is the fallback the receiving MTA uses when no selector is specified in the message. Most senders only need this one record.

Named selectors exist for two practical scenarios. First, a sender operating multiple brands from the same domain can publish separate BIMI records for each brand:

brand-a._bimi.example.com  IN TXT  "v=BIMI1; l=https://...; a=https://...;"
brand-b._bimi.example.com  IN TXT  "v=BIMI1; l=https://...; a=https://...;"

Second, a sender using multiple ESPs who wants different logos associated with different mail streams can use named selectors. The sending infrastructure references the selector via the BIMI-Selector header in the outbound message:

BIMI-Selector: v=BIMI1; s=brand-a;

The receiving MTA reads this header and looks up brand-a._bimi.<domain> rather than default._bimi.<domain>. If the header is absent or the named selector doesn't exist, the MTA falls back to default.

Named selectors are not a shortcut around the dependency chain. Each selector's VMC must still cryptographically match the logo it points to.

BIMI Troubleshooting: Reading the Failure Signal in the Authentication-Results Header

When BIMI evaluation occurs, the receiving MTA records the result in the Authentication-Results header. This is the primary diagnostic surface.

Possible outcomes:

Authentication-Results: mx.example.com;
  bimi=pass header.d=example.com header.selector=default;
  
Authentication-Results: mx.example.com;
  bimi=fail (DMARC not enabled) header.d=example.com;
  
Authentication-Results: mx.example.com;
  bimi=skipped (no BIMI record) header.d=example.com;

Reading these values:

• bimi=pass, all layers validated; logo should display in supporting clients
• bimi=fail, a layer in the chain failed; the parenthetical explains which one
• bimi=skipped, BIMI evaluation was not attempted, usually because no DNS record exists or DMARC wasn't present

Common failure reasons in the parenthetical:

For deeper diagnosis, reading the full delivery path in email headers shows how to trace the full chain of authentication results across hops. When the bimi=fail reason points upstream, to DMARC or DKIM, DKIM signature verification failures and diagnosing delivery failures from raw headers are the right companion references for isolating the break.

One consistent pattern: senders who reach BIMI configuration having never fully validated their DMARC setup discover failures at that layer first. The BIMI record is usually fine. The DMARC pct tag is at 90, or a subdomain is missing its own policy. Get the authentication stack clean, and the BIMI layer becomes the easy part.