BIMI Email Logo Setup: What Must Pass Before It Appears

BIMI lets a domain owner publish a preferred logo for supporting email clients, but it does not authenticate a message and it does not guarantee that the logo will appear. DMARC supplies the authentication decision. BIMI supplies the logo location and, when used, evidence about the mark. The receiving provider still decides whether to display anything.

That separation is the key to a clean rollout. I treat BIMI as five gates, not one DNS record: aligned mail, an enforced DMARC policy, a safe logo asset, acceptable mark evidence, and a receiver willing to show the result.

The protocol is still developing. The current BIMI Internet-Draft was published on May 1, 2026 and expires on November 2, 2026. It is a work in progress, not an RFC. Provider rules can be narrower than the draft.

The five gates a BIMI logo must pass

1. The message passes DMARC. At least one aligned SPF or DKIM identity must authenticate the visible From domain. Publishing BIMI does not repair broken alignment.
2. The domain has an enforcement policy. Use p=quarantine or p=reject. For the broadest practical compatibility, set pct=100.
3. The indicator is safe to fetch and render. The logo is served over HTTPS in the constrained SVG format expected by the receiver.
4. The receiver accepts the evidence. A VMC or CMC may be required even though the protocol makes the a= authority-evidence location optional.
5. The receiver chooses to display it. Reputation, local policy, client support, and interface design remain outside the sender's control.

A pass at one gate cannot substitute for another. A valid SVG cannot compensate for DMARC failure. A certificate cannot force a mailbox provider to render the logo.

Which requirements come from the draft, and which come from providers?

This is where setup guides often become misleading. They merge the protocol, the BIMI Group deployment guidance, and one provider's product rules into a single universal requirement.

That is not a contradiction to hide. It is the operating model. The draft defines interoperable data. A mailbox provider decides what evidence and reputation it needs before using that data in its interface.

What goes in the BIMI DNS record?

For the default selector, publish one TXT record at default._bimi.example.com. This hypothetical record points to a logo and a mark certificate:

default._bimi.example.com. 3600 IN TXT (
  "v=BIMI1; "
  "l=https://assets.example.com/bimi/logo.svg; "
  "a=https://assets.example.com/bimi/mark.pem"
)

The parentheses and split strings above are DNS-zone-file presentation. Resolvers concatenate the strings into one TXT value.

• v=BIMI1 is required, must be first, and is case-sensitive.
• l= is the HTTPS location of the indicator. The draft requires the tag, although its value can be empty.
• a= is an optional HTTPS location for authority evidence. Provider policy determines whether evidence is practically required.

The draft's assertion-record definition says receivers must not repair capitalization or syntax mistakes. A record that looks close enough to a human can still be invalid.

How do you verify the chain before testing an inbox?

Do not start by sending a message and staring at the avatar slot. Check each dependency directly. Replace example.com and the asset URLs below with your own values.

# 1. DMARC policy at the organizational domain
dig +short TXT _dmarc.example.com

# 2. Default BIMI assertion
dig +short TXT default._bimi.example.com

# 3. Logo response, redirects, media type, and cache headers
curl -fsSIL https://assets.example.com/bimi/logo.svg

# 4. Save and inspect the first lines of the SVG
curl -fsS https://assets.example.com/bimi/logo.svg -o logo.svg
head -n 8 logo.svg

# 5. Save and inspect the certificate dates and identity
curl -fsS https://assets.example.com/bimi/mark.pem -o mark.pem
openssl x509 -in mark.pem -noout -subject -issuer -dates

A useful pass signal is evidence at every layer: the expected DMARC policy, exactly one valid BIMI record, successful HTTPS responses, a compatible SVG, and an unexpired certificate chain when your target provider requires one.

Google currently requires absolute SVG dimensions of at least 96 by 96 pixels. Its guidance also summarizes the SVG Tiny Portable/Secure restrictions: no scripts, animation, external references, or interactive elements. Those constraints reduce the attack surface of a file fetched and rendered by mail systems.

Keep the logo centered in a square and test it at small sizes. A technically valid wordmark can become unreadable when reduced to an inbox avatar.

Why can a correct BIMI record still show no logo?

A receiver evaluates more than the record. It first authenticates the message, discovers the selector, fetches the assertion, evaluates the asset and evidence, applies local reputation and policy, and then gives its mail client data it may display.

The sender controls the early inputs. The receiver controls the final decision.

So a missing logo does not by itself identify the failed layer. Work backward from observable evidence:

1. Confirm the message passed DMARC for the visible From domain.
2. Confirm the receiver queried the selector you intended.
3. Resolve the TXT record from more than one public resolver.
4. Fetch the exact HTTPS URLs without credentials or cookies.
5. Validate the SVG and certificate against the target provider's current rules.
6. Only then investigate provider eligibility or reputation.

If DMARC is not already at enforcement, stop there. Use aggregate reports to find every legitimate sender before changing policy. The DMARC aggregate-report guide shows how I separate raw SPF or DKIM results from actual alignment. The SPF, DKIM, and DMARC trace explains why one aligned pass is enough for DMARC.

Does a BIMI logo prove the message is safe?

No. BIMI can associate an eligible, authenticated domain with an approved indicator. It does not evaluate the sender's intent, the safety of a link, the legitimacy of an invoice, or whether an account was compromised.

The strongest fair objection is that a visible logo may cause recipients to trust a message too quickly. That is exactly why the boundary matters. Authentication answers whether a domain authorized the message. It does not answer whether the person or system using that domain is behaving safely. A lookalike domain can also publish its own authentication records and its own visual mark. The DMARC phishing threat model covers those bypasses in more detail.

A rollout is complete before the logo appears

I would call the technical rollout complete when legitimate mail passes aligned DMARC, the enforcement policy is stable at 100%, the BIMI TXT record resolves, the public assets validate, and any required mark certificate is current. Document the selector and asset owners so a brand refresh does not leave stale DNS behind.

After that, test representative messages at the providers you care about and monitor authentication normally. A displayed logo is useful confirmation that one receiver accepted the chain. A missing logo is not proof that mail failed authentication, and a displayed logo is not proof that the message is safe.