Set up BIMI: from a DNS record to possible logo display

What BIMI does, and what a logo does not prove

BIMI stands for Brand Indicators for Message Identification. As at 27 September 2026, the relevant specification is the individual Internet-Draft version 14 of 1 May 2026. “Intended status: Standards Track” is an aim, not an adopted RFC. Providers already operate BIMI under their own rules. IETF Datatracker

A BIMI record points to a logo and, where applicable, evidence. It neither signs nor encrypts email. A mark certificate confirms certain verified relationships between an organisation, domain and logo; it is neither a DKIM signature nor a mail server's TLS certificate. A visible logo does not make links, invoices or attachments harmless. Conversely, a missing logo does not prove forgery. BIMI draft sections 4.1 and 8

Secure sending first, then plan brand display

The BIMI draft requires an enforced DMARC policy for the visible From domain and its organisational domain. p=none and an explicitly set sp=none exclude BIMI there. With p=quarantine, any present pct must not be below 100 under this draft. The actual message must also meet the authentication requirements; under certain conditions, the draft permits additional local trust decisions by the recipient, for example using ARC. A DNS record alone is never sufficient. BIMI draft section 7.1

The current DMARC standard, RFC 9989, removed pct. Google's BIMI guidance still specifies pct=100; the BIMI draft and provider guidance use the older requirements context here. This does not restore pct as an effective limit under RFC 9989. BIMI draft 14 does not explicitly address the new DMARC test mode t=y. Therefore, do not assume that a nominal reject policy in test mode will count as full BIMI enforcement. Google: set up BIMI

MTA-STS, DANE and DNSSEC address other protection tasks. They are not universal prerequisites for every logo arising solely from the BIMI draft; additional recipient requirements remain possible.

The receiving provider and mail app determine display

The following overview reflects the provider guidance read on 27 September 2026. It does not describe display measured by us.

Sources: Google, Apple, Yahoo, Fastmail. Some provider guidance describes other providers using outdated information: for example, Fastmail's statement that Gmail requires a VMC exclusively is superseded by Google's own current VMC/CMC guidance.

A logo may also come from an address book, profile or another brand programme. The visible image alone cannot establish a BIMI, VMC or CMC verification route. Programmes such as trustedDialog or Apple's own brand offerings must not be equated with BIMI without specific provider evidence.

VMC or CMC: clarify evidence and acceptance first

VMCs (Verified Mark Certificates) and CMCs (Common Mark Certificates) differ particularly in the permitted evidence of a mark. A VMC often relies on a registered trademark; issuer rules recognise additional eligible categories. A CMC may be an option for certain unregistered logos. “Used somewhere for twelve months” is no general qualification: the Prior Use route has specific evidence requirements for earlier use on the relevant website. Other CMC categories have different prerequisites.

The BIMI Group list names DigiCert, GlobalSign and SSL.com on the review date. The group does not itself certify these issuers or guarantee acceptance by mailbox providers. Order only after comparing current issuer conditions with target recipient rules. This chapter does not assess trademark rights or promise prices or delivery times.

Prepare the logo as SVG Tiny Portable/Secure

An ordinary SVG export is not automatically suitable for BIMI. The Tiny-PS profile excludes active content, external resources and animations. It includes the SVG namespace, version="1.2", baseProfile="tiny-ps" and a non-empty title. Google additionally requires absolute dimensions of at least 96 × 96 pixels; a square, centred layout, solid background and size of no more than 32 KB are recommendations there. Fastmail requires less than 16 KB. SVG Tiny-PS draft, Google

This entirely invented two-colour logo demonstrates the file structure. It is neither a trademark nor a certified logo:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2"
     baseProfile="tiny-ps" width="96" height="96" viewBox="0 0 96 96">
  <title>Example logo</title>
  <desc>Blue square with a smaller white square.</desc>
  <rect width="96" height="96" fill="#16324f"/>
  <rect x="28" y="28" width="40" height="40" fill="#ffffff"/>
</svg>

Keep explanatory notes outside the XML file. The x and y attributes on shapes such as rect differ from the identically named attributes prohibited on the svg root element by the profile. Check the profile, forbidden elements, size and recipient requirements. Well-formed XML does not prove full Tiny-PS conformity or eligibility for certification. Use the same agreed logo for the evidence application and the published file.

Configure the record, selector and HTTPS files

The default selector is default; the specification permits other selectors. A synthetic record for example.com might look like this:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://assets.example.com/logo.svg; a=https://assets.example.com/mark.pem"

The example addresses are not hosted files. If the recipient has no certificate requirement, a record containing only v and a valid l may be used; this is not a low-cost substitute for evidence required by your target provider.

A documented difference: Draft 14 requires a valid l reference for logo display and describes an empty l as declining to publish. Google, by contrast, shows a PEM route with l=;a=https://… when the evidence contains the logo. This is provider guidance, not a universal BIMI rule. Our example explicitly publishes both URLs. BIMI draft sections 4.3 and 7.3, Google, step 4

Discovery first considers the From domain and, where applicable, the organisational domain using the same selector. Multiple matching records are not a valid resilience strategy. Hosting requires publicly reachable HTTPS files and a suitable certificate chain. A successful HEAD request alone validates neither SVG content nor a mark certificate. BIMI draft sections 7.2–7.4

A practical order for rollout and operation

1. Clarify aims: Identify relevant receiving providers and mail apps, and read their current conditions. A blanket percentage for the German-speaking market does not help here.
2. Check sending: Record the From and organisational domains, every sending service, DMARC policy and message authentication. Stop if legitimate failures remain unexplained.
3. Prepare the logo and evidence: Check the profile, rights and evidence category; commission an accepted issuer if needed. Do not change a logo solely for display without checking.
4. Publish files: Make the SVG and required evidence reachable over HTTPS; inspect the content and certificate chain.
5. Set the record: Publish exactly one suitable BIMI record; compare all DMARC conditions relevant to the From and organisational domains again.
6. Observe your own messages: Send from the services actually used to your own or explicitly agreed destination mailboxes. Document headers, provider, app, time and display separately.
7. Maintain: Manage evidence expiry and revocation, HTTPS availability, logo changes and changes to recipient rules.

This operational trial was not performed for this manuscript. If an error occurs, correct the logo, evidence or record. If a DMARC policy changed for the BIMI rollout affects legitimate mail, controlled rollback takes priority over the logo. Removing a BIMI record does not immediately end every cached display or revoke a certificate.

Assess reach and value against your own sending

Mailbox market share is not BIMI reach. A DNS record on one company domain proves neither adoption across a whole brand nor actual display. It also establishes neither open rates nor supposed protection against phishing.

What the Email Security Check reads for BIMI

The Email Security Check queries default._bimi.<entered name> and reads HTTPS addresses for the logo and evidence from a uniquely identified record. It does not fetch the files. SVG, VMC/CMC type, validity period, trust chain, trademark rights and mailbox display are not validated. BIMI and certificate references are unweighted indications; their absence does not prove an email security vulnerability.

This route does not fully check BIMI prerequisites either: no message, no other selectors, no complete BIMI discovery at the organisational domain and no exhaustive comparison of both policies with sp and historical pct. The check's additional DMARC note is not BIMI approval. It also provides no expiry warning for mark certificates.

Brand display is not evidence of compliance

A logo or mark certificate does not demonstrate fulfilment of legal security requirements. Logo rights, issuance conditions, data processing and technical security are separate questions. The legal and organisational connection is covered in email compliance; BIMI does not replace that assessment.