Quick answer
BIMI (Brand Indicators for Message Identification) lets your domain publish a brand logo that participating mailbox providers can display next to your authenticated messages. It is gated behind strong authentication: your organizational domain must have DMARC at an enforcement policy (p=quarantine or p=reject), the logo must be an SVG Tiny Portable/Secure file, and a Verified Mark Certificate (VMC) is what actually makes the logo display at the major providers. You publish it as a single DNS TXT record at default._bimi.<yourdomain> of the form v=BIMI1; l=<logo URL>; a=<VMC URL>. BIMI is an emerging standard maintained by the AuthIndicators Working Group and the BIMI Group — an IETF draft, not a finalized RFC — and provider support varies.
What BIMI is for
BIMI turns a verified brand into a visible inbox signal. When it works, the recipient sees your logo beside the message in the message list or the open view, which is both a trust and a recognition cue. But a logo is only meaningful if the mail is genuinely yours, so BIMI is deliberately built on top of email authentication rather than alongside it. It does not authenticate anything itself; it rides on the proof that DMARC at enforcement already provides and adds a display layer.
That dependency is the most important thing to understand about BIMI: it is a reward for finishing the authentication journey, not a shortcut. If your domain is not yet enforcing DMARC, BIMI is not the next step — getting to enforcement is.
The DNS record and the three pieces
BIMI is published as a TXT record at default._bimi.<yourdomain>:
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"
v=BIMI1— the version.l=— the HTTPS URL of the logo file.a=— the HTTPS URL of the authority evidence, i.e. the Verified Mark Certificate.
default is the selector. Senders can request a different selector with a BIMI-Selector header, but default is the common case. Behind that one record sit three real pieces of work: the DMARC enforcement prerequisite, the logo in the right format, and (in practice) the VMC.
The DMARC enforcement prerequisite
BIMI requires DMARC at enforcement on the organizational domain, and on subdomains via the sp= tag: p=quarantine or p=reject. A p=none policy — monitor-only — does not qualify, and neither does partial enforcement. This is the gate. The reasoning is direct: displaying a brand indicator next to mail that can still be spoofed would actively mislead recipients, so BIMI only applies once unauthenticated mail for your domain is already being quarantined or rejected. If you are not there yet, work through the staged rollout from p=none to p=reject first.
The logo: SVG Tiny PS
The logo cannot be an arbitrary image. It must be an SVG Tiny Portable/Secure (SVG Tiny PS, sometimes written SVG P/S) file — a restricted, security-hardened subset of SVG with no scripts and no external references, square, and hosted over HTTPS. A logo exported normally from a design tool will usually be rejected until it is converted to the Tiny PS profile with the required attributes. This conversion is a common stumbling block and is part of why BIMI setup is more involved than a single DNS edit.
The VMC and provider support
The a= tag points to a Verified Mark Certificate, a certificate that attests you own the trademark on the logo, issued by an authorized certificate authority and typically requiring a registered trademark. In the specification the VMC is described as highly recommended but technically optional.
In practice, the VMC is what makes BIMI display at the providers most people care about. Self-asserted BIMI — a record with no VMC — has limited support across mailbox providers, and major providers such as Gmail and Apple Mail require a VMC before they will render the logo. Because provider behavior here is evolving, treat the VMC as effectively required for broad display, and re-check current provider requirements before committing to the cost of obtaining one.
How to set up BIMI
The order matters, because most of the work is upstream of the DNS record.
First, reach DMARC enforcement (p=quarantine or p=reject) on your organizational domain and subdomains — this is the hard prerequisite. Next, produce an SVG Tiny PS version of your logo, square and hosted over HTTPS at a stable URL. Then decide on a VMC: if you want the logo to appear at Gmail, Apple Mail, and similar providers, obtain a VMC from an authorized issuer (which requires a trademark on the logo). Publish the default._bimi TXT record with v=BIMI1, the l= logo URL, and the a= VMC URL. Finally, validate that the record parses, the SVG is valid Tiny PS and reachable, and the VMC chains correctly — then expect display to vary by provider and take time to appear.
What this does not prove
A public check can confirm that your default._bimi TXT record exists and parses, that the logo URL and VMC URL resolve over HTTPS, and that your DMARC policy is at enforcement. It cannot guarantee that any given mailbox provider will display your logo — display is provider-specific, gated on a valid VMC at the major providers, and still changing as the standard matures. It also cannot validate the contents of the SVG against the full Tiny PS profile or verify the VMC's trademark attestation. Publishing a correct record over an enforced DMARC policy is the groundwork; actual logo display depends on each provider's current, evolving support.