BIMI: How Brand Indicators for Message Identification Works

BIMI stands for Brand Indicators for Message Identification. It is an email-authentication standard that lets a sender publish a brand logo for supporting mailbox providers to evaluate and, where their own policies permit, display beside the sender’s messages.

BIMI is not an image-upload feature. It sits on top of authenticated email, DNS, a constrained SVG format, and receiver policy. A correct BIMI record does not compel an inbox to show a logo. Mailbox providers make their own decisions for individual domains.[1]

The practical path has four parts:

1. authenticate the sending domain and enforce DMARC;
2. prepare a valid SVG Tiny Portable/Secure logo;
3. publish the BIMI assertion record and, where required, a certificate file; and
4. test the deployed domain rather than assuming that publication alone is enough.

Run a BIMI domain audit or validate a logo before changing DNS.

What BIMI does

A BIMI assertion record identifies the location of a logo file and, when applicable, a certificate file. A supporting receiver can retrieve those resources, evaluate them alongside the sender’s authentication, and decide whether to render the indicator.

The result is a recognisable sender identity in a recipient’s inbox. The underlying objective, however, is stronger sender authentication. BIMI depends on DMARC; it does not replace DMARC, SPF, or DKIM.

What BIMI does not do

BIMI does not guarantee inbox placement, sender reputation, or logo display. A technically valid record can still fail to display if the receiving provider applies a different policy, if a resource cannot be fetched or validated, or if the message does not meet the receiver’s authentication conditions. BIMI should therefore be implemented as part of a broader authenticated-email programme, not as a cosmetic shortcut.[1]

The implementation path

1. Enforce DMARC

For Google’s documented BIMI workflow, DMARC must be configured with a policy of p=quarantine or p=reject and pct=100; p=none does not qualify.[2] SPF or DKIM must also authenticate the mail in a way that satisfies DMARC alignment.

If the domain is still at monitoring mode, begin with a controlled DMARC programme. DMARCSwiss is the portfolio service for ongoing aggregate-report monitoring and policy progression. This page does not treat p=none as BIMI-ready.

Read the detailed DMARC requirement guide.

2. Prepare an SVG Tiny P/S logo

BIMI uses a restricted SVG profile intended for safe rendering in a security-sensitive environment. Standard design-tool exports frequently contain unsupported elements, external references, scripts, animations, or geometry that needs normalisation.

Google’s published guidance includes SVG Tiny P/S requirements and Gmail-specific conditions, including absolute pixel dimensions and recommendations on square presentation, solid backgrounds, file size, and a desc element.[2]

makeBIMI converts and validates SVG assets against the relevant technical constraints. The result is a technical validation, not a promise that a certificate authority or mailbox provider will accept the final deployment.

Convert or validate a logo · Read the SVG Tiny P/S guide · Read the technical standard

3. Publish the BIMI record

A default BIMI assertion record is published at:

default._bimi.example.com

A representative record is:

v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/certificate.pem

The v= tag declares the BIMI version. The l= tag identifies the hosted SVG. The a= tag identifies the certificate file when the receiver’s implementation requires one.

Resources must be publicly reachable over HTTPS and must remain stable after publication. Google’s guidance explains certificate-file construction and states that the entity certificate, intermediate certificates, and root certificate are typically appended in that order when a PEM file is used.[2]

Read the BIMI DNS record guide before publishing a live record.

4. Determine whether a certificate is needed

Receiver requirements differ. Google documents a VMC or CMC for its BIMI setup, and states that Gmail’s verified checkmark is associated with a VMC.[2] A VMC is based on a trademarked logo and a rigorous verification process. A CMC may be available for eligible non-trademark use cases, subject to current certificate-authority and receiver requirements.

The portfolio-approved active VMC issuer wording is: DigiCert and Entrust are the active VMC issuers. Do not rely on historical issuer lists or assume that any certificate type produces the same receiver result.

Read the VMC and CMC guide · Compare VMC and CMC · Talk to veriBIMI

Receiver policy matters

The BIMI standard gives receivers a common way to obtain and evaluate logo information. It does not remove receiver discretion. The BIMI Group states explicitly that a mailbox provider is not required to display a logo for a domain that employs BIMI and can make local determinations for individual domains.[1]

For this reason, makeBIMI will maintain a dated BIMI Receiver Requirements Matrix. It will separate documented provider requirements from general standards rules and mark uncertain or undocumented behaviour as such. It will not infer support from screenshots, third-party claims, or legacy blog posts.

Common reasons a logo does not appear

The usual causes are straightforward:

• DMARC is still set to p=none, or the sending stream is not aligned.
• The SVG contains prohibited content or does not meet a receiver’s documented constraints.
• The BIMI assertion record is malformed, published under the wrong selector, or not yet visible in DNS.
• The hosted SVG or PEM file cannot be fetched securely.
• The certificate chain or logo relationship does not validate.
• A third-party sending platform is not configured for aligned authentication.
• The receiving provider does not display the indicator for that message or domain.

Use the BIMI audit to inspect the observable domain configuration, then follow the appropriate technical guide rather than changing several controls at once.

A disciplined implementation sequence

Related implementation guides

• BIMI technical standard
• BIMI email-client support
• BIMI with third-party senders and ESPs
• How to check whether BIMI is working
• Why a BIMI logo is not displaying
• BIMI and Microsoft Outlook

Frequently asked questions

Does BIMI work without DMARC enforcement?

Not in Google’s documented BIMI flow. Google requires a DMARC policy of p=quarantine or p=reject and pct=100, rather than p=none.[2]

Is a normal SVG enough?

No. BIMI uses a constrained SVG Tiny P/S profile. A logo that renders on a website can still include elements that do not meet BIMI constraints. Validate the final hosted asset rather than assuming a design-tool export is suitable.

Does a valid BIMI record guarantee a logo in every inbox?

No. Receiver display remains a receiver decision. The BIMI Group notes that providers may make local determinations for individual domains.[1]

Which VMC issuers are active?

For portfolio content, use the approved current wording: DigiCert and Entrust are the active VMC issuers. Certificate and receiver requirements can change, so verify current requirements before an application.

Sources

[1] BIMI Group — Mailbox Providers

[2] Google Workspace Admin Help — Set up BIMI

[3] BIMI Group — Supporting Documents