BIMI and VMC: The Complete Guide

24 June 2026 · DMARC Engine · 12 min read

Brand Indicators for Message Identification (BIMI) is the standard that lets your verified logo appear next to your messages in supporting mailbox providers. It is the most visible reward for getting email authentication right: a small but powerful trust signal that turns the work you have already done on DMARC, SPF and DKIM into something your recipients can actually see. But BIMI is widely misunderstood. It is not a deliverability switch, it does not work without enforced DMARC, and in most major inboxes it now requires a paid certificate that ties your logo to a registered trademark.

This guide is the canonical reference for BIMI and the Verified Mark Certificate (VMC). It covers exactly what BIMI is and is not, the hard prerequisites you must satisfy first, the strict logo format (SVG Tiny Portable/Secure), the difference between a VMC and a Common Mark Certificate (CMC), which inboxes display logos and how, what it costs in money and time, and a complete deployment checklist you can follow end to end.

What BIMI actually is

BIMI is an open specification, maintained by the AuthIndicators Working Group, that publishes the location of a brand's logo (and optionally an authenticating certificate) in DNS as a TXT record. When a participating mailbox provider receives an email that passes its checks, it fetches the logo referenced in the sender's BIMI record and renders it in the avatar position next to the message, in the inbox list, the message header, or both.

The key idea is that BIMI piggybacks on authentication you already control. The receiver only trusts the logo if it can first prove the message genuinely came from your domain and that your domain enforces a policy preventing spoofing. In other words, BIMI is the visible layer on top of an invisible foundation. If the foundation is missing, the logo never appears.

What BIMI is not

Not a deliverability feature. Publishing a BIMI record does not improve your inbox placement, sender reputation or open rates by itself. The authentication that BIMI requires helps deliverability; the logo display is cosmetic.
Not a substitute for DMARC. BIMI sits downstream of DMARC. You cannot use BIMI to "get to reject faster"; it is the other way round.
Not universally supported. Only certain mailbox providers honour BIMI, and several of them require a paid certificate before they will show anything.
Not free, in practice. While the BIMI record and SVG hosting cost nothing, the major inboxes (Gmail, Apple Mail, Yahoo) require a VMC or CMC, which is a paid annual certificate.

The hard prerequisite: enforced DMARC

This is the single most important thing to understand about BIMI: your domain must publish a DMARC policy at enforcement. "Enforcement" means a policy of p=quarantine or p=reject. A policy of p=none, no matter how long it has been running, does not qualify.

There are further nuances that catch people out:

The DMARC record must be applied to the organisational domain (or the specific subdomain you send from), and it must be discoverable by the receiver.
Several providers will not honour BIMI if p=quarantine is set with a pct tag below 100. Gmail in particular expects full enforcement. The safest position is p=reject (or p=quarantine at 100%) with no partial-percentage tag.
The message itself must pass DMARC, meaning it passes SPF or DKIM and that passing mechanism aligns with the From-header domain. A message that fails DMARC will never show a BIMI logo even if your record is perfect.

A compliant DMARC record for a BIMI-ready domain looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s

If you are not yet at enforcement, BIMI is premature. Get DMARC to p=reject safely first, without blocking legitimate mail, using a staged ramp. This is exactly the journey we automate; see the enforcement journey and our hosted DMARC service, which moves you from p=none to p=reject while monitoring aggregate reports so nothing legitimate breaks. You can confirm your current policy in seconds with the DMARC checker.

Rule of thumb: if you cannot put p=reject on the domain without risking a mail outage, you are not ready for BIMI. Fix authentication coverage first, then layer the logo on top.

The BIMI DNS record

BIMI is published as a TXT record at a specific, structured hostname:

default._bimi.yourdomain.com

The default portion is the selector, analogous to a DKIM selector. default is the value almost everyone uses and the only one many receivers look for, but the spec allows other selectors, signalled per-message by the BIMI-Selector header so you could, in principle, show different logos for different mail streams.

The record itself has two main tags:

v: the version, always BIMI1.
l: the HTTPS URL of your SVG logo file.
a: the HTTPS URL of your certificate (VMC or CMC) in PEM format. Optional in the raw spec, but required in practice by Gmail, Apple Mail and Yahoo.

A minimal (logo-only) record:

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

A production record with a certificate:

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

Notes and pitfalls:

Both URLs must be served over HTTPS with a valid certificate. Plain HTTP is rejected.
An empty l= value with a present a= is a way of explicitly opting out while keeping the structure; an entirely absent record means "no BIMI".
Host the SVG and PEM on a stable, highly available URL. If the asset 404s or the TLS handshake fails when the receiver fetches it, the logo silently does not render.
Keep the file sizes sensible. Receivers impose practical size limits (the SVG should be small, well under the low-hundreds-of-kilobytes range; many guides target under 32 KB).

