BIMI in plain English

What BIMI actually does

Open your inbox. Most senders show up with either a generic colored circle and a letter (the first letter of the sender's name), or a tiny photo if you have one in your contacts. BIMI replaces that initial avatar with a domain-controlled logo — the actual brand mark a recipient already associates with you.

That's the whole feature. It's not a security mechanism in the way DMARC is; it's a presentation mechanism that piggybacks on DMARC's authentication. BIMI's whole pitch is "the recipient can see at a glance that this message is from a real, authenticated sender." Visual trust signal at the point of the inbox.

Receivers that currently honor BIMI in some form: Apple Mail (iOS / macOS), Yahoo Mail, AOL, Fastmail, La Poste — and Gmail, partially, with the important caveat below. Outlook / Microsoft 365 added a "brand impressions" feature that's BIMI-adjacent but not full BIMI today.

The three required pieces

Piece 1: DMARC at p=quarantine or p=reject (with pct=100)

BIMI does not display unless your DMARC policy is at p=quarantine or stricter, applied to 100% of mail. p=none is explicitly disqualifying — receivers won't show the logo regardless of the rest of your setup.

This is the gate that filters out most BIMI deployments before they start. If you haven't already progressed past p=none, do that first. BIMI is a downstream reward for the harder authentication work.

Piece 2: a properly-formatted SVG logo (Tiny SVG profile)

Your logo must be saved as an SVG that conforms to the "SVG Tiny 1.2 PS/B" profile. It's a constrained subset of SVG — no scripts, no animations, no external references, no foreign content. Square aspect ratio, ideally rendered cleanly at 96×96 pixels.

Most enterprise logos need an explicit re-export to comply. Designers comfortable with SVG can usually produce a compliant version in 10-15 minutes. There are also free online "BIMI SVG validators" that will tell you which parts of your existing SVG are out of profile.

Piece 3: hosting + DNS

Host the SVG file at a stable HTTPS URL (anywhere — your CDN, S3, your marketing site). Then publish a DMARC-style TXT record at default._bimi.<your-domain>:

v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem

The l= tag is the SVG location. The a= tag is optional — it points to the Verified Mark Certificate (see next section). If you skip a= entirely, BIMI still works in some inboxes; in others (notably Gmail), it doesn't.

The Verified Mark Certificate question

A VMC is a certificate issued by a Mark Verifying Authority — currently DigiCert and Entrust. It cryptographically attests "this organization owns this trademark and is authorized to display this logo." The receiver checks the cert chain before showing your logo.

The catch: getting one requires a registered trademark on the logo. Pending applications don't count; common-law marks don't count. Pricing typically lands around $1,500-1,700 per year per organization, with possible volume discounts. The cert is good for the registered logo only — re-issued cert if you change the mark.

Receivers handle VMCs differently:

• Gmail — VMC is required. Without it, no logo display even if everything else is in order.
• Apple Mail — accepts both VMC-protected logos and self-asserted Common Mark Certificates (CMC) in some configurations. Some logos display without a cert entirely. Behavior has shifted across iOS / macOS releases.
• Yahoo / AOL — historically displayed self-asserted SVG without a VMC. Has been moving toward stricter VMC requirement; check current behavior.

The CMC option (Common Mark Certificate) is a cheaper alternative to the VMC for senders that don't have a registered trademark. CMCs are issued by the same authorities, cost less ($300-$700/year range), and cover unregistered marks via different validation. Receiver coverage is narrower than VMC.

What it's worth

Honest assessment, not a sales pitch:

• Brand recognition lift — measurable in published experiments, particularly in mobile inboxes where the logo occupies comparatively more of the rendered row. Credible reports from large B2C senders show open-rate lifts in the single digits.
• Phishing protection — the absence of your logo on a spoofed message is a visual cue, but only for recipients who already know your real logo and are using a BIMI-aware client. Don't deploy BIMI for security; deploy DMARC p=reject for security.
• Operational cost — if you don't have the trademark already, registering it is a multi-month process plus filing fees in the $250-$2000 range depending on jurisdiction. The ongoing VMC fee is the easier part.
• Audience matters — if your customer base is mostly Gmail-on-mobile, the VMC investment delivers the visible benefit. If they're mostly Outlook-on-desktop, the benefit is invisible (Outlook doesn't render BIMI logos today).

The decision rule we'd suggest:

• You already have a registered trademark and you're at p=reject — do it. The marginal cost is the VMC fee and a designer-hour for the SVG. Visual brand at the inbox is genuinely valuable for recognized brands.
• You're not yet at p=reject — wait. Get authentication right first; BIMI without enforcement does nothing.
• You don't have a registered trademark — try the SVG-only path (no a= tag). It works in some inboxes, costs nothing beyond designer time, and you can revisit VMC later if/when you trademark.
• You're a small B2B SaaS with a niche audience — probably not worth it today. The receivers your customers use heavily likely aren't the strong-BIMI ones, and the ROI on the VMC fee is hard to defend.

What we'll do for you (eventually)

BIMI tooling sits in our V3 plan — a /tools/bimi-validator that checks every piece of a deployment (SVG profile compliance, DNS record format, certificate chain, downstream receiver-by-receiver display behavior), plus in-app monitoring on a domain's BIMI tab. The auto-fix path (publish the BIMI DNS record, host the SVG for you, manage the cert renewal) is a further-out V3 item that pairs with the MTA-STS hosting work.

Today, BIMI deployment is manual — same pattern as MTA-STS. We monitor your DMARC policy and tell you when you've crossed the BIMI prerequisite threshold; the rest is on you (or your designer + your registrar + DigiCert).

Common deployment mistakes

Publishing BIMI before reaching p=quarantine

The BIMI DNS record is allowed; it just won't display anywhere. Recipients see no change. We see this regularly — the fix is to either complete the DMARC progression first or to remove the BIMI record until you do.

Using a non-Tiny SVG

Your standard logo SVG probably has metadata, scripts, or external font references that make it non-compliant with Tiny 1.2. Receivers reject non-compliant SVGs silently — no logo, no error, no notification. Validate before publishing.

Hosting the SVG on a flaky URL

Receivers fetch the SVG on their schedule, with their own caching. If your URL is occasionally 404 or 500, BIMI display becomes flaky. Static hosting (CDN, S3, your marketing site) is far better than a dynamic endpoint.

Forgetting to renew the VMC

Annual cert. Lapses silently. Set a calendar reminder a month out.

Related

• Progressing past p=none safely — the prerequisite. BIMI does nothing without it.
• What is DMARC? — the authentication scaffolding BIMI rides on.
• Why 1024-bit DKIM keys are being phased out — receivers look at DKIM key strength when deciding how much trust to extend, and BIMI display is part of that calculus.