BIMI and Verified Mark Certificates: Requirements, Setup and Pitfalls Explained

BIMI lets a sender's logo appear next to its mail in supporting inboxes, but only for domains that have already proven, through DMARC enforcement and usually a Mark Certificate, that their mail cannot easily be spoofed. Most failed BIMI projects stall on the prerequisites rather than on the DNS record: a DMARC policy left at p=none, a subdomain policy nobody checked, an SVG that is not SVG Tiny PS, or a trademark that does not match the logo submitted for a Verified Mark Certificate (VMC). This guide explains what Brand Indicators for Message Identification (BIMI) is, the requirements in the current Internet-Draft and the Mark Certificate Requirements, how VMCs and Common Mark Certificates (CMCs) differ, how to implement and evidence it, and the mistakes that keep logos from showing. It is written for email, DNS and brand protection teams. For choosing a DMARC reporting service see the DMARC Buyer's Guide; this page does not repeat it. Sources were checked on 8 November 2026.

Key takeaways

• BIMI is a reward for enforcement, not a control in itself. The security value is the DMARC policy at quarantine or reject that it requires; the logo is the incentive that often gets that enforcement funded.
• The specification is still an Internet-Draft. The BIMI document on the IETF datatracker is draft-brand-indicators-for-message-identification-15 (31 October 2026), an individual draft with intended status Standards Track and no formal IETF standing, so details can change.
• A certificate is optional in the draft but required in practice for the largest inboxes. Gmail only displays BIMI logos supplied in a PEM file with a VMC or CMC; standalone SVG files are not supported there.
• VMC needs a registered trademark, CMC does not. The Mark Certificate Requirements (MCR) v1.8 define VMC subtypes for Registered and Government Marks and CMC subtypes for Prior Use, Modified Registered Trademark and Provisional marks.
• Every subdomain matters. The draft rejects a published sp=none, and the BIMI Group asks for enforcement on the organisational domain and its subdomains, so a forgotten marketing subdomain can block the whole brand.

What it is and who it applies to

BIMI is a DNS-published assertion that says: for mail from this domain that passes DMARC, here is the logo to show, and here is the evidence that the domain owner is entitled to use it. A receiving mail system that supports BIMI checks DMARC, looks up the BIMI record, fetches and validates the logo and evidence document, and passes the result to the mail client. The receiver, not the sender, decides whether to display anything.

• Who publishes it: any domain owner that sends mail to consumers or customers, typically retail, banking, SaaS and public sector senders with high phishing exposure. Domains that never send mail should not publish BIMI; protect them as described in the Domain Without Email guide.
• Who maintains it: the AuthIndicators Working Group (the BIMI Group) publishes the implementation guide and the Mark Certificate Requirements. Mark Verifying Authorities (MVAs), which are certificate authorities approved under the MCR, issue VMCs and CMCs.
• Who consumes it: mailbox providers that have chosen to support it. Each sets its own display criteria, and the BIMI Group says future programmes may require certificates. Gmail shows a checkmark next to senders verified with a VMC.
• What it is not: BIMI does not authenticate mail by itself, does not stop lookalike domains (a lookalike can run its own DMARC), and is not a deliverability guarantee. Treat any claim that it improves inbox placement as unproven unless a provider documents it.

Structure and key requirements

The requirements come from three layers: the IETF draft (record format and receiver processing), the BIMI Group implementation guide and MCR (certificates and logos), and each mailbox provider's own rules. The table pulls the checked requirements together.

A note on DMARCbis: RFC 9989 removed the pct tag and added t=y for testing. The BIMI draft text still expresses the quarantine requirement as pct=100. Until mailbox providers document how they treat the new tags, the safe reading is: publish p=reject (or quarantine) without pct below 100 and without t=y on any domain where you want a logo.

Record anatomy

