What Is BIMI? How Brand Logos in Email Work
Brand Indicators for Message Identification (BIMI) lets a domain publish a preferred brand logo for participating mailbox providers to consider displaying beside authenticated messages. It builds on SPF, DKIM and DMARC, but a valid BIMI record is only one part of provider eligibility and never a guarantee that a logo will appear.
BIMI is a DNS-based way to point participating mailbox providers to an approved SVG brand logo. Before a provider will consider the logo, the visible From domain normally needs aligned email authentication and DMARC enforcement at p=quarantine or p=reject with pct=100. Providers can also require a VMC or CMC, sufficient sender reputation, and their own eligibility checks.
Overview
BIMI does not replace SPF, DKIM or DMARC. SPF authorizes sending infrastructure, DKIM signs message content, and DMARC checks whether at least one passing authentication method aligns with the domain visible in the From header. BIMI is evaluated after that authentication foundation. A receiver can look up the domain's BIMI Assertion Record, retrieve the logo and any evidence document, and then apply its own display policy.
The conventional record is a TXT record at default._bimi.example.com. A different selector can be used when a message explicitly requests it through a BIMI-Selector header. The record starts with v=BIMI1 and commonly contains an l= HTTPS URL for the logo plus an a= HTTPS URL for an evidence document such as a Verified Mark Certificate or Common Mark Certificate.
Why it happens
BIMI relies on DMARC enforcement because a logo would be misleading if an unauthenticated sender could publish the same visible identity. A p=none policy is monitoring-only, and pct below 100 leaves part of the mail stream outside full enforcement. BIMI guidance therefore treats p=quarantine or p=reject with pct=100 as the readiness baseline. Authentication still has to align on real messages; publishing strict DNS records alone does not prove that every sending platform is configured correctly.
How to fix it
Use the BIMI Inspector in a deliberate order: enter the organizational domain and selector; confirm that exactly one BIMI TXT record is found; review the parsed v, l and a tags; verify that the logo URL is HTTPS and fetchable; inspect the SVG Tiny PS structural findings; review the evidence-document metadata the tool can parse; and confirm the effective DMARC policy and pct value. Fix structural DNS, hosting, SVG or DMARC findings before investigating provider-specific eligibility.
MXFend reports syntactic and structural evidence available to the scanner. It does not establish a certificate chain's trust, revocation status, Certificate Transparency status, legal trademark rights, sender reputation or a mailbox provider's final display decision.
DNS record example
v=BIMI1; l=https://assets.example.com/brand.svg; a=https://assets.example.com/brand.pem
Examples
A typical record can look like: v=BIMI1; l=https://assets.example.com/brand.svg; a=https://assets.example.com/brand.pem. The exact evidence-document requirement depends on the mailbox provider. A self-asserted record without a certificate can be structurally valid while receiving limited or no display support.
Common mistakes
Common mistakes include publishing BIMI before DMARC enforcement is complete, using pct below 100, hosting a normal web SVG instead of SVG Tiny PS, serving the file with redirects or an incorrect content type, publishing multiple records for one selector, assuming a successful DNS lookup proves provider eligibility, and treating an evidence document as a guarantee of inbox display.
Checklist
- SPF and/or DKIM pass and align with the visible From domain on real mail.
- DMARC is enforced with p=quarantine or p=reject and pct=100.
- Exactly one BIMI1 TXT record exists for the intended selector.
- The l= URL is stable HTTPS and serves a compliant SVG Tiny PS file.
- The a= evidence URL, when required, is stable HTTPS and matches the certificate issuer's instructions.
- Provider eligibility and sender reputation are checked separately from structural readiness.
What BIMI can and cannot prove
A BIMI record communicates a domain owner's requested indicator and where supporting files can be fetched. DMARC alignment helps a receiver connect that request to authenticated mail. An evidence document can add independently issued identity or mark information. None of those signals forces a receiver to display the logo, proves that every message from the domain is legitimate, or improves deliverability by itself.
Provider-specific eligibility
Participating providers decide whether and where to display BIMI. Their rules can include a VMC or CMC, sending history, reputation, complaint levels, authentication consistency, message type and UI-specific policy. A domain can therefore be structurally ready in MXFend and still have no logo at one provider, intermittent display, or display only for some recipients.
Frequently asked questions
Does BIMI guarantee that my logo will appear in Gmail, Yahoo or Apple Mail?
No. A valid record, enforced DMARC, a compliant logo and any required certificate make the domain technically eligible for evaluation. Each provider still applies its own reputation, certificate, account and display policies.
Does BIMI replace SPF, DKIM or DMARC?
No. BIMI depends on the authentication and alignment supplied by SPF, DKIM and DMARC. It adds a brand-indicator lookup after that foundation; it is not an authentication mechanism for message content on its own.
Is a VMC or CMC always required?
The BIMI record format can reference an evidence document, but actual certificate requirements are provider-specific. Some providers offer little or no support for self-asserted logos, while others require a VMC or CMC. Check the current policy of each provider you care about.
What does the MXFend BIMI Inspector validate?
It checks the published record, selector, logo and evidence URLs, SVG structure and DMARC readiness that are observable by the engine. It does not prove legal ownership, certificate-chain trust, revocation, Certificate Transparency, sender reputation or final provider eligibility.