You can validate your published record and the assets it points to with the BIMI checker and inspect certificate details with the VMC checker.

The logo: SVG Tiny Portable/Secure (Tiny PS)

BIMI does not accept arbitrary images. The logo must be in a tightly constrained profile of SVG called SVG Tiny Portable/Secure (SVG Tiny PS). This is a hardened subset of SVG Tiny 1.2, designed to be safe to render inside an email client (no scripts, no external references, no animation) and to display cleanly at small sizes.

Hard requirements

Format: SVG Tiny PS specifically, not generic SVG, not SVG Tiny 1.1, not a rasterised PNG/JPG embedded in an SVG wrapper.
The root element must declare the profile: baseProfile="tiny-ps" and version="1.2".
A <title> element is required and should contain your brand or organisation name.
Square aspect ratio. The logo must be square (1:1): set a square viewBox, e.g. viewBox="0 0 512 512". Logos display in a circular or rounded-square avatar, so centre your mark with safe padding.
A solid, non-transparent background. Transparency is not allowed; fill the canvas with a solid colour (white is common, but use whatever suits your mark).
No scripting, no external links, no animation, no embedded raster images, no interactivity. These are the "Secure" part of Tiny PS and are strictly forbidden.

A conforming skeleton

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     baseProfile="tiny-ps" version="1.2"
     viewBox="0 0 512 512">
  <title>Your Organisation</title>
  <rect width="512" height="512" fill="#0B3D91"/>
  <path d="..." fill="#FFFFFF"/>
</svg>

Common logo pitfalls

Exporting "SVG" from a design tool and assuming it works. Illustrator, Figma and similar tools produce SVG that almost never conforms to Tiny PS out of the box: they include unsupported elements, missing profile attributes, or transparency.
Forgetting the baseProfile/version attributes. Without them the file is technically not Tiny PS and certificate authorities and receivers will reject it.
Non-square art or off-centre marks that get clipped by the circular avatar.
Leftover metadata, comments or unused definitions that bloat the file or include disallowed elements.

To convert and tidy an existing logo into a compliant file, use the BIMI SVG converter, then confirm conformance with the BIMI logo validator before you publish.

VMC vs CMC: which certificate do you need?

This is the most consequential, and most expensive, decision in a BIMI rollout. To display logos in the major inboxes, you need a certificate that vouches for your right to use the logo. There are two kinds.

Verified Mark Certificate (VMC)

A VMC proves you own a registered trademark for the exact logo you want to display. The certificate authority verifies your organisation's identity and confirms that the trademark is registered with a recognised intellectual-property office (for example the USPTO, the EUIPO, the UK IPO, or other accepted national registries) and that the registered mark matches your SVG.

Requirement: a registered trademark of the logo (a word mark is usually not sufficient; it generally needs to be the figurative/design mark you intend to show).
Issued by: a small number of authorised CAs (currently DigiCert and Entrust).
Accepted by: the broadest set of providers, including Gmail and Yahoo, and it is the route Apple Mail recognises.

Common Mark Certificate (CMC)

The CMC was introduced to lower the barrier for organisations that do not have, or cannot obtain, a registered trademark, for example because the mark is too new, has been in use without registration, or belongs to a government or non-profit body. A CMC verifies that the organisation has a legitimate claim to the mark (often via prior public use) without requiring a formal trademark registration.

Requirement: evidence of legitimate use of the mark, rather than a registered trademark.
Trade-off: broader eligibility, but narrower display support than a VMC. Not every provider that honours VMCs will honour CMCs, and CMC-displayed logos may be presented differently.
Status: a newer option; support is still expanding across mailbox providers.

You can model how each certificate type would render with the CMC simulator and preview overall behaviour with the BIMI simulator.

How to decide

If you own a registered figurative trademark for your logo (or can obtain one), get a VMC: it has the widest support and is the de facto standard.
If you cannot get a registered trademark but have a legitimate, demonstrable claim to the mark, evaluate a CMC, accepting that fewer inboxes will display it.
If you simply want the logo to exist in BIMI for the (shrinking) set of providers that show logo-only records without a certificate, you can publish without a=, but do not expect Gmail, Apple Mail or Yahoo to show anything.

Which inboxes display BIMI logos

Support is uneven and evolving, so treat the following as a general map rather than a guarantee. Behaviour changes as providers update their clients.

Gmail (Google Workspace and consumer): displays BIMI logos and requires a VMC (or CMC where supported) plus enforced DMARC. Logo-only records are not honoured.
Yahoo Mail / AOL: among the earliest adopters; supports BIMI and expects a certificate for major display.
Apple Mail (iOS, iPadOS and macOS): displays verified logos, recognising VMCs (and adding CMC support over time) for senders meeting Apple's authentication bar.
Fastmail and various others: have supported BIMI, in some cases including logo-only records.
Microsoft Outlook / Microsoft 365: historically the notable holdout. Microsoft announced BIMI support, and rollout has been progressing, but do not assume universal display across all Outlook surfaces; verify against current behaviour for your tenant.

Because display also depends on the message passing authentication and the receiver's own anti-abuse heuristics, even a perfectly configured domain will not show a logo on every single message at every provider. BIMI raises the ceiling; it does not guarantee a logo on each send.

Costs and timelines

There are three cost components to a BIMI deployment, and only one of them is recurring and significant.

DNS and SVG hosting: effectively free. You already control DNS; the SVG and PEM are small static files.
The trademark (for a VMC): if you do not already own a registered figurative trademark, registration is a separate legal process with its own fees and a multi-month timeline that varies by jurisdiction. This is often the longest pole in the project. A CMC avoids this requirement.
The certificate (VMC or CMC): a paid annual certificate from an authorised CA. Pricing is set by the CAs and varies, so we will not quote a figure here; request a current quote from DigiCert or Entrust. Budget for annual renewal, not a one-off.

On timelines: if you already hold the trademark and are at p=reject, issuing a VMC and publishing the record is typically a matter of days to a couple of weeks (the CA performs identity and trademark verification). If you need to register a trademark first, plan in months. Getting DMARC safely to enforcement is itself a project measured in weeks for most organisations, which is the part hosted DMARC is designed to compress and de-risk.

Step-by-step BIMI deployment checklist

Follow these in order. Skipping ahead is the most common reason BIMI "doesn't work".

Reach DMARC enforcement. Publish p=quarantine (100%, no reduced pct) or, ideally, p=reject on the sending domain. Confirm legitimate mail still authenticates by reviewing aggregate (rua) reports. Verify with the DMARC checker.
Confirm authentication coverage. Make sure every legitimate source passes SPF or DKIM with alignment. Watch for the SPF 10-lookup limit causing permerror, and ensure DKIM is signing on every stream with adequate key length. Our SPF checker and DKIM checker cover this.
Decide VMC vs CMC. Determine whether you hold (or can obtain) a registered figurative trademark. If yes, plan a VMC; if not, evaluate a CMC.
Prepare the logo as SVG Tiny PS. Produce a square, solid-background, script-free SVG with baseProfile="tiny-ps", version="1.2" and a <title>. Use the BIMI SVG converter and validate with the BIMI logo validator.
Obtain the certificate. Apply to an authorised CA (DigiCert or Entrust) for your VMC or CMC. Be ready to evidence organisation identity and the trademark/claim. The CA will issue a PEM that bundles the certificate and the logo.
Host the assets over HTTPS. Place the SVG and the PEM on a stable, valid-TLS URL. Confirm both load without redirect chains or TLS errors.
Publish the BIMI record. Create the TXT record at default._bimi.yourdomain.com with v=BIMI1, the l= SVG URL and the a= PEM URL.
Validate end to end. Use the BIMI checker and VMC checker to confirm the record parses, the SVG conforms, and the certificate chains and matches.
Send test mail and inspect real inboxes. Send to seed accounts at Gmail, Yahoo and Apple Mail. Remember the message must pass DMARC for the logo to render; a test from an unaligned source will not show it.
Monitor and renew. Track certificate expiry (it is annual), keep the hosting alive, and keep DMARC at enforcement. If you ever drop below p=quarantine, the logo disappears.

Troubleshooting: "I published BIMI but no logo shows"

Work down this list:

Is the test message actually passing DMARC? This is the number-one cause. Check the message headers for dmarc=pass and alignment. Use the email header analyzer.
Is DMARC at full enforcement? p=none, or p=quarantine with pct<100, will not satisfy Gmail.
Does the receiver require a certificate you have not supplied? Gmail, Yahoo and Apple need a=. A logo-only record shows nothing there.
Does the SVG truly conform to Tiny PS? Re-validate; a missing baseProfile, transparency, or a non-square viewBox will fail.
Are the asset URLs reachable over HTTPS from the public internet, with valid TLS and no 404?
Has the certificate expired or does it no longer match the published SVG?
Are you simply testing in a non-supporting client or surface? Confirm against a known-supporting inbox.

Next steps

BIMI is the visible payoff for doing email authentication properly, but it is genuinely the last step, not the first. The order is fixed: get SPF and DKIM clean, take DMARC to p=reject without breaking legitimate mail, then prepare a Tiny PS logo and obtain a VMC (or CMC) and publish the record. If any link in that chain is weak, the logo never appears.

If you are not yet at enforcement, start there: our hosted DMARC service and the enforcement journey walk you safely from p=none to p=reject. When you are ready to add the logo, our BIMI tooling, BIMI checker and VMC checker will get you from a compliant record to a verified logo in the inbox. For a quick health snapshot of any domain across all of these standards, run a scan with the DMARC checker.

The complete guide to BIMI and VMC