• Default record: default._bimi.example.com TXT "v=BIMI1; l=https://brand.example.com/bimi/logo.svg; a=https://brand.example.com/bimi/vmc.pem"
• Declining BIMI for a subdomain: v=BIMI1; l=; a=; explicitly opts a selector out. Receivers fall back from the Author Domain to the same selector at the organisational domain, so use this where a subdomain must not inherit the brand logo.
• Alternative selectors: a sender can choose a non-default selector with the BIMI-Selector header (v=BIMI1; s=<selector>), which the draft says should be covered by the DMARC-aligned DKIM signature. Use this for sub-brands that share a sending domain.
• Receiver-added headers: BIMI-Location and BIMI-Indicator are inserted by the receiving system. The draft says senders must not set BIMI-Location, so strip any such header at your outbound gateway.
• Results: receivers record the outcome in Authentication-Results as bimi= with values such as pass, none, fail, temperror, declined or skipped. These headers in received test mail are your main troubleshooting evidence.

VMC and CMC compared

Identity and NHI requirements

BIMI looks like a branding feature, yet it rests on several identities and credentials that need ownership.

• Sending identities: every platform that sends as your domain (marketing, CRM, ticketing, billing) needs SPF or, better, aligned DKIM, or enforcement will reject its mail. The DKIM private keys and the API keys of these platforms are non-human credentials; see the SendGrid, Mailgun and Mailchimp API Keys Security Guide.
• DNS write access: whoever can change the _bimi or _dmarc records can display a logo or break enforcement. Protect registrar and DNS provider accounts with phishing-resistant MFA and change alerts; see the Authoritative DNS and Registrar Account Security Guide.
• Web hosting of the PEM and SVG: the l= and a= URLs point at web content. A compromised CDN or storage bucket could swap the file. Host on a controlled origin, restrict write access to a deployment identity, and monitor for changes.
• Human identities in certificate issuance: the MCR requires named contract signers and certificate approvers and face-to-face verification. Record who these people are, and plan for them leaving.
• Brand impersonation: attackers use lookalike domains and display names (ATT&CK T1583.001 Domains for acquisition, T1566 Phishing for delivery). BIMI helps only on your real domain; pair it with the Domain Portfolio and Lookalike Domain Management Guide.

Implementation steps

1. Inventory sending sources. Use 30 to 60 days of DMARC aggregate reports to list every source sending as the organisational domain and each subdomain. Fix alignment for each one before tightening policy.
2. Move DMARC to enforcement everywhere. Reach p=quarantine or p=reject on the organisational domain, set sp explicitly to quarantine or reject, and remove pct below 100 and t=y. Subdomains with their own _dmarc records must also be enforced. Rollback: revert to the previous policy record, which takes effect as caches expire, so keep TTLs on _dmarc modest during the change.
3. Decide on the certificate. If the exact logo is a registered trademark in a jurisdiction the MVA accepts, choose a VMC. If not, choose a CMC or start trademark registration in parallel. Confirm the mark image in the trademark record matches the SVG you will publish.
4. Produce the SVG Tiny PS logo. Square, centred on a solid background, absolute pixel dimensions, a <title> and <desc>, no scripts or external references, ideally 32 KB or less. Validate it with a BIMI SVG checker before submitting it to the MVA, because the MVA embeds that exact image.
5. Complete MVA validation. Prepare corporate registration evidence, the trademark record, the named approver and signer, and the face-to-face verification. Make sure CAA records on the domain permit the chosen MVA.
6. Host the files. Publish the PEM (SVG plus certificate chain, intermediates and root appended in issuance order for Gmail) and the SVG over HTTPS on a controlled origin with a stable URL.
7. Publish the BIMI record in a pilot. Start with a selector on one sending stream, or publish default._bimi once tests pass. Add explicit declination records on subdomains that must not show the logo.
8. Test. Send to test mailboxes at the providers you target, read Authentication-Results for dmarc= and bimi=, and allow up to 48 hours for Gmail to display the logo. Rollback is simple: remove the TXT record or publish the declination form.
9. Operationalise renewal. Track the Mark Certificate expiry date, the trademark renewal date and the TLS certificate for the hosting origin in the same calendar as other certificates; see the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Decision guidance

• Small organisations: the expensive part is the certificate and, for VMC, the trademark. If the brand is not regularly impersonated in consumer mail, reach DMARC enforcement first and treat BIMI as optional.
• Large or multi-brand organisations: use selectors for sub-brands, a central owner for all _bimi and _dmarc records, and one renewal tracker. Each logo on its own certificate keeps a change to one brand from affecting the others.
• Self-asserted BIMI (no a= tag): cheap to publish, but the BIMI Group says support is limited, and Gmail will not display it. Use it only where your target providers document support.
• VMC versus CMC: choose VMC when the checkmark matters to customers and the trademark exists; choose CMC to move faster or to use a variant logo.

Evidence and assessment

Auditors and brand teams will ask different questions; keep evidence for both.

Metrics that show it is working:

• Percentage of sending domains and subdomains at p=quarantine or p=reject (target 100 percent of domains in BIMI scope).
• Percentage of legitimate volume passing aligned DKIM, from aggregate reports.
• bimi=pass rate in seeded test mail per target provider.
• Days of warning before Mark Certificate, trademark and hosting TLS expiry (alert at 60 days or more).
• Number of unauthorised sources still sending as the domain, trending to zero.
• Time to detect a change to _bimi, _dmarc or the hosted PEM file.

Mapping to other frameworks

BIMI is not named in the control catalogues below. What maps is the authentication and monitoring that BIMI depends on.

Common pitfalls

• Organisational domain enforced, subdomains not. An explicit sp=none, or a subdomain with its own p=none record, disqualifies the domain. Check every _dmarc record, not just the apex.
• Logo does not match the trademark. A refreshed brand colour or a removed tagline means the SVG no longer matches the registered mark, and the MVA will refuse a VMC. A CMC (Modified Registered Trademark) may fit; plan before a rebrand.
• Wrong SVG profile. Exporting plain SVG from a design tool leaves scripts, x/y attributes on the root or relative dimensions. Gmail requires SVG Tiny PS and absolute pixel dimensions.
• Standalone SVG for Gmail. A record with only l= and no certificate is not displayed in Gmail, which needs the PEM bundle.
• Expired certificate or moved file. A website migration that changes the PEM URL, or an unrenewed Mark Certificate, silently removes the logo. Monitor the URL and the expiry.
• Expecting BIMI to stop phishing. Lookalike domains and display-name spoofing are untouched. Customer awareness that "a logo means safe" can backfire if attackers use lookalikes; keep messaging accurate, and see the How to Spot a Phishing Email Guide.

Practitioner checklist

• All sending sources identified from DMARC aggregate reports and aligned with DKIM.
• p=quarantine or p=reject on the organisational domain, sp explicitly enforced, no pct below 100 and no t=y.
• Every subdomain _dmarc record checked; declination BIMI records on subdomains that must not show the logo.
• Certificate type chosen (VMC or CMC) and trademark record matched to the exact SVG.
• SVG Tiny PS 1.2 logo validated: square, absolute pixels, at least 96 x 96, no scripts or external references.
• CAA records permit the chosen Mark Verifying Authority.
• PEM and SVG hosted over HTTPS on a controlled origin with change monitoring and restricted write access.
• Authentication-Results show dmarc=pass and bimi=pass at target providers before announcing.
• Mark Certificate, trademark and hosting TLS expiry dates in the certificate renewal tracker with named owners.
• DNS and registrar accounts protected with phishing-resistant MFA and change alerts.

Standards and references

• IETF: Brand Indicators for Message Identification (BIMI), Internet-Draft
• AuthIndicators Working Group: Mark Certificate Requirements
• BIMI Group: BIMI Implementation Guide
• Google Workspace Admin Help: Set up BIMI
• IETF: RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• CIS: Critical Security Controls v8.1
• MITRE ATT&CK: Phishing

Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · DMARC Buyer's Guide · Email Authentication Checklist · Brand Impersonation and Lookalike Domain Takedown Playbook