DMARC Analyzer

TL;DR

• BIMI (Brand Indicators for Message Identification) is the spec that puts your brand logo next to authenticated messages in the inbox. Defined in IETF draft-brand-indicators-for-message-identification plus the BIMI Group profile documents.
• BIMI is published as a DNS TXT record at default._bimi.<domain> with tags v=BIMI1; l=<svg-url>; a=<vmc-url>.
• DMARC is a hard prerequisite: the publishing domain must enforce p=quarantine or p=reject with pct=100. p=none is not eligible.
• The logo must be SVG Tiny PS (baseProfile="tiny-ps") — a strict sub-profile that forbids scripts, raster embeds, animation, and external references — square, under 32KB, with a solid background.
• Major mailbox providers (Gmail, Apple Mail, Yahoo, AOL, Fastmail) require a VMC (Verified Mark Certificate) issued by DigiCert or Entrust before displaying the logo.
• BIMI is a trust signal, not an authentication primitive. It rides on top of SPF + DKIM + DMARC; it does not authenticate the message itself.

1. What is BIMI?

BIMI (Brand Indicators for Message Identification) is an email standard that lets a domain owner publish a brand logo for receiving mailbox providers to display alongside authenticated messages in the inbox. BIMI is specified in IETF draft-brand-indicators-for-message-identification (still an Internet Draft, not yet a published RFC) and the de-facto industry profile documents from the Authindicators Working Group (BIMI Group). A BIMI record is a DNS TXT record at default._bimi.<domain> declaring the URL of an SVG Tiny PS logo and (optionally, but in practice required) the URL of a Verified Mark Certificate (VMC).

BIMI complements the existing email-authentication primitives — SPF (envelope-sender IP authorisation), DKIM (message cryptographic signature), and DMARC (policy + alignment + reporting). Where SPF / DKIM / DMARC authenticate the message, BIMI takes the authenticated result and renders it visible to the recipient as a brand logo in the inbox interface. The intent is two sided: it gives legitimate senders a visible trust signal end users can recognise, and it gives end users a heuristic for spotting unauthenticated impersonation (no logo where one is expected → likely phishing).

Critically, BIMI is not an authentication mechanism. It does not sign mail, does not authorise senders, does not produce a pass / fail verdict by itself. It rides on top of an already-passing DMARC verdict; a domain that fails DMARC alignment on a given send will not get a BIMI logo rendered for that send regardless of what its BIMI record contains.

2. How BIMI works, step by step

1. The domain owner enforces DMARC at p=quarantine or p=reject with pct=100. (This is a hard precondition — BIMI is ineligible at p=none.)
2. The owner prepares an SVG Tiny PS logo file (square, < 32KB, solid background, baseProfile="tiny-ps") and publishes it at an HTTPS URL.
3. The owner obtains a Verified Mark Certificate (VMC) from DigiCert or Entrust after proving trademark ownership in an accepted registry (USPTO, EUIPO, UKIPO, JPO, IPA, or CIPO). The VMC is a PEM-encoded certificate chain that the owner publishes at an HTTPS URL.
4. The owner publishes a BIMI DNS TXT record at default._bimi.<domain> declaring the SVG URL (l=) and VMC URL (a=).
5. When the receiving mailbox provider accepts a message and the message passes DMARC alignment, the receiver queries default._bimi.<rfc5322.from-domain> for the BIMI record, fetches the SVG from l=, fetches the VMC from a=, validates the certificate chain and the SVG hash binding, and renders the logo next to the message in the inbox.
6. If any step fails — DMARC not enforcing, SVG not Tiny-PS-compliant, VMC expired, URL not HTTPS, certificate not chained to an approved root — the mailbox provider silently falls back to its default (often a generated initials avatar). There is no error surface to the sender; debugging requires fetching the same artefacts the receiver fetches.

3. BIMI DNS syntax

A BIMI record is a DNS TXT record published at <selector>._bimi.<domain>. The default selector is default; per-stream selectors are possible (e.g. marketing._bimi) and declared in the BIMI-Selector: header of the signed message.

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

Tag-by-tag anatomy of the BIMI record:

v=BIMI1

Version tag. MUST appear first; receivers that find a missing or invalid v= reject the record. BIMI1 is the only defined version at the time of writing.

l=<https-svg-url>

Location of the SVG Tiny PS logo. MUST be an absolute HTTPS URL (HTTP is rejected). The host SHOULD serve the SVG with Content-Type: image/svg+xml and cacheable headers. An empty l= tells receivers the domain has explicitly opted out of BIMI for that selector — used to suppress logos on a specific selector without removing the record entirely.

a=<https-vmc-url>

Location of the Verified Mark Certificate (PEM format). MUST be an absolute HTTPS URL. The certificate cryptographically binds the SVG hash to the verified trademark. Without a=, major mailbox providers (Gmail, Apple, Yahoo, AOL) will not display the logo. Earlier in BIMI's rollout, a= was optional; the operational reality at major providers is now that it is required.

The selector name in the DNS query is determined by the sending message. If the message carries no BIMI-Selector: header, the receiver queries default._bimi.<domain>. If the message carries BIMI-Selector: v=BIMI1; s=newsletter, the receiver queries newsletter._bimi.<domain> — letting the domain publish different logos for transactional versus marketing versus newsletter streams.

4. SVG Tiny PS logo requirements

BIMI logos use a strict SVG profile called SVG Tiny 1.2 Portable/Secure (SVG Tiny PS), defined in the BIMI Group SVG profile specification. The profile strips everything that could be a security, privacy, or rendering risk inside a mailbox UI.

Required attributes on the root <svg>:

Forbidden in SVG Tiny PS (rejected by validators):

• <script> — no scripting under any circumstance.
• <a> hyperlinks, interactivity events (onclick, onload, etc.).
• External references — no <image href="...">, no xlink:href to external resources, no @font-face.
• Raster image embedding (PNG / JPEG via <image>).
• <animate>, <animateMotion>, <animateTransform>, SMIL.
• Most filters and masks (only a narrow allow-list survives).
• Foreign objects (<foreignObject>).

File-format requirements:

• Square aspect ratio: rectangular logos are cropped or rejected.
• File size < 32KB: the Authindicators Working Group profile caps the file size to keep inbox rendering fast.
• Solid (non-transparent) background: the logo must look correct against both light and dark inbox themes. Transparent backgrounds risk a broken-looking logo in dark mode.
• No DOCTYPE / XML declarations except <?xml version="1.0" encoding="UTF-8"?> on the first line.
• Title element: a <title> child of <svg> with the company name is REQUIRED for accessibility.

5. Verified Mark Certificate (VMC)

A Verified Mark Certificate (VMC) is an X.509 PKI certificate that cryptographically binds a registered trademark to the SVG logo and the publishing domain. VMCs are issued by DigiCert and Entrust, the two CAs currently approved by the BIMI Group consortium of mailbox providers.

Trademark registries accepted for VMC issuance:

• USPTO — United States Patent and Trademark Office.
• EUIPO — European Union Intellectual Property Office.
• UKIPO — UK Intellectual Property Office.
• JPO — Japan Patent Office.
• IP Australia.
• CIPO — Canadian Intellectual Property Office.
• Plus a small set of recognised regional registries. Check the CA's current list at issuance time; registry coverage expands periodically.

The VMC issuance process typically requires 3-6 weeks: the CA validates the trademark registration, validates domain control, cryptographically hashes the supplied SVG into the certificate, and issues the PEM chain. Renewal is annual.

A CMC (Common Mark Certificate) is a lower-tier variant that does NOT require a registered trademark — it accepts unregistered "common law" marks used in commerce for at least 12 months. Gmail extended CMC support in 2024 for the BIMI checkmark feature (the blue verified-mark badge); the SVG-display path still requires a full VMC. Check current Google Workspace documentation for the latest position.

6. Mailbox-provider compatibility

BIMI display is a tenant-level decision at each provider. Even when the sending domain has a valid BIMI record + SVG + VMC, the receiving provider can override based on its own brand reputation, abuse history, or operational concerns. Logo display is best interpreted as opportunistic, not guaranteed.

7. BIMI examples

7.1 Minimal BIMI record (with VMC, production)

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

The production-typical BIMI record. Both URLs are served over HTTPS from a dedicated subdomain (bimi.example.com) so the BIMI assets can have their own caching / availability profile, separate from the main site.

7.2 BIMI record without VMC (Fastmail-style, non-production)

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

A record without a= will validate on receivers that do not require a VMC, but will be ignored by Gmail / Apple / Yahoo / AOL. Useful only during early-stage testing or for receivers known to accept unsigned logos.

7.3 Per-stream selectors

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

The marketing send sets a BIMI-Selector: v=BIMI1; s=marketing header to direct receivers to the marketing record. Use cases: seasonal logos, sub-brand differentiation, A/B testing new logos before promoting them to default.

7.4 Explicit BIMI opt-out

default._bimi.example.com.  IN  TXT  "v=BIMI1; l="

An empty l= tells receivers the domain has explicitly opted out of BIMI for this selector. Useful if a brand temporarily wants to suppress logo display (during a logo refresh, brand-incident window, etc.) without dropping the DNS record entirely.

7.5 Minimal SVG Tiny PS logo skeleton

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 64 64">
  <title>Example Company</title>
  <rect width="64" height="64" fill="#0a3160"/>
  <path d="M8 32 L32 8 L56 32 L32 56 Z" fill="#ffffff"/>
</svg>

A minimal compliant SVG: explicit XML declaration, square 64×64 viewBox, baseProfile="tiny-ps", accessibility <title>, solid background fill, no scripts / no external references / no animation.

8. BIMI best practices

• Enforce DMARC at p=quarantine or p=reject with pct=100 before publishing BIMI. A BIMI record at p=none is ignored by every major receiver and looks like deployment cargo-cult.
• Validate your SVG against SVG Tiny PS before going live. BIMI Group's converter is the reference toolchain — strip unsupported elements rather than hope they'll be ignored.
• Host both SVG and VMC on HTTPS — plain HTTP fails validation. A dedicated subdomain (bimi.example.com) is the typical pattern.
• Get a VMC from DigiCert or Entrust. Start the trademark-verification process early; plan for 3-6 weeks from order to working certificate. The trademark itself must be registered first, which adds 6-24 months in most jurisdictions.
• Match the SVG hash in the VMC exactly. If you change the SVG content (even a single byte of optimization), the VMC stops binding to it and validation fails. Re-issue the VMC alongside any SVG update.
• Use the default selector unless you have a real per-stream-logo use case. Per-stream selectors are a maintenance burden; most senders never need them.
• Monitor DMARC aggregate reports before and after BIMI launch — a regression that drops your DMARC pass rate will silently kill logo display long before any user complaint surfaces.
• Set HTTP caching headers on the SVG + VMC endpoints: Cache-Control: public, max-age=86400 is a sensible floor. Receivers cache aggressively; a transient 503 on the SVG endpoint can disable BIMI for the receiver's cache TTL window.
• Renew the VMC before expiry. VMCs are valid for ~1 year; an expired certificate silently kills logo display. Calendar the renewal at VMC_expiry - 30 days.
• Keep the SVG file size well under 32KB. Optimise with SVGO configured for the Tiny PS profile; 4-8KB is a realistic target for a brand mark.

9. Common BIMI mistakes

• Publishing BIMI before DMARC enforces. At p=none, every major receiver silently ignores the record. The fix is sequential: DMARC migration first, BIMI second.
• Using a regular SVG (not Tiny PS). SVG files exported from Illustrator / Figma / Sketch contain elements forbidden by SVG Tiny PS — gradients with extra attributes, masks, embedded fonts, metadata blocks. Run the file through BIMI Group's converter rather than ship as-exported.
• Skipping the VMC. Major mailbox providers (Gmail, Apple, Yahoo, AOL) refuse to render BIMI logos without a VMC. The DNS record will look fine in validators but no logo will ever appear in production.
• Serving SVG / VMC over plain HTTP. Both URLs MUST be HTTPS. A redirect from HTTP to HTTPS is not enough — the BIMI record itself must declare HTTPS URLs.
• Updating the SVG without re-issuing the VMC. The VMC binds the certificate to the exact SVG bytes; any change in the SVG invalidates the binding. Plan SVG updates as joint SVG + VMC re-issuance.
• Non-square viewBox. Rectangular logos are cropped or rejected; the BIMI Group profile requires 1:1 aspect ratio.
• Transparent background. The logo must look correct against both light and dark inbox themes; a transparent background risks invisible-logo failures in dark mode. Use a solid fill on the root <rect> or in the first path.
• Forgetting the <title> element. The BIMI Tiny PS profile REQUIRES a <title> child of <svg> containing the company name — both for accessibility and as a validator check.
• Treating BIMI as authentication. BIMI is a brand-display layer on top of an already-authenticated message. It does not substitute for SPF / DKIM / DMARC; a BIMI logo on a non-DMARC-aligned message is impossible by design.

10. BIMI troubleshooting

Logo does not appear in Gmail / Apple Mail / Yahoo

Confirm DMARC is at p=quarantine or p=reject with pct=100 (BIMI ineligible at p=none). Confirm the specific message passed DMARC alignment via the message's Authentication-Results: header. Validate the SVG + VMC at BIMI Group's tools.

BIMI validator passes but Gmail still shows no logo

Gmail layers brand-reputation gating on top of BIMI's technical validation. Low-reputation domains may pass BIMI's protocol checks yet still not get the logo rendered. Check sender reputation via Google Postmaster Tools; unresolved spam complaints or recent bounces suppress the logo until reputation recovers.

SVG validation fails — "scripts not allowed"

The SVG contains a <script> element or an event-handler attribute (onload, onclick, etc.). These are categorically forbidden by SVG Tiny PS. Re-export through the BIMI converter or strip them manually.

SVG validation fails — "raster image embedded"

The SVG contains an <image> element referencing a PNG / JPEG. SVG Tiny PS forbids raster embedding. Recreate the logo as pure vector paths.

VMC validation fails — "SVG hash mismatch"

The SVG that the receiver fetched does not byte- match the SVG that was hashed into the VMC at issuance time. Most common cause: the SVG was re-optimised after the VMC was issued. Re-issue the VMC against the current SVG bytes.

VMC validation fails — "certificate expired"

The VMC's notAfter date has passed. VMCs are valid for ~1 year; arrange renewal with the CA. After renewal, replace the PEM at the a= URL.

DNS lookup returns SERVFAIL on default._bimi.<domain>

The authoritative DNS for the _bimi sub-zone is not responding. Confirm the TXT record is published and the authoritative servers for the domain are reachable. Verify with dig +short txt default._bimi.<domain>.

11. Frequently Asked Questions

What is BIMI?

BIMI (Brand Indicators for Message Identification) is an email specification that lets a domain publish a brand logo for receiving mailbox providers to display alongside authenticated messages in the inbox. BIMI is defined in the IETF Internet Draft draft-brand-indicators-for-message-identification and the BIMI Group profile documents. A BIMI record is a DNS TXT record at default._bimi.<domain> declaring the URL of an SVG Tiny PS logo and (optionally) the URL of a Verified Mark Certificate.

Does BIMI require DMARC?

Yes. BIMI requires the publishing domain to enforce DMARC at policy quarantine or reject — p=none is insufficient. The pct= tag must be 100. The intent is that the inbox logo signals an authenticated, brand-protected message, which only holds if DMARC is actually enforcing. Most mailbox providers (Gmail, Apple Mail, Yahoo) also require the message to pass DMARC alignment before BIMI logo display.

What does a BIMI DNS record look like?

A BIMI DNS record is a TXT record at default._bimi.<domain> containing tag=value pairs separated by semicolons. A typical record is: default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem" — declaring the BIMI version, the public URL of the SVG Tiny PS logo, and the URL of the Verified Mark Certificate.

What is SVG Tiny PS?

SVG Tiny PS (Portable/Secure) is a strict subset of SVG Tiny 1.2 defined for BIMI. It forbids scripts, animation, external references, raster image embedding, interactivity, and most filters. The root <svg> element must declare baseProfile="tiny-ps" and version="1.2". The image must be square (1:1 aspect ratio), under 32KB, and use a solid (non-transparent) background. The strict profile is what makes the logo safe to render inline in the inbox without security or performance risk.

What is a VMC and do I need one?

A VMC (Verified Mark Certificate) is an X.509 PKI certificate that cryptographically binds a registered trademark to the SVG logo and the publishing domain. VMCs are issued by approved Certificate Authorities — DigiCert and Entrust are the current production issuers — after the customer proves trademark ownership in one of the accepted jurisdictions (USPTO, EUIPO, UKIPO, JPO, IPA, CIPO). Gmail, Apple Mail, and Yahoo require a VMC before they will display the BIMI logo. Some providers (Fastmail historically) display the logo without a VMC, but the major-provider consensus has converged on requiring one.

Which mailbox providers support BIMI?

Gmail (Google Workspace + consumer), Apple Mail (iOS 16+ / macOS Ventura+), Yahoo Mail, AOL Mail, and Fastmail all display BIMI logos for authenticated mail. Outlook.com / Microsoft 365 announced BIMI support in 2023 but rollout has been gradual; check current Microsoft Learn documentation for the latest state. Provider support is enabled only when DMARC is enforcing and the BIMI record + SVG + VMC all validate.

Why is my BIMI logo not showing in the inbox?

The most common causes are: DMARC is at p=none (must be quarantine or reject), the message failed DMARC alignment for this specific send, the SVG is not strictly Tiny PS compliant (scripts, gradients-with-stops outside the profile, raster embeds, viewBox missing), the SVG is over 32KB, the VMC is missing or expired, or the logo URL is not served over HTTPS. A few mailbox providers also have brand reputation requirements layered on top of the technical validation.

12. Related guides

• DMARC explained — the policy + reporting standard that BIMI builds on top of. BIMI is ineligible without DMARC at p=quarantine or p=reject.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the BIMI-DISPLAY-ELIGIBILITY-IS-GATED-ON- TERMINAL-DMARC-POLICY-MODE-STATE companion to this BIMI protocol pillar. Where THIS page documents the BIMI byte-level protocol (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 version-prefix, the per-receiver-organisation brand-indicator rendering decision), the DMARC-policy-modes spoke documents the UPSTREAM three-state DMARC-enforcement policy ladder whose terminal-state choice at the publisher's apex DMARC TXT record is the LOAD-BEARING UPSTREAM PRECONDITION every receiver-side BIMI-eligibility evaluator THIS page documents gates the brand-indicator inbox-list rendering on. The PER-DMARC- POLICY-MODE-VS-BIMI-RENDERING cross-reference establishes FOUR structurally-distinct per- policy-mode-to-BIMI-rendering coupling dimensions: (i) p=none as canonical BIMI-INELIGIBLE policy-mode state at every BIMI-supporting receiver (Gmail / Yahoo / Apple Mail / Fastmail) — the BIMI specification (RFC draft-blank- ietf-bimi-12) + every BIMI-supporting receiver's published acceptance criteria REQUIRE the publisher to publish DMARC at p=quarantine or p=reject as the canonical author-domain enforcement posture; p=none publication is the DEFINITIONAL BIMI-INELIGIBILITY signal — the canonical receiver-side BIMI-rendering evaluator returns FALSE for every per-message BIMI-rendering decision under p=none; the DMARC-policy-modes spoke documents p=none as the Phase-1 OBSERVATION-ONLY policy-mode whose publication is INCOMPATIBLE with the BIMI- eligibility precondition THIS page documents; (ii) p=quarantine as MINIMUM-VIABLE BIMI-eligibility policy-mode state with the pct=100 coverage rate as the load-bearing per-percentage- coverage prerequisite — the BIMI- eligibility evaluator at each BIMI-supporting receiver accepts p=quarantine; pct=100 as the MINIMUM-VIABLE policy-mode state for per-message BIMI-rendering; publishers at p=quarantine; pct=10 (partial- coverage ramp posture) are DENIED BIMI- rendering because the per-message policy_evaluated/disposition=none outcome for 90% of non-aligned mail under pct=10 dilutes the receiver- side enforcement signal below the BIMI- eligibility floor; the DMARC-policy-modes spoke documents the pct=-tag per-percentage-coverage semantics whose terminal-pct=100 evaluation is the load-bearing BIMI-eligibility prerequisite; (iii) p=reject as CANONICAL TERMINAL-STATE BIMI-eligibility policy-mode state with the strongest per- receiver-organisation brand-trust signal — the BIMI-eligibility evaluator at each BIMI-supporting receiver returns the STRONGEST brand-trust signal for publishers at p=reject; pct=100 (the canonical terminal-state DMARC posture); the per-receiver BIMI-rendering decision at Gmail / Yahoo / Apple Mail / Fastmail prefers p=reject publishers over p=quarantine publishers when the brand-indicator cache eviction policy decisions consume per-publisher trust-score evidence; the DMARC-policy-modes spoke documents p=reject as the TERMINAL operationally-justified policy-mode state whose publication is the canonical BIMI-eligibility-maximising publisher posture; (iv) sp= subdomain-policy-mode tag-value as load- bearing per-subdomain-emitting-mail BIMI- eligibility coordination prerequisite — publishers using subdomains as transactional / marketing / per-vendor mail-emission streams MUST publish a per-subdomain DMARC posture (via the apex sp= tag default OR a per-subdomain explicit DMARC record at _dmarc.<subdomain>) at p=quarantine or p=reject for the per-subdomain mail-emission stream to inherit BIMI-eligibility from the apex BIMI TXT record publication; a publisher with p=reject at the apex but sp=none for subdomains DENIES BIMI-rendering for every subdomain-emitted message; the DMARC-policy-modes spoke documents the sp= subdomain- policy-mode coordination tag-value semantics whose per-subdomain enforcement posture is the load-bearing BIMI-eligibility coordination prerequisite. Read THIS BIMI pillar WITH the DMARC-policy-modes spoke when the per- publisher BIMI-rendering-eligibility audit step arrives: the BIMI pillar documents the PER-RECEIVER BRAND-INDICATOR RENDERING DECISION, the DMARC-policy-modes spoke documents the THREE-STATE AUTHOR-DOMAIN ENFORCEMENT-POLICY-MODE LADDER whose terminal- state choice at the publisher's apex DMARC TXT record is the upstream precondition every per-publisher BIMI-eligibility decision the receiver-side evaluator structurally depends on.
• DMARC reporting pipeline (RFC 7489 §7) — the END-TO-END-AGGREGATE-REPORT-PIPELINE- AS-BIMI-ELIGIBILITY-MONITORING-EVIDENCE- LAYER companion to this BIMI protocol pillar. Where THIS page documents the BIMI protocol at the byte level (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 / l=<SVG-URL> / a=<VMC-URL> tag grammar, the SVG Tiny PS profile, the 32KB / 800x800 logo constraints, the VMC vs CMC per-receiver eligibility matrix, the DMARC-at-enforce-plus-90-day-rolling-pass- rate ceiling) AND the per-receiver inbox- logo display behaviour, the DMARC-reporting- pipeline spoke is the OBSERVABILITY-LAYER REFERENCE documenting the seven-stage pipeline through which the 90-day-rolling- DMARC-pass-rate evidence surfaces in the operator-observable Stage 6 per-row analysis evidence stream. The BIMI- ELIGIBILITY-VS-AGGREGATE-REPORT-PIPELINE cross-reference establishes FOUR structurally-distinct per-pipeline-stage BIMI-eligibility-monitoring dimensions: (i) Stage 1 per-receiver per- message SPF+DKIM evaluation produces the per-message spf=pass / dkim=pass verdict that the BIMI-receiver-side display logic consumes AFTER the operator-side aggregate-report analysis confirms the 90-day rolling DMARC-pass-rate floor is sustained at the per-receiver-organisation eligibility threshold; the DMARC-reporting- pipeline spoke documents Stage 1's per- message verdict-emission contract AND the per-receiver-organisation receiver-side DMARC-evaluation algorithm whose successful completion is the load-bearing prerequisite for the receiver-side BIMI inbox-logo display this page documents; (ii) Stage 2-3 per-source-IP per- disposition row aggregation surfaces the per-source-IP DMARC-pass-rate evidence operators use to verify the 90-day rolling BIMI-eligibility floor is sustained per domain at the per-receiver-organisation boundary — the canonical BIMI- eligibility-monitoring discipline computes a rolling 90-day per-source-IP DMARC- pass-rate aggregation against the per- receiver-organisation XML rua-payload stream; the DMARC-reporting-pipeline spoke documents the Stage 2 per-source-IP aggregation algorithm receivers apply AND the Stage 3 XML rua-payload schema BIMI- eligible domain operators consume the per- source-IP DMARC-pass-rate attribution through (RFC 7489 §7.2.1.5 <row><policy_evaluated> <disposition> + <dkim> + <spf> elements); (iii) Stage 6 operator-side per-row analysis surfaces the BIMI-eligibility- floor-vs-deployed-pass-rate gap evidence the operator analyses to verify the domain is sustaining the 90-day rolling eligibility floor BEFORE submitting the BIMI v=BIMI1 TXT record — the canonical operator-side BIMI- deployment-prerequisite verification discipline runs a per-receiver- organisation per-source-IP per-disposition Stage 6 analysis cycle for 90 consecutive days against the aggregate-report stream BEFORE publishing the BIMI record AND for every subsequent rolling 90-day window the BIMI record remains published; the DMARC-reporting-pipeline spoke documents the Stage 6 operator-analysis discipline operators apply AND the per-receiver- organisation reputation-lookup cross- reference operators use to verify the BIMI-eligibility floor is sustained across the per-receiver-organisation set; (iv) Stage 7 per-operator BIMI-record publication-decision feedback closes the per-domain BIMI-eligibility-monitoring loop — the operator-side decision to publish (or retire) the v=BIMI1 TXT record at the default._bimi.<d-domain> owner-name becomes a per-receiver- organisation observability decision based on the aggregate-report Stage 6 evidence; the DMARC-reporting- pipeline spoke documents the Stage 7 operator-side decision-feedback channels AND the per-domain BIMI-record- publication-vs-aggregate-evidence coordination operators use to ensure the BIMI record this page documents remains published ONLY when the aggregate-report pipeline Stage 6 evidence confirms the per-receiver-organisation 90-day rolling DMARC-pass-rate floor remains sustained. Pair this page (the BIMI protocol pillar reference) with the DMARC-reporting- pipeline spoke (the end-to-end aggregate- report observability-layer reference) when designing the per-domain BIMI- deployment-and-monitoring runbook — the spoke documents the per-stage payload structure AND the per-source-IP aggregation algorithm receivers apply that surfaces the 90-day rolling DMARC-pass-rate evidence the BIMI-eligibility floor this page documents requires operators to sustain at the per-receiver-organisation boundary.
• Email security glossary — the BIMI-VMC-CMC-MARK-VERIFYING- AUTHORITY-SVG-TINY-PS-INBOX-LOGO- DISPLAY-VOCABULARY-CONSUMER companion to this BIMI pillar. Where THIS page documents the BIMI protocol at the byte level (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 / l=<SVG-URL> / a=<VMC-URL> tag grammar, the SVG Tiny PS profile, the 32KB / 800x800 logo constraints, the Verified Mark Certificate (VMC) vs Common Mark Certificate (CMC) per- receiver eligibility matrix, the DMARC at enforce + 90-day rolling pass-rate ceiling), the email-security-glossary spoke is the VOCABULARY-DEFINITION- REFERENCE companion documenting the canonical definitions for every BIMI- specific term-of-art this pillar uses in the body text without inline glossing — readers arriving from a Google search for "what is BIMI" or "what is a VMC" or "what is Mark Verifying Authority" or "what is SVG Tiny PS" need the glossary spoke to establish the BIMI vocabulary baseline before they can productively read THIS page's protocol-level deep dive. The BIMI- vs-glossary relationship is pillar-and-vocabulary-reference: THIS page is the canonical BIMI protocol pillar (BIMI specification draft-blank-ietf-bimi-04+ and adjacent WG drafts); the glossary spoke is the cross-cluster vocabulary hub the BIMI pillar shares with every other inbox-display / brand-trust / message-authentication / threat-catalogue / receiver-side pillar in the help cluster. Read the glossary spoke when the reader has not yet established the baseline vocabulary for BIMI-cluster terms — Verified Mark Certificate (VMC), Common Mark Certificate (CMC), Mark Verifying Authority (MVA), SVG Tiny PS profile, RFC 7042 P-mode constraints, TM (Trade Mark) registration, SM (Service Mark) registration, brand-trust signal, inbox-UI logo display, 90-day rolling DMARC pass rate — each defined in the glossary with the canonical BIMI-WG-draft anchor, the cross-pillar links to the BIMI certificates spoke (help_bimi_certificates.php) and the BIMI SVG requirements spoke (help_bimi_svg_requirements.php) and the per-platform BIMI deployment guides (help_bimi_for_google_workspace not yet shipped, help_bimi_for_ microsoft_365 not yet shipped), and the operator-side context for when each BIMI term-of-art appears in the operator's pre-BIMI-launch readiness audit, in the inbox-UI verification step that follows BIMI record publication, or in the BIMI logo-disappearance incident-response triage when an unexpected BIMI regression surfaces in the brand- trust analytics dashboard.
• DKIM explained — DomainKeys Identified Mail (RFC 6376): the cryptographic signature that, together with SPF, feeds DMARC alignment — the prerequisite for BIMI logo display.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) — the BIMI-LOGO-DISPLAY-AT-INBOX-UI-IS-DOWNSTREAM-CONSUMER-OF-PER-SELECTOR-DKIM-TXT-RECORD-BYTE-SYNTAX-CORRECTNESS companion documenting the per-tag byte-level grammar (v=DKIM1 / k=rsa / p=<base64> / s=email / h=sha256 / t=y|s) the BIMI display chain at Gmail / Yahoo / Apple Mail / Fastmail inbox UIs depends on when the BIMI Indicators check at the receiver-side BIMI evaluator (per the BIMI draft spec) consumes the per-message DKIM verdict and resolves it back to the publisher's per-selector TXT-record byte-content, across FOUR BIMI-downstream DKIM-byte-syntax consumer dimensions: (1) BIMI 90-day rolling DMARC-aligned pass-rate floor as downstream consumer of per-selector DKIM TXT-record byte-content correctness — BIMI display at the Gmail inbox UI gates on the publisher domain achieving ≥99% DMARC-aligned-pass rate across a 90-day rolling window; ANY per-selector DKIM TXT-record byte-syntax error (missing v=DKIM1 prefix, malformed p=-tag, truncated 255-byte chunk split that bisects base64 padding, missing k=-tag at non-default cryptosystem) reduces the achievable pass-rate floor below the BIMI display threshold; (2) BIMI evidence-document Verified Mark Certificate (VMC) issuance gates on per-selector DKIM-pass posture as certificate-issuance prerequisite — DigiCert / Entrust VMC issuance for BIMI requires the applicant to demonstrate a 90-day DMARC-pass-rate above the issuance floor; per-selector DKIM TXT-record byte-syntax stability is the load-bearing prerequisite for satisfying the VMC issuer's DMARC-history audit; (3) BIMI per-domain l=-tag URL publication parallel to DKIM p=<base64>-tag chunk-split byte-discipline — the BIMI default._bimi.<domain> TXT record carrying the SVG logo URL and VMC evidence URL faces the same RFC 1035 §3.3.14 per-string 255-byte limit that 2048-bit RSA DKIM p=-tags face; operators publishing both BIMI and DKIM records via the same DNS-provider UI MUST apply consistent chunk-split discipline; the DKIM byte-syntax guide is the authoritative reference for how the receiver-side resolver reassembles split TXT-records; (4) BIMI per-selector DKIM-rotation overlap-window correctness consumer of t=y-tag publication discipline — operators rotating DKIM keys quarterly produce a 24-72 hour overlap window where the old selector <sel-old>._domainkey.<domain> and new selector <sel-new>._domainkey.<domain> BOTH publish — BIMI's 90-day pass-rate accounting absorbs both selectors' pass-rate contributions; the per-selector t=y-tag byte-publication discipline at the new selector during the rotation window is the load-bearing correctness signal that prevents the rotation from puncturing the BIMI 99% pass-rate floor. Byte-syntax correctness across these four BIMI-downstream DKIM byte-syntax consumer dimensions is the load-bearing prerequisite for the BIMI logo-display chain at every BIMI-supporting mailbox-provider inbox UI documented on THIS pillar.
• DKIM for Google Workspace — the WORKSPACE-TENANT-DKIM-AS-BIMI- DISPLAY-PREREQUISITE companion documenting the canonical case where the BIMI logo display at Gmail's inbox UI (the receiver-side surface where BIMI logos actually MATERIALIZE for the largest consumer-email cohort) is GATED on the Workspace tenant's per-author-domain DKIM-signing infrastructure documented on the spoke. Documents FOUR Workspace- parallel BIMI-prerequisite dimensions (Workspace tenant's google._domainkey.<author-domain> TXT-record publication produces the DKIM signature whose per-message PASS-rate contribution feeds the 90-day rolling DMARC pass-rate floor BIMI display requires at the receiver-side Gmail evaluator — Workspace tenants whose google-selector DKIM publication has gaps see BIMI logo display LOSS in the Gmail inbox UI before any other receiver-side surface; Workspace's per- tenant 2048-bit DKIM key-size baseline meets the BIMI display prerequisite for cryptographic-strength signaling — a Workspace tenant publishing 1024-bit DKIM may technically pass DMARC but the downstream-receiver reputation models coupled with BIMI display eligibility prefer the 2048-bit baseline; Workspace's per-tenant DKIM-key-rotation cadence DIRECTLY governs the BIMI display stability post-deployment — if the Workspace operator initiates a key rotation that creates a transient gap in google-selector public-key publication, the per-message DKIM-fail rate spike drives the 90-day rolling DMARC-pass-rate floor below the BIMI display threshold and BIMI logo display in Gmail goes dark; Workspace tenants whose author-domain runs PARALLEL third-party signing (Mailchimp, SendGrid, Marketo) experience BIMI display stability as the JOINT product of Workspace's google-selector DKIM pass-rate AND every parallel third- party-signer's per-selector DKIM pass- rate — the BIMI display threshold evaluator at Gmail observes the per- author-domain JOINT pass-rate across all signing infrastructures). The Workspace spoke covers the Admin Console's DKIM-key-generation workflow, the per-tenant google-selector TXT- record publication procedure, the per- tenant 1024-vs-2048-bit key-size selection at generation time, and the per-tenant key-rotation overlap window coordination — all FOUR of which are the operational levers a Workspace operator pulls to keep their author- domain's BIMI logo display stable in the Gmail inbox UI.
• DMARC for Google Workspace — the WORKSPACE-TENANT-DMARC-PUBLICATION- DISCIPLINE-AS-PRECONDITION-FOR-BIMI- RENDERING companion to this BIMI pillar reference. Where THIS page documents the receiver-side BIMI publication-discipline (the per-publisher BIMI TXT record at default._bimi.<author-domain> declaring the l=<SVG-Tiny-PS-URL> and a=<VMC-URL> tag-values, the per-receiver BIMI brand-indicator rendering at Gmail / Yahoo / Apple Mail / Fastmail consumer-inbox-views, the receiver-side STRUCTURAL GATING on the per-message DMARC-aligned-pass verdict), the DMARC-for-Workspace spoke documents the per-tenant DMARC publication discipline at four Workspace-DMARC-to-BIMI-rendering coupling dimensions: (i) per- tenant DMARC p=quarantine or p=reject as load-bearing BIMI-eligibility precondition at the Gmail inbox UI — the per- receiver BIMI rendering gate THIS page documents requires the publisher's per- tenant DMARC policy to be at p=quarantine or p=reject with pct=100; the Workspace- tenant p=none monitoring phase produces NO BIMI rendering at the Gmail inbox UI regardless of the per-publisher BIMI TXT publication; (ii) per-tenant DMARC-aligned- pass rate baseline as Workspace BIMI rendering-rate-determinant — the per-tenant DMARC RUA-aggregate- report evidence stream the Workspace operator monitors during the rollout ramp from p=none → p=quarantine → p=reject partitions per- message per-receiver alignment outcomes into the pass-rate baseline that determines whether downstream Gmail BIMI rendering rate matches the per- tenant per-receiver legitimate-mail volume; (iii) per-tenant google._domainkey DKIM- aligned-pass as Workspace BIMI- rendering DKIM signature-input — the Workspace-tenant DKIM publication at google._domainkey.<tenant> (per the Workspace Admin Console DKIM signing toggle) produces per-message DKIM-Signature headers whose d=<tenant-domain> tag is the per-message-DKIM-aligned-pass input the Workspace-tenant DMARC verdict consumes; the receiver-side BIMI rendering gate THIS page documents depends on this Workspace DKIM-aligned- pass cascade producing the load-bearing per-message DMARC-aligned-pass verdict; (iv) per-tenant BIMI VMC certificate binding to Workspace-tenant author-domain — the X.509 VMC (Verified Mark Certificate) bound to the Workspace-tenant author-domain publishes the legal-entity-vetted brand identity Gmail honours at BIMI rendering; the per-tenant DMARC publication discipline THIS DMARC-for-Workspace spoke documents is the policy-layer contract that makes the Workspace BIMI VMC operationally meaningful at every per-receiver per-message rendering event. Read the DMARC-for-Workspace spoke alongside this BIMI pillar when the Workspace-tenant operator is designing the per-tenant rollout sequence whose Phase-3 BIMI publication depends on the per-tenant DMARC publication discipline the DMARC-for- Workspace spoke documents the operational reference for.
• DMARC for hybrid Exchange (on-premises + Exchange Online) — the HYBRID-EXCHANGE-DUAL-EGRESS-PATH- BIMI-VMC-RENDERING-PRECONDITION-CONSUMER companion to this BIMI pillar. Where THIS page documents the receiver-side BIMI-eligibility evaluator's load-bearing prerequisite (DMARC-pass-with-Friendly- From-header-alignment at p=quarantine or p=reject, rolling 90-day pass-rate floor, VMC chain validation against the published BIMI logo at default._bimi.<d-domain>) — i.e. the BIMI-VMC-DISPLAY-PRECONDITION side of the BIMI receiver-side rendering contract — the DMARC-for-hybrid-Exchange spoke is the HYBRID-EXCHANGE-DUAL-EGRESS- PATH-CONSUMER companion documenting how the precondition gets satisfied (or broken) across the TWO simultaneous outbound mail-flow boundaries a hybrid Exchange topology induces. Concretely, the spoke documents FOUR hybrid-Exchange- BIMI-precondition-coordination dimensions: (i) BIMI VMC rendering requires DMARC-pass-with-Friendly-From-alignment at BOTH egress paths independently — mail emitted from on-premises Exchange (signed by an on-prem DKIM transport agent under d=your-domain.com) and mail emitted from Exchange Online (signed by the cloud-side selector1 / selector2 CNAME-delegated keys under the same custom domain) must BOTH produce DMARC-pass verdicts with Friendly-From alignment — if EITHER path breaks alignment, BIMI VMC rendering fails for THAT path's mail at the receiver-side Outlook / Gmail inbox UI, fragmenting brand-logo display along the hybrid egress fault line; (ii) the dual-signer DKIM-alignment-ambiguity failure mode is a primary BIMI-rendering-loss cause in hybrid Exchange — when BOTH on-prem and cloud sign a single outbound message under DIFFERENT d= domains (on-prem under d=your-domain.com, cloud under d=<tenant>.onmicrosoft.com), only one signature will align with the Friendly-From-header organisational domain, and receiver-side BIMI evaluators observing non-deterministic per-receiver-implementation alignment outcomes treat the alignment posture as UNSTABLE — depressing the 90-day rolling DMARC pass rate below the BIMI display eligibility threshold THIS page documents; (iii) Default Frontend Connector DKIM-strip is a BIMI-rendering-loss induction mechanism specific to hybrid Exchange — when the Exchange Online Default Frontend Connector strips the on-prem DKIM signature from relayed mail (the canonical hybrid misconfiguration the spoke documents), the cloud re-signs under <tenant>.onmicrosoft.com and the visible Friendly-From-domain's carefully-crafted on-prem DKIM signature is lost — every hybrid- relayed message arriving at gmail.com / outlook.com loses BIMI VMC rendering because the published BIMI VMC at default._bimi.your-domain.com no longer has an aligning DKIM signature from any d= domain; and (iv) ARC sealing in hybrid Exchange preserves BIMI precondition across the on-prem-to-cloud relay hop — when the operator deploys ARC seals (ARC-Seal + ARC-Message-Signature + ARC-Authentication-Results) at the on-prem signing side AND registers the on-prem signing domain as a Trusted ARC Sealer in Defender for Office 365, the receiver-side BIMI evaluator can reconstruct the ORIGINAL DKIM-pass + DMARC-aligned verdict across the on-prem-to-cloud relay hop even when the intermediate relay invalidates the original DKIM signature — preserving the BIMI VMC rendering eligibility for hybrid- relayed mail that would otherwise lose alignment. Read the DMARC-for- hybrid-Exchange spoke alongside this BIMI pillar when planning BIMI VMC deployment for a hybrid Exchange portfolio: the receiver-side BIMI- eligibility precondition THIS page documents must be satisfied at BOTH egress paths (in classic-hybrid) or consolidated to the cloud egress boundary (via CMT) — and the dual- signer / DKIM-strip / ARC-sealing operational levers the spoke documents are the load-bearing controls determining whether BIMI VMC rendering stays consistent across all hybrid-emitted mail at the receiver- side Outlook / Gmail inbox UI.
• DKIM best practices — the cryptographic-hygiene discipline that determines whether BIMI logo display stays stable post-deployment — the operator-facing best-practices reference for the DKIM deployment-and-maintenance discipline BIMI logo display structurally depends on. Where the DKIM pillar above is the PROTOCOL primer, the DKIM best-practices spoke is the STANDING-DISCIPLINE reference that determines whether your BIMI logo display stays stable across the years following BIMI deployment. BIMI is uniquely sensitive to DKIM regression because: (i) BIMI requires DMARC at enforce (p=quarantine or p=reject) — a single botched DKIM key-rotation can drop the DMARC-pass rate enough that receivers temporarily downgrade BIMI display, (ii) Gmail's BIMI eligibility additionally requires a 90-day rolling DMARC-pass-rate above a heuristic ceiling — making DKIM-pass regression a BIMI-logo-disappearance vector even if DMARC enforcement remains nominally compliant, (iii) the 2024 Gmail / Yahoo RSA-1024 deprecation forced every BIMI-eligible operator into a RSA-1024-to-RSA-2048-or-ED25519 key-rotation cadence at minimum, (iv) BIMI's a=<VMC-URL> Verified Mark Certificate dependency means the cost-of-failure is substantially higher than for plain-DMARC operators (an unexplained BIMI-logo disappearance triggers brand-protection escalations even when the underlying issue is a single SaaS-sender DKIM regression). The best-practices spoke documents the canonical 2048-bit RSA minimum, the ED25519 / RSA dual-algorithm publication strategy, the 6-month selector-rotation cadence with overlap-window dual-signing (essential for BIMI operators — never DELETE a selector before retiring it from active signing), the explicit l=-tag avoidance, the relaxed/relaxed canonicalization choice, the per-provider key-inventory discipline, and the DKIM-private-key-breach response protocol that an enforce-DMARC + BIMI-eligible operator MUST have rehearsed before the incident happens.
• DKIM selectors explained — the SELECTOR-PUBLICATION-DISCIPLINE- AS-BIMI-DISPLAY-STABILITY-PREREQUISITE companion to this BIMI pillar. Where THIS page documents the receiver-side BIMI evaluation gate (DMARC at p=quarantine or p=reject + 90-day rolling DMARC-pass-rate floor + VMC/CMC verification + SVG Tiny PS asset compliance), the DKIM-selectors- explained spoke documents FOUR publisher-side selector-publication- discipline dimensions whose correctness directly determines whether the BIMI-eligible 90-day DMARC-pass-rate floor stays observable at the receiver-side evaluator: (i) the per-key selector publication at the owner- name layer — every signed message's DKIM-Signature carries an s=<selector> tag, and the receiver resolves the public key at <selector>._domainkey.<d-tag-domain> — selector-publication defects (missing record, wrong owner-name, byte-corrupted base64, chunk-concatenation breakage on keys >255 octets) produce dkim=fail rows in receiver-side evidence which directly drag the 90-day rolling DMARC-pass- rate below the BIMI threshold, suppressing logo display until the regressing mail-stream rebuilds its pass-rate window; (ii) the per-mail-stream dedicated selector inventory — operators with multiple sending infrastructures publish a dedicated selector per stream (in-house MTA, Workspace, M365, SendGrid, Mailchimp, etc.) — but the BIMI 90-day rolling pass-rate is computed PER-DOMAIN, so ANY single per-stream selector regression drags the cross-stream domain-level pass-rate below the BIMI threshold, making the per-stream selector inventory load-bearing for cross- stream BIMI eligibility; (iii) the dual-selector rotation overlap window discipline — the rotation pattern requires publishing the new selector + waiting for DNS TTL + maximum receiver-cache- age propagation BEFORE old-selector revocation — a premature revocation during the rotation window produces a per-mail-stream dkim=fail spike whose 90-day rolling impact suppresses BIMI logo display for weeks even after the rotation completes, and (iv) the selector-rotation- cadence vs BIMI-rolling-window composition — operators rotating selectors quarterly (best- practice cadence) must coordinate the rotation overlap windows carefully so that the receiver-side DKIM=pass rate across ALL receivers is preserved through the rotation — a misexecuted rotation triggers a multi-week BIMI-display-suppression episode the operator must wait out for the 90-day rolling window to rebuild. Pair this BIMI pillar (the receiver-side eligibility gate) with the DKIM-selectors-explained spoke (the publisher-side selector- publication-discipline reference) when designing the BIMI-eligible per-mail-stream selector inventory and the per-selector rotation cadence that keeps BIMI logo display stable across the years following BIMI deployment.
• DKIM replay attacks — the BIMI-INDICATOR-VISIBILITY-AT- DKIM-REPLAYED-MESSAGE-DELIVERY-EVENT- AS-VISUAL-TRUST-WEAPONIZATION-SURFACE companion reference. Where THIS page documents the BIMI brand-indicator protocol (the default._bimi.<domain> TXT record, the l=-tag SVG-Tiny-PS logo URL, the a=-tag VMC certificate URL, the receiver-side BIMI-logo display gate on DMARC-pass + identifier-alignment), the DKIM- replay-attacks spoke documents the RFC 6376 §6.2.2 signature-replay attack class in which a single legitimately-signed (and thus DMARC- passing) message is captured and re- injected to many additional receivers under the ORIGINAL DKIM-Signature header. The BIMI-VISUAL-TRUST WEAPONIZATION concern is that the receiver-side BIMI display logic documented on THIS page (Gmail's BIMI logo rendering, Apple Mail's BIMI brand indicator, Yahoo's BIMI logo display, Microsoft's BIMI-prepared display path) fires on EVERY DMARC-passing message that meets identifier-alignment criteria — INCLUDING the DKIM-replayed instances whose DMARC verdict is pass by virtue of the original DKIM-Signature header being preserved byte-identically. The replay attacker who harvests a single legitimately-signed message from a BIMI-eligible sender therefore weaponizes the brand-trust signal the BIMI logo delivers: every replayed message carries the brand-logo display in the receiver inbox alongside any attacker-controlled MAIL FROM / envelope manipulation that does not invalidate the signed From: header field. Brands that deploy BIMI at enforce-DMARC therefore face a UNIQUELY ELEVATED replay-attack- risk profile relative to plain- DMARC senders: the cost-of-replay for the attacker is BIMI-logo bearing message delivery (visual- trust amplification), and the defender-side mitigation surface is the RFC 6376 §3.5 x= expiration tag, the l=-tag-as-replay- extension-vector, the per- selector retire-and-rotate cadence, and the receiver-side DKIM-Signature replay-detection the DKIM-replay-attacks spoke documents. Read this BEFORE publishing BIMI on a high-trust brand domain — the attack surface for replay-amplified visual-trust weaponization is BIMI-specific and the defender-side mitigation discipline (short x= expiry, dual- selector rotation, body-hash uniqueness tracking) must be in place before the BIMI logo appears on a receiver-side rendering surface.
• DKIM alignment with DMARC — the alignment half that determines whether BIMI-eligible DMARC enforce stays at the 99% pass-rate floor — the DKIM-ALIGNMENT EVALUATION reference that determines whether BIMI-eligible DMARC enforce stays at the 99%-plus pass-rate floor BIMI display depends on. Where the DKIM-pillar introduces the protocol and the best-practices spoke above documents the standing-discipline crypto hygiene (RSA-2048, ED25519, selector rotation), the DKIM-alignment-with-DMARC spoke is the receiver-side identifier-alignment decision-tree reference: the DKIM-Signature d=-tag extraction, the From: organizational- domain extraction, the adkim=r relaxed vs adkim=s strict policy knob, and the THREE CANONICAL DKIM-pass-but-DMARC-fail provenance patterns BIMI operators encounter most often: (i) the M365 onmicrosoft.com gotcha — a BIMI-eligible domain on Microsoft 365 ships with d=<tenant>.onmicrosoft.com signing by default; until customer- domain DKIM is provisioned in Defender's DKIM blade, every BIMI-eligible outbound message ships DKIM-aligned-to-microsoft- not-customer — typically silently dropping the 90-day rolling DMARC-pass rate below the BIMI eligibility ceiling and triggering an unexplained BIMI logo disappearance, (ii) the Google Workspace gappssmtp.com gotcha — the Workspace equivalent of the same provider-default-domain alignment trap, (iii) the ESP shared-domain signing pattern (SendGrid / Mailchimp / Postmark / Mandrill / Amazon SES) — BIMI operators using ESPs for marketing mail blast their BIMI-eligible apex From: with ESP-signed-not-apex-signed messages unless CNAME-delegated authenticated-domain DKIM is provisioned per-ESP. Each of the three patterns is a SILENT BIMI-logo-disappearance vector operators only diagnose by inspecting the aggregate-report auth_results/dkim/domain verbatim and mapping the observed d=-tag back to the signing infrastructure. Pair this BIMI pillar (which documents the BIMI logo-display DMARC-pass-rate prerequisite at the protocol level) with the DKIM-alignment spoke (which documents the SPECIFIC ALIGNMENT-FAILURE PATTERNS that drop the DMARC-pass rate below the BIMI eligibility floor) when a BIMI logo disappears unexpectedly — the alignment- spoke is the operator's first stop for identifying which of the three canonical gotchas is biting.
• SPF explained — Sender Policy Framework (RFC 7208): the envelope-sender authorisation mechanism that complements DKIM. Together SPF + DKIM produce the DMARC verdict BIMI piggybacks on.
• Why SPF alone is insufficient — the BIMI-LOGO-DISPLAY-REQUIRES-DMARC- PASS-NOT-JUST-SPF-PASS-AS-FOUNDATIONAL- WHY-DMARC-EXISTS-RATIONALE companion to this BIMI protocol pillar. Where THIS page documents the BIMI receiver-side eligibility evaluation (DMARC-aligned- and-DMARC-enforcement-passing precondition per AuthIndicators-Working-Group spec + BIMI assertion record + optional VMC verified-mark-certificate gating the verified-mark display in major mailbox clients), the why-SPF-alone-is- insufficient spoke is the FOUNDATIONAL why-DMARC-exists reference whose 4-class SPF-insufficiency catalogue explains WHY the BIMI eligibility floor STRUCTURALLY cannot rely on SPF alone — BIMI must require the DMARC-pass verdict (which requires SPF-OR-DKIM alignment to the RFC5322.From domain) as the eligibility gate that closes the SPF-only-pass-but- DMARC-fail impersonation attack class. The BIMI-LOGO-DISPLAY-REQUIRES-DMARC- PASS-NOT-JUST-SPF-PASS-AS-FOUNDATIONAL- WHY-DMARC-EXISTS-RATIONALE cross- reference establishes FOUR structurally- distinct BIMI-eligibility-floor-depends- on-DMARC-complement dimensions: (i) SPF-pass-without-alignment- FAILS-DMARC-and-FAILS-BIMI-eligibility dimension — SPF authentication per RFC 7208 produces a pass verdict against the RFC5321.MailFrom envelope domain, but BIMI eligibility per the AuthIndicators-Working-Group spec requires DMARC pass (per RFC 7489 §3.1.2 alignment requirement); if SPF passes for an attacker-controlled envelope domain (attacker.example) but the RFC5322.From header presents the victim brand domain, DMARC FAILS (alignment failure) and BIMI logo display is correctly suppressed — but SPF ALONE would have allowed delivery; the why-SPF-alone-is-insufficient spoke documents WHY the BIMI eligibility floor must require DMARC-alignment, not just SPF-pass; (ii) SPF-fail- through-forwarder-but-DKIM-pass-still- achieves-BIMI-eligibility dimension — when legitimate brand mail traverses forwarders, SPF FAILS at the receiver-side (envelope rewrite breaks the SPF chain), but DKIM cryptographic signatures SURVIVE the forwarder (assuming forwarders don't modify signed headers/body); DMARC's SPF-OR-DKIM alignment per RFC 7489 §3.1 allows the DKIM leg to satisfy DMARC alignment when the SPF leg fails — and BIMI logo display correctly proceeds because DMARC passes; the why-SPF-alone-is-insufficient spoke documents WHY the BIMI eligibility floor's DMARC-pass requirement is structurally MORE forgiving of legitimate forwarded mail than an SPF-only floor would be — and structurally MORE strict against attacker- controlled-envelope spoofing than an SPF-only floor would be; (iii) BIMI-eligibility-floor-requires-p-equals- quarantine-or-reject-NOT-p-equals-none dimension — BIMI eligibility per the AuthIndicators-Working-Group spec requires DMARC p=quarantine or p=reject enforcement ( p=none monitoring-only is NOT BIMI-eligible); SPF alone has NO equivalent enforcement-policy concept — the SPF qualifier (-all / ~all / ?all / +all) influences receiver- side reputation heuristics but NOT a normative-enforcement-mode contract; the why-SPF-alone-is-insufficient spoke documents WHY the BIMI eligibility floor's enforcement-policy requirement is structurally a DMARC-only capability SPF alone cannot provide; (iv) BIMI-VMC-public-PKI-mark- certificate-anti-lookalike-defense- depends-on-DMARC-not-SPF dimension — BIMI VMC verified-mark- certificate per the AuthIndicators- Working-Group spec requires the publisher to demonstrate trademark-or- equivalent-mark ownership via a public- PKI X.509 verified-mark certificate (Entrust / DigiCert today); lookalike- domain attackers (g00gle.com / microsoftupdates.com) CANNOT obtain a VMC for the victim's trademark, structurally closing the lookalike-domain spoofing attack class that SPF alone provides NO defense against (the lookalike-domain attacker publishes a valid SPF record for their OWN lookalike domain); the why-SPF- alone-is-insufficient spoke documents WHY the BIMI VMC + DMARC-enforcement composite anti-lookalike defense is structurally beyond SPF's protocol- layer capability. Pair this page (the BIMI logo-display + VMC + eligibility- evaluation protocol pillar) with the why-SPF-alone-is-insufficient spoke (the foundational why-DMARC-exists reference) when an operator authors the brand- impersonation-defense rollout plan and needs to apply the same four-class BIMI-eligibility-floor-depends-on-DMARC- complement discipline as the structural rationale for WHY BIMI's enforcement- floor requires the DMARC-aligned + DMARC- enforcement complement that SPF alone cannot provide.
• SPF mechanisms explained — the BIMI-LOGO-DISPLAY-AS-DOWNSTREAM- CONSUMER-OF-SPF-MECHANISM-EVALUATION- PASS-RATE companion to this BIMI protocol pillar. Where THIS page documents the BIMI protocol at the byte level (the default._bimi TXT record, the v=BIMI1 / l= SVG URL / a= VMC URL tag grammar, the SVG Tiny PS profile and 32KB / 800x800 logo constraints, the Verified Mark Certificate (VMC) vs Common Mark Certificate (CMC) per-receiver eligibility matrix, the DMARC at enforce + 90-day rolling DMARC-pass-rate eligibility floor), the SPF-mechanisms spoke documents the SEVEN STRUCTURALLY- DIFFERENT SPF mechanism tokens (RFC 7208 §5 — all, include:, a:, mx:, ptr:, exists:, and the IP-literal ip4: / ip6:) whose per-message-evaluation spf=pass-rate is the load-bearing UPSTREAM INPUT to the 90-day rolling DMARC-pass-rate floor the BIMI receiver-side evaluator (Gmail Yahoo Apple Mail Fastmail) gates logo- display on. The two protocol layers chain: at the receiver, the SPF- mechanism-evaluation FIRST produces the spf= verdict by checking the connecting client IP against the SPF-record's mechanism sequence — then the DMARC engine's aspf=-alignment-mode evaluator computes the DMARC SPF-aligned verdict — then the receiver's BIMI evaluator aggregates the 90-day rolling DMARC-pass-rate across all receiver-observed messages from the publishing domain to determine whether the BIMI logo this pillar documents renders at inbox-list time. Critically: an operator publishing a BIMI logo MUST ensure the upstream SPF-mechanism- evaluation pass-rate is high enough to sustain the DMARC-pass-rate above the BIMI-eligibility floor — the most common BIMI-deployment failure mode is NOT a malformed BIMI record nor a non-compliant SVG Tiny PS logo, but instead a sub-floor DMARC-pass-rate driven by SPF-mechanism authoring errors (an include:-mechanism recursive-lookup budget breach producing spf=permerror rows, a deprecated ptr:-mechanism producing spf=permerror rows, a missing ip4: / include: entry for a SaaS-sender producing spf=fail rows). Read the SPF-mechanisms spoke alongside this BIMI pillar when scoping the upstream authentication posture a BIMI logo publication depends on — the SPF mechanism vocabulary documented in the spoke is the AUTHORING-TIME LEVER the operator pulls to maintain the DMARC-pass-rate floor the BIMI receiver-side evaluator gates logo- display on.
• Email deliverability fundamentals — the BRAND-TRUST-DOWNSTREAM-DELIVERABILITY-SIGNAL business-outcome companion to this BIMI protocol pillar. Where THIS pillar documents the BIMI protocol at the byte level (the default._bimi TXT record, the v=BIMI1 / l= SVG URL / a= VMC URL tag grammar, the SVG Tiny PS profile and 32KB / 800x800 logo constraints, the Verified Mark Certificate (VMC) vs Common Mark Certificate (CMC) per-receiver eligibility matrix, the DMARC at enforce + 90-day rolling pass-rate eligibility floor), the email-deliverability page documents the BUSINESS-OUTCOME framework in which BIMI operates: BIMI logo display is NOT an INPUT to deliverability — BIMI is a DOWNSTREAM SIGNAL of an already-healthy deliverability posture (DMARC at enforce + 90-day rolling DMARC-pass-rate above the BIMI-eligibility floor + sender-reputation healthy enough for the receiver to render the logo at inbox-list time). The deliverability page documents the FULL CAUSAL CHAIN (sender-reputation → IP/domain reputation computation → authentication verdict → DMARC pass + alignment → engagement signals → inbox-folder placement) BIMI logo display sits at the BUSINESS-OUTCOME END of, and the BIMI-deliverability MYTH this pillar refutes IN PASSING (that BIMI directly improves deliverability) — both the myth-refutation FRAMING and the deliverability funnel that explains WHY the relationship is BIMI-as-SIGNAL not BIMI-as-INPUT. Read the deliverability page when triaging a BIMI-eligibility failure rooted in sender-reputation rather than the BIMI-tag or VMC eligibility — the deliverability page is the canonical operator-reference for the sender-reputation computation BIMI eligibility depends on at every receiver.
• DMARC for transactional email — the BIMI-LOGO-DISPLAY-AT-INBOX-LIST-IS- PRIMARY-SURFACE-FOR-TRANSACTIONAL-STREAM- BRAND-RECOGNITION companion to this BIMI protocol pillar. Where THIS pillar documents the BIMI protocol at the byte level (the default._bimi TXT record, the v=BIMI1 / l= SVG URL / a= VMC URL tag grammar, the SVG Tiny PS profile and 32KB / 800×800 logo constraints, the Verified Mark Certificate eligibility matrix, the DMARC at enforce + 90-day rolling DMARC-pass-rate eligibility floor), the transactional-email spoke is the per- message-type deployment companion documenting FOUR transactional-email- BIMI-rendering-value dimensions: (i) order confirmation and receipt inbox-list arrival → BIMI logo display immediately reinforces brand identity AT THE EXACT MOMENT recipients scan their inbox for the just-triggered purchase transaction confirmation — the transactional-email spoke documents WHY transactional streams are the primary BIMI rendering value surface: recipients ACTIVELY EXPECT the confirmation message (they just clicked Buy Now), the BIMI logo at inbox-list arrival visually CONFIRMS the message originated from the legitimate brand BEFORE the recipient clicks into the message, and the seconds-to-minutes inbox-arrival latency between purchase-completion and confirmation-email-delivery is the canonical brand-trust reinforcement moment BIMI logo display is engineered for; (ii) password-reset and account-verification link inbox-list arrival → BIMI logo display ATTESTS TO LEGITIMATE ORIGIN at the exact moment recipients are most vulnerable to phishing impersonation — the transactional spoke documents the canonical phishing-defense pattern where attackers send LOOKALIKE password-reset emails IMMEDIATELY AFTER the recipient triggers the legitimate reset (timing correlation attack); the BIMI logo at inbox-list time visually DISTINGUISHES the legitimate brand-signed message from the attacker's BIMI-unsigned lookalike BEFORE the recipient inspects message contents, gating the credential-capture attack at the visual-trust layer; (iii) two-factor code and OTP delivery → BIMI logo display ATTESTS TO LEGITIMATE ORIGIN at the exact moment recipients are most likely to approve a financial transaction or grant account access — the transactional spoke documents the highest-financial-impact BIMI rendering value scenario where the OTP message arrives at the inbox during a narrow 30-second-to-5-minute validity window, the recipient is in an active financial-decision state (about to approve a wire transfer, about to authorise a payment), and the BIMI logo at inbox-list time provides the per-message visual legitimate-origin signal that differentiates the legitimate bank-issued OTP from the canonical attacker-injected lookalike OTP; (iv) transactional-stream 99%- DMARC-pass-rate-floor BIMI-eligibility is the EASIEST-TO-ACHIEVE rolling-90- day baseline of any operationally- distinct stream type because the transactional stream typically flows from a SINGLE ESP with a SINGLE DKIM selector signing posture — the transactional spoke documents the operationally-significant per- stream subdomain pattern (publish transactional stream on a DEDICATED subdomain that has its own DMARC record at p=reject) so the transactional-subdomain BIMI- eligibility evaluation runs on the 99%-DMARC-pass-rate floor the transactional stream achieves INDEPENDENTLY of the marketing / corporate / SaaS-relay streams whose heterogeneous signing posture would otherwise drag the apex-domain DMARC-pass-rate below the BIMI- eligibility floor. Read the transactional-email spoke when deploying BIMI on a domain whose dominant inbox-arrival stream is transactional (e-commerce, SaaS account lifecycle, bank transaction alerts, healthcare appointment reminders, fintech KYC progress updates) — the spoke is the authoritative per-message-type operational reference for the BIMI- rendering-value-meets-transactional- deployment-discipline cross-cluster boundary.
• DMARC myths and misconceptions — the cluster-spanning catalogue this BIMI pillar refutes the BIMI-specific myths from — the CLUSTER-SPANNING MYTHS CATALOGUE the BIMI-specific myths this pillar refutes IN PASSING are catalogued in. Where THIS pillar documents the BIMI protocol at the byte level (the default._bimi TXT record, the v=BIMI1 / l= SVG URL / a= VMC URL tag grammar, the SVG Tiny PS profile and 32KB / 800x800 logo constraints, the Verified Mark Certificate (VMC) vs Common Mark Certificate (CMC) per-receiver eligibility matrix, the DMARC at enforce + 90-day rolling pass-rate ceiling), the myths-catalogue spoke is the OPERATIONAL CROSS-PROTOCOL TAXONOMY of the full myth family the BIMI- specific myths this page refutes belong to: the BIMI-protocol myths (BIMI requires VMC at every receiver — false, Gmail accepts CMC; BIMI improves deliverability directly — false, BIMI is a downstream SIGNAL of deliverability not an INPUT; BIMI works without DMARC at enforce — false, the BIMI eligibility prerequisite is structural; BIMI VMCs verify the brand owner — false, VMCs verify only that a trademark registration exists for the mark; BIMI logo display is binary — false, the per-receiver eligibility matrix and 90-day rolling pass-rate compute receiver-by-receiver), catalogued ALONGSIDE the adjacent myth families: the DMARC-protocol myths (DMARC blocks all phishing, p=none is safe forever), the SPF myths (SPF stops spoofing, ~all is safer than -all), the DKIM myths (DKIM proves end-to-end integrity, single-selector deployment is sufficient), the transport-security myths (TLS encryption stops phishing, MTA-STS replaces DANE), and the threat-model myths (display-name spoofing is cosmetic, look-alike-domains need DMARC). Read the myths-catalogue spoke when stakeholders arrive with BIMI- specific misconceptions ("BIMI will lift our open rate by 30%", "we don't need DMARC enforce for BIMI", "VMC is optional for Gmail", "BIMI logo display proves brand authenticity to end users") — the catalogue is the cluster-spanning navigation reference for the broader misconception taxonomy this BIMI pillar intentionally only refutes pillar- adjacent fragments of.
• Email spoofing explained — the BIMI-VISUAL-LOGO-COUNTERS-SPOOFING- VISUAL-CONFUSION parent-threat-class reference documenting the seven canonical email-spoofing techniques whose visual- confusion-at-the-inbox-layer is the EXACT defender target the visual-brand- verification primitive this BIMI pillar documents is engineered to address. Where THIS pillar documents the BIMI protocol at the byte level (default._bimi.<domain> IN TXT "v=BIMI1; l=…svg; a=…vmc.pem" record, the SVG Tiny PS profile, the VMC / CMC certificate chain-of-trust), the email-spoofing pillar is the PARENT-CLASS DEEP DIVE documenting the SEVEN spoofing-technique taxonomy BIMI's last-mile UI layer is engineered to defeat at the user-perception layer, plus the sharp distinction between the spoofing classes BIMI ACTUALLY defeats and those BIMI does NOT — critical because operators deploying BIMI routinely over-estimate its anti-spoofing reach. The four-axis BIMI-VS-SPOOFING comparison exposes the structurally-distinct BIMI-DEFEATS-VS-BIMI-DOES-NOT-DEFEAT roles: (i) BIMI DEFEATS — Direct domain spoofing (RFC 5322 From: forgery) at p=reject — the attacker forges the From: header outright; DMARC at p=reject blocks the message at the alignment check; receivers therefore never see the spoofed mail at all, so BIMI's contribution is the SUPPORTING role of making DMARC enforcement palatable to operators (the BIMI-enabled anchored-brand-trust signal motivates the 90-day rolling p=reject deployment); (ii) BIMI DEFEATS — Display-name spoofing — the attacker injects "Acme Bank Billing" <billing@unrelated.example> to exploit the From-header structure where alignment evaluates the ADDRESS domain not the DISPLAY-NAME phrase; DMARC alignment passes for the attacker's chosen unrelated From: domain, BUT the BIMI lookup at default._bimi.unrelated.example returns NXDOMAIN (the attacker doesn't control that DNS zone) so the inbox shows NO LOGO next to the spoofed mail while showing the LOGO next to legitimate Acme Bank mail — visual disambiguation at the inbox-UI layer; (iii) BIMI DOES NOT defeat — Lookalike-domain registration + IDN homograph + cousin- domain — the attacker authors valid DMARC + DKIM + SPF + BIMI for acmebank.co or acme‐bank.com Unicode- hyphen and publishes their own VMC / CMC; the lookalike's BIMI logo displays next to the spoofed message — same visual brand-experience as the legitimate domain; BIMI's anti-spoofing scope is narrow enough that operators MUST add third-party brand-monitoring services (Domain-Tools, Whoxy, BrandShield) to catch lookalike-domain registrations BEFORE the attacker publishes their own BIMI; (iv) BIMI DOES NOT defeat — DKIM-replay-from-cooperating- spammer — the attacker replays a legitimately-signed message body to attacker-chosen recipients; the DKIM-d=-aligned-with-DMARC posture passes, the BIMI logo lookup at the legitimate domain returns the legitimate VMC, and the replayed message displays the brand logo normally; receivers have no BIMI-side signal that anything is wrong — operators MUST cross-reference the DKIM-replay-attacks deep dive and the spoofing pillar's defense-in-depth section to scope this residual exposure. Read THIS BIMI pillar WITH the email-spoofing pillar when scoping BIMI's anti-spoofing contribution: the answer is NARROW — BIMI defeats direct domain spoofing (by supporting p=reject) and display-name spoofing (by withholding the logo from spoofed unrelated- domain mail), but BIMI does NOT defeat lookalike-domain spoofing or DKIM-replay spoofing — the spoofing pillar documents the full seven-technique taxonomy and the six defender countermeasures the broader defense-in-depth stack must combine with BIMI to close the residual spoofing surface area.
• DMARC multi-domain strategy — the PER-BRAND-BIMI-LOGO-PUBLICATION- REQUIRES-PER-DOMAIN-DMARC-ENFORCEMENT companion documenting the structurally- distinct portfolio-level BIMI deployment challenge that emerges when a single org runs multiple brand domains under a single organisational umbrella (primary brand, secondary brands, acquired-company brands, sub-brand SaaS / mobile-app domains) and EACH brand domain that wants BIMI logo display must independently advance its OWN DMARC posture to p=quarantine or p=reject AND procure its OWN Verified Mark Certificate (VMC) / Common Mark Certificate (CMC) tied to its OWN registered trademark. Where THIS pillar documents the BIMI protocol for a SINGLE domain (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 / l= SVG URL / a= VMC URL tags, the SVG Tiny PS profile, the 32KB / 800x800 logo constraints, the DMARC at enforce + 90-day rolling pass-rate ceiling), the multi-domain-strategy spoke is the PORTFOLIO-LEVEL-BIMI-ROLLOUT-SEQUENCING companion documenting the org-wide brand-BIMI deployment posture across N portfolio brands: (i) PER-BRAND-DMARC-ENFORCEMENT-READINESS sequencing (each portfolio brand independently progresses through the p=none → monitoring → p=quarantine pct=10 → … → p=quarantine → p=reject rollout phases; the multi-domain-strategy spoke documents the per-brand sequencing whereby NOT EVERY portfolio brand reaches BIMI-eligibility on the same timeline — the primary brand typically leads, secondary brands follow as the per-brand source-inventory and the per-brand pct=100 rollout completes, and parked / legacy-acquisition brands may never become BIMI-eligible at all), (ii) PER-BRAND-VMC-PROCUREMENT sequencing (each BIMI-eligible portfolio brand requires its OWN VMC tied to its OWN registered trademark mark; the multi-brand operator must coordinate per-brand VMC procurement with the trademark portfolio's per-brand registration cadence, where some brands may have full international registrations already in place while others — typically newly-acquired sub-brand domains — may not yet have the registered-mark prerequisite the Mark Verifying Authority requires), (iii) PER-BRAND-LOGO-DESIGN-AND-SVG- PRODUCTION sequencing (each portfolio brand needs its OWN SVG Tiny PS logo file conforming to the 32KB / 800x800 BIMI logo constraints; the multi-domain-strategy spoke documents the per-brand brand-asset-team coordination cadence required to ship compliant SVG-Tiny-PS assets for every BIMI-eligible portfolio sibling without per-brand re-mastering at each receiver-side rendering edge case), (iv) PARKED-DOMAIN-NULL-BIMI portfolio- default posture (the canonical portfolio-non-sending sibling SHOULD NOT publish a BIMI record at all — the default._bimi.parked-domain.example NXDOMAIN response is the desired outcome, eliminating the attacker's opportunity to spoof the parked sibling with a forged-mark BIMI logo), (v) ORG-WIDE-BIMI-ROLLOUT-COORDINATION with the rest of the brand-portfolio marketing calendar (BIMI logo display debuts have measurable brand-trust signal value; the multi-domain- strategy spoke documents the coordination cadence between the portfolio-wide DMARC enforcement timeline and the brand-portfolio marketing-launch calendar so each BIMI logo debut maximises the cross-brand brand-trust signal). Read the multi-domain-strategy spoke alongside this BIMI pillar when scoping the portfolio-level BIMI rollout posture — the per-domain BIMI protocol mechanics documented here become the BUILDING-BLOCK repeated across every BIMI-eligible portfolio brand, and the multi-domain-strategy spoke provides the PORTFOLIO-LEVEL-BIMI-SEQUENCING- AND-VMC-COORDINATION meta-discipline preventing portfolio-brand BIMI debut misalignment, per-brand VMC procurement gaps, and parked-sibling BIMI publication drift.
• Phishing protection — the operator-facing defense-in-depth playbook BIMI contributes the visual-brand-verification layer to — the LAYERED-DEFENSE OPERATOR PLAYBOOK companion to this BIMI pillar. Where this pillar documents the BIMI protocol at the byte level (the default._bimi TXT record grammar, the v=BIMI1 / l= SVG URL / a= VMC URL tags, the SVG Tiny PS profile, the 32KB / 800x800 logo constraints, the Verified Mark Certificate (VMC) vs Common Mark Certificate (CMC) per-receiver eligibility matrix, the DMARC at enforce + 90-day rolling pass-rate ceiling), the phishing-protection spoke documents the FULL defense-in-depth control stack BIMI contributes ONE LAYER to: (i) authentication- protocol layer (the SPF + DKIM + DMARC + BIMI + MTA-STS + DANE + ARC controls this pillar's cluster catalogues, of which BIMI provides the VISUAL-BRAND- VERIFICATION half — the receiver-side rendering of an attestation-verified brand logo in the inbox-rendering UI conditional on DMARC enforce + cryptographic VMC chain-of- trust), (ii) gateway-control layer (SEG + sandbox URL analysis + attachment detonation + AI-based content classification), (iii) endpoint layer (EDR + browser isolation + WebAuthn / FIDO2 phishing-resistant MFA), (iv) identity layer (Conditional-Access + impossible-travel + token-binding + session-risk scoring), (v) user-behaviour layer (continuous phishing simulation + reporter-button workflow + JIT training), (vi) response layer (SOC + SIEM correlation + SOAR playbook automation + tabletop-exercise cadence). BIMI occupies a STRUCTURALLY- UNIQUE position in the layered defense because it is the ONLY anti-phishing control rendered DIRECTLY in the recipient-facing inbox UI — every other layer (gateway / EDR / identity / authentication-protocol / response) operates INVISIBLY to the end user, so BIMI is the only protocol-layer signal the user- behaviour layer can train against: "if the verified-brand logo is absent, treat the message as untrusted regardless of Display- Name or claimed-sender identity". This makes BIMI the load-bearing visual-signal layer of the anti-phishing user-behaviour control — but ONLY when stacked on top of DMARC enforce (the precondition for BIMI eligibility) and DKIM + SPF (the alignment inputs that determine the DMARC pass-rate BIMI display depends on). Read this spoke once BIMI is deployed per this pillar and need the operator-side reference for how the visual-brand-verification primitive composes with the broader anti-phishing control stack — including the user-training playbook for converting BIMI-logo-presence / absence into a behaviourally-actionable end-user signal.
• BIMI Verified Mark Certificates (VMC and CMC) — the dedicated deep-dive sibling spoke off this pillar covering the certificate half of the BIMI a= tag. Where this pillar tells you the BIMI record has an a= URL that points to a Verified Mark Certificate (and that Gmail / Apple Mail / Yahoo / Fastmail require one before the logo renders), the certificates page documents what the cert actually is, how you obtain one, and what it costs: the VMC vs CMC distinction (Verified Mark Certificate requires a registered trademark in a recognised jurisdiction; Common Mark Certificate accepts unregistered marks but only Gmail supports it as of 2025), the two issuing CAs (DigiCert and Entrust) with per-CA pricing and turnaround comparisons, the trademark-evidence + chain-of-title documentation pack the CA validates, the public-PKI trust chain that mailbox providers verify, the PEM-bundle file format the a= URL must serve, and the 12-month renewal cadence. Read once you have the BIMI record published on this pillar and need the operational reference for the cert acquisition workflow that gates logo display in every VMC-requiring inbox.
• Business Email Compromise (BEC) — the FINANCIAL-IMPACT THREAT-SCENARIO companion to this BIMI protocol pillar. Where this pillar documents the BIMI protocol at the byte-level (default._bimi.<domain> IN TXT "v=BIMI1; l=…svg; a=…vmc.pem" record, SVG Tiny PS profile, VMC chain- of-trust per the BIMI Working Group spec), the BEC spoke documents the FINANCIAL-IMPACT THREAT SCENARIO BIMI's visual-brand-verification primitive is engineered to defeat: the DISPLAY-NAME variant of CEO-fraud / invoice-fraud / payroll-diversion where the attacker forges only the visible "From: <Display Name>" string (the social-engineering layer DMARC's cryptographic-authentication primitive cannot reach because the d=-aligned signature validates the DOMAIN, not the display-name string). BIMI's logo rendering provides the recipient with a VISUAL TRUST SIGNAL that survives even the strongest display-name spoof: the absence of the legitimate brand logo next to "From: CEO Name" is the operator- intended detection cue. The BEC spoke catalogues the specific dollar-impact of each BEC variant (CEO fraud $130K/incident, invoice fraud $26B+ cumulative, payroll diversion HR-impersonation rerouting direct-deposit, vendor email compromise hijacked-legitimate-mailbox spoofing) and identifies the EXACT subset BIMI defeats: display-name spoofing of LEGITIMATE-BRAND identity WHEN the recipient mailbox provider is BIMI-rendering AND the publishing domain is at DMARC enforce AND the VMC chain- of-trust validates — three conditions that the BIMI pillar documented on this page is the canonical reference for. Read the BEC spoke when justifying the BIMI investment to commercial / marketing / brand-management stakeholders ("which dollar-impact threat scenario does BIMI specifically defeat" — the answer is the display- name-spoofing variant of BEC the spoke catalogues alongside the specific FBI IC3 dollar figures that justify the VMC commercial-acquisition workflow on the certificates spoke above).
• DNS propagation explained — the DNS-INFRASTRUCTURE-CACHE-AGING companion to this BIMI pillar's DNS record-publication mechanism. Where THIS page documents the BIMI protocol's visual-brand-verification primitive (RFC-draft BIMI Working Group spec: the default._bimi.<domain> IN TXT "v=BIMI1; l=…svg; a=…vmc.pem" record's v= / l= / a= tag triplet, the organizational-domain inheritance semantics, the per-selector <selector>._bimi record convention, and the DMARC-enforcement pre-condition each mailbox-provider's logo-rendering policy gates BIMI display on), the DNS-propagation spoke documents the DNS-INFRASTRUCTURE-LAYER behaviour that determines WHEN a newly-published default._bimi TXT record BECOMES OBSERVABLE across the mailbox- provider population that performs the BIMI lookup per inbound message: per- record TTL semantics (RFC 1035 §3.2.1 + RFC 2181 §8), the resolver-cache minimum + maximum cap quirks (Cloudflare 1.1.1.1 300-second negative- cache floor; Google 8.8.8.8 21 600-second TTL cap; corporate resolvers' 1800-second minimums), and the diagnostic workflow operators run when a fresh BIMI publication produces "no BIMI record found" at Gmail / Apple Mail / Yahoo despite the operator confirming the new TXT record is present in the authoritative zone: dig / kdig directly against the authoritative nameservers ("dig default._bimi.example.com TXT @ns1.your-dns-provider.com") to confirm publication, then dig with +norecurse against multiple recursive resolvers to confirm what each cache currently believes, then the web- based propagation checker for the global cache snapshot. Read the propagation spoke when a fresh BIMI record publication does not produce logo rendering at inbox-providers in the first 24-72 hours after publication — DNS propagation of the default._bimi TXT record across the mailbox-provider's recursive- resolver path is almost always the explanation, especially when the operator has confirmed the VMC PEM is served at the a= URL and the SVG is served at the l= URL with public-PKI HTTPS — both of which depend on the prior TXT-record DNS-propagation step.
• MTA-STS policy-file byte syntax — the BIMI-DISPLAY-PREREQUISITE-DEPENDS- ON-DMARC-AT-ENFORCE-WHOSE-OPERATIONAL- INTEGRITY-DEPENDS-ON-TRANSPORT-LAYER- MTA-STS-POLICY-FILE-MX-ALLOW-LIST- DISCIPLINE companion to this BIMI pillar. Where THIS page documents the BIMI protocol at the byte level (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 / l=<SVG-URL> / a=<VMC-URL> tag grammar, the SVG Tiny PS profile, the VMC vs CMC per-receiver eligibility matrix, the DMARC-at-enforce + 90-day rolling pass-rate ceiling), the MTA-STS-policy- syntax spoke is the TRANSPORT-LAYER OPERATIONAL-INTEGRITY-PREREQUISITE BYTE-GRAMMAR REFERENCE documenting the RFC 8461 §3.2 policy-file format whose transport-layer enforcement is the upstream integrity prerequisite for the publisher-side DMARC-at-enforce posture BIMI display requires. The BIMI-DISPLAY- DEPENDS-ON-DMARC-DEPENDS-ON-MTA-STS- POLICY-BYTE-DISCIPLINE cross-reference establishes FIVE structurally-distinct per-byte-grammar-tag relevant BIMI- eligibility dependencies: (i) mode: enforce at the publisher's MTA-STS policy — the MTA-STS-policy-syntax spoke documents the byte-tag whose receiver- side STRICT-STARTTLS commitment is the transport-layer DEFENCE that prevents a downgrade-to-cleartext MITM from SILENTLY modifying BIMI-asserted mail in transit; without mode: enforce, the BIMI publisher's DMARC pass-rate ceiling could be eroded by intermediary attackers who modify mail content, breaking DKIM verification and the DMARC-at-enforce prerequisite for BIMI display; (ii) mx: <hostname-glob> allow-list at the publisher's MTA-STS policy — the spoke documents the byte-format whose tight allow-list bounds the set of MX hosts receivers will deliver BIMI-asserted mail through; a permissive or stale allow-list creates the transport-layer attack surface that could compromise the publisher's sustained DMARC pass-rate; (iii) max_age: <seconds > policy-file freshness budget — the spoke documents the receiver-side cache-lifetime semantic; BIMI publishers maintaining a 90-day rolling DMARC pass-rate ceiling must ensure receiver-side MTA-STS policy caches are sufficiently fresh to track mx: allow-list edits that respond to compromised-MX events within the 90-day window; (iv) version: STSv1 protocol-version sentinel — the spoke documents the version- sentinel as the FIRST byte of the policy file; BIMI publishers' operational transport-layer baseline depends on every receiver recognising the version-sentinel before applying the allow-list; (v) cross- protocol complementarity with TLS-RPT report-format observability of intra- BIMI-delivery STARTTLS anomalies — when a BIMI-publisher's outbound delivery encounters STARTTLS failure at an unauthorised MX, the receiver generates a TLS-RPT JSON report the publisher SOC consumes; the MTA-STS- policy-syntax spoke documents the publisher-side mx: allow- list discipline whose tight maintenance ensures the TLS-RPT stream surfaces every BIMI-delivery transport-layer anomaly that could erode the BIMI eligibility ceiling. Pair this page (the BIMI byte-level protocol reference) with the MTA-STS-policy- syntax spoke (the transport-layer publisher-side policy-file byte- grammar reference) when authoring the BIMI deployment posture review — the spoke documents the transport-layer operational-integrity prerequisite whose tight maintenance preserves the DMARC-at-enforce posture this page documents as the load-bearing BIMI eligibility gate.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-MTA-STS-AS- TRANSPORT-LAYER-PREREQUISITE-FOR-BIMI- VMC-RENDERING companion to this BIMI deployment pillar. Where THIS page documents the BIMI VMC indicator- display contract at the receiver-side BIMI-supporting consumer-inbox (the v=BIMI1; l=<svg-url>; a=<vmc-url> DNS record publication mechanics, the SVG Tiny PS asset constraints, the VMC trademark-evidence pack the CA validates, the receiver-side cert- chain validation at message-rendering time, the 13-month VMC validity window and the publisher-side DMARC- at-enforce alignment prerequisite that unlocks BIMI logo display in Gmail / Outlook / Apple Mail / Yahoo / Fastmail consumer inboxes) — i.e. the APPLICATION-LAYER-BRAND-INDICATOR- DISPLAY side of the BIMI deployment — the Workspace MTA-STS spoke is the WORKSPACE-TENANT-TRANSPORT-LAYER- OPERATIONAL-INTEGRITY-PRESERVING- DMARC-AT-ENFORCE-POSTURE companion documenting the Workspace-operator- published MTA-STS policy whose receiver-side STARTTLS-enforcement contract preserves the operational integrity of the Workspace-tenant- published DMARC-at-enforce posture THIS page documents as the BIMI eligibility gate. Concretely, the spoke documents FOUR Workspace-MTA- STS-as-BIMI-precondition dimensions: (i) Workspace-tenant BIMI VMC rendering at Gmail and Outlook consumer inbox structurally requires DMARC-at-enforce on the Workspace- tenant Friendly-From-header domain — the BIMI deployment gate THIS page documents requires the publishing domain to publish p=quarantine or p=reject DMARC posture with pct=100, and the Workspace MTA-STS spoke documents the Workspace-tenant-specific transport- layer-STARTTLS-enforcement that preserves that posture's operational integrity against active downgrade- induced authentication-failure cascades on inbound Workspace-tenant receive paths; (ii) Workspace- tenant published MTA-STS enforce- mode policy at https://mta- sts.<workspace-domain>/.well- known/mta-sts.txt with mx: directive listing the 5-host tier'd MX inventory bounds the transport-layer-STARTTLS- enforcement contract cooperating sending MTAs apply when delivering BIMI-VMC-Friendly-From-header-aligned mail to Workspace-hosted recipient domains — the Workspace MTA-STS spoke documents the publisher- published policy file's mx: aspmx.l.google.com + 4 alt-tier entries that lock in the transport-layer-STARTTLS- enforcement contract on Workspace inbound mail, structurally orthogonal to but operationally complementary with the BIMI VMC indicator-display contract THIS page documents at the application layer; (iii) Workspace-tenant BIMI VMC chain validation runs structurally SEPARATELY from Workspace MTA-STS HTTPS-policy-host cert validation but BOTH publisher- side cert-validation contracts must succeed for BIMI rendering to remain operationally unlocked — the BIMI VMC cert chain validates at receiver-side message-rendering time against the BIMI-WG-approved-CA root list, and the Workspace MTA-STS spoke documents the publisher-published HTTPS policy-host cert validation against the standard web-PKI root list at sending-side STARTTLS time — these two publisher-side cert- validation contracts run at STRUCTURALLY-DISTINCT cryptographic validation timepoints (BIMI at receiver-side rendering, MTA-STS at sender-side STARTTLS) but the Workspace-tenant operator coordinates BOTH publisher-side cert-validation contracts as part of the integrated BIMI-deployment-readiness validation the BIMI VMC rendering deployment depends on; and (iv) Workspace- tenant MTA-STS-policy-cache-rollover coordination is part of the BIMI VMC deployment-window discipline — when the Workspace tenant updates the published policy file's mx: directive (during Workspace tier migration, Workspace- domain-rename, or coordinated security incident response MX-decommission), the receiver-side policy-cache- rollover semantics the spoke documents directly bound the transport-layer-operational-integrity- window during which the BIMI VMC rendering contract's underlying DMARC- at-enforce posture remains operationally hardened — the publisher-side BIMI VMC deployment- readiness review THIS page documents MUST coordinate with the Workspace- tenant MTA-STS-policy-cache-rollover cadence the spoke documents to preserve the BIMI VMC rendering contract's operational integrity across BIMI deployment windows. Read the MTA-STS-for-Google-Workspace spoke alongside this BIMI deployment pillar when planning BIMI VMC rendering deployment on a Workspace- hosted publishing domain — the Workspace-tenant transport-layer MTA-STS deployment is the load- bearing operational-integrity- preserving prerequisite for the Workspace-tenant DMARC-at-enforce posture THIS page documents as the BIMI VMC rendering eligibility gate.
• MTA-STS explained - the BIMI-VMC-CERT-AT-INDICATOR-DISPLAY- LAYER-VS-MTA-STS-POLICY-HOST-HTTPS-CERT-AT- TRANSPORT-LAYER-CROSS-PUBLISHER-CERT- VALIDATION companion to this BIMI pillar. Where THIS page documents the BIMI indicator-display-layer authentication- policy mechanism (VMC X.509 cert published in the BIMI a=-tag pointer chain, SVG Tiny PS asset publication at the l=-tag URL, per-receiver Gmail/Apple/Yahoo display-engine VMC- chain-validation consumption), the dedicated MTA-STS-explained spoke documents the STRUCTURALLY-PARALLEL transport-layer- SMTP-receive authentication-policy mechanism at four cross-protocol publisher-cert- validation-discipline dimensions whose operator-discipline framework parallels the BIMI-VMC-cert-validation discipline: (i) both mechanisms publish a publisher-side authentication-policy authority at a structurally-analogous DNS sub-owner-name (BIMI at default._bimi.<domain> TXT record pointing to the VMC a= URL; MTA-STS at _mta-sts.<domain> TXT record providing the policy-version identifier pointing to the mta-sts.<domain> HTTPS policy file) - both DNS sub-owner-names require the publisher's per-domain publication discipline at the apex zone and inherit the same DNS-publication- cascade prerequisites; the MTA-STS spoke documents the per-sub-owner-name TXT-RR publication discipline that parallels BIMI's per-selector ._bimi sub-owner-name publication discipline; (ii) both mechanisms require an HTTPS-served authentication-content fetch with cert- chain-validation at the receiver's consumer-side - BIMI receivers fetch the VMC a=-URL HTTPS resource and validate the VMC X.509 chain (DigiCert / Entrust BIMI Working Group approved issuers); MTA-STS sending MTAs fetch the mta-sts.<domain> HTTPS policy file and validate the policy-host leaf cert (typically Let's Encrypt / Sectigo / Google Trust Services) - BOTH mechanisms depend on the publisher maintaining a valid CA-issued HTTPS cert at the publication endpoint with renewal-cycle discipline; the MTA-STS spoke documents the policy-host HTTPS cert publication and renewal discipline that parallels BIMI's VMC cert publication and renewal discipline; (iii) both mechanisms encode a publisher-side ENFORCEMENT-STRICTNESS commitment via a publisher-tunable operator-discipline dial - BIMI's a=-tag presence vs absence is the publisher's binary commitment to VMC-validated display (absence falls back to non-VMC SVG-only display that Gmail demotes), while MTA-STS's mode: enforce vs mode: testing vs mode: none is the publisher's graded-strictness commitment to receiver- side TLS-failure-rejection - both encode operator-rollout-staged tunable commitments with non-rejecting initial states that ramp to enforcement after publisher's observation of the evidence stream; the MTA-STS spoke documents the mode-tier publisher- ramp-discipline that parallels BIMI's VMC-rollout publisher-discipline; and (iv) both mechanisms produce a receiver-side observability evidence stream surfaced through a parallel reporting layer - BIMI's per-receiver display-rate observability surfaces in Postmaster-Tools / Mailbox-provider publisher dashboards; MTA-STS's TLS- validation-failure observability surfaces in TLS-RPT JSON reports at the publisher's rua=-mailbox - both reporting layers produce per-publisher per-day per-receiver verdict-distribution evidence the publisher consumes for operator-discipline-rollout decisions; the MTA-STS spoke documents the TLS-RPT- as-publisher-side-observability reporting layer that parallels BIMI's Postmaster- Tools-as-publisher-side-observability reporting layer, closing the cross- protocol observability-feedback-loop parallel this BIMI pillar's deployment- framework rests on.
• SMTP TLS Reporting (TLS-RPT) report format — the BIMI-DEPLOYMENT-TLS-DEPENDENCY- OBSERVER companion to this BIMI pillar. Where THIS page documents the BIMI protocol at the byte level (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 / l=<SVG-URL> / a=<VMC-URL> tag grammar, the SVG Tiny PS profile, the VMC vs CMC per-receiver eligibility matrix, the DMARC-at-enforce + 90-day rolling pass-rate ceiling), the TLS-RPT report-format spoke is the TRANSPORT-LAYER OBSERVABILITY companion documenting the RFC 8460 §4 JSON report schema receivers emit when their STARTTLS connection to the BIMI-publisher's sending MTA fails — a transport-layer observability dimension structurally orthogonal to the BIMI protocol contract but operationally CRITICAL because (i) the VMC at the a= URL and the SVG at the l= URL are retrieved by receivers over HTTPS — the HTTPS endpoint's TLS handshake is transport-layer cleartext-vs-encryption observation captured in the same TLS-RPT family of reports that observes the publisher's SMTP STARTTLS contract, (ii) BIMI-asserted mail flowing from the publisher's MTA to the receiver's MTA crosses the TLS-RPT observation boundary — a transport-layer downgrade attack that strips STARTTLS will deliver the BIMI-asserted mail in cleartext, and the TLS-RPT JSON report-format spoke documents the failure-type taxonomy ("starttls-not-supported", "certificate-host-mismatch", "certificate-not-trusted", "validation-failure") that surfaces this downgrade in the operator's daily TLS-RPT triage queue, (iii) a sustained TLS-RPT failure rate against a BIMI- publisher's sending MTA is the leading-indicator metric for receiver-side BIMI logo disappearance because receivers often suppress BIMI display when their inbound delivery to the publisher's domain shows a sustained transport-layer authentication gap. Read the TLS-RPT report-format spoke when the BIMI deployment is observably stable at the application layer (DMARC enforce passing, BIMI TXT/SVG/VMC published) but the brand-trust analytics dashboard reports intermittent BIMI logo disappearance at specific receivers — the TLS-RPT JSON reports for the publisher's sending MTA are the canonical evidence source for whether a transport-layer downgrade or certificate-validation failure on the BIMI-publisher's outbound STARTTLS endpoint is the structural cause.
• BIMI SVG file requirements (SVG Tiny PS profile) — the dedicated deep-dive sibling spoke off this pillar covering the other half of the BIMI record: the l= tag URL that must serve a profile-conformant SVG file. Where this pillar tells you the BIMI record has an l= URL that points to the brand logo (and that the file must follow the SVG Portable/Secure profile published by the BIMI Group), the SVG-requirements page documents the byte-level constraints the mailbox provider will actually validate before rendering: the baseProfile="tiny-ps" root attribute that gates conformance (its omission is the #1 silent-rejection cause), the explicit black/white-list of permitted SVG elements (<svg>, <path>, <g>, <title>) versus forbidden elements (<script>, <animate>, <foreignObject>, external <image> references) that cause silent reject, the 1:1 square aspect ratio with safe central crop circle that survives downstream circular cropping by Gmail and Apple Mail, the no-raster-images-allowed constraint (<image> elements with href to PNG/JPEG are profile-invalid even though they parse), the HTTPS-only fetch contract with public-PKI trust chain (the same constraint that gates the certificate file), the < 32 KB recommended file-size ceiling for inbox render latency, and the SVG-validator tooling published by the BIMI Group to check conformance before publication. Read alongside the certificate spoke (above) for the complete BIMI record-payload reference: l= SVG + a= VMC together form the two-file deployment artefact every VMC-requiring inbox validates before rendering the brand logo.
• CAA records explained (Certificate Authority Authorization, RFC 8659) — the UPSTREAM-PKI-ISSUANCE-POLICY-GATEKEEPER-FOR-VMC-CERTIFICATE-PROCUREMENT companion — the UPSTREAM-PKI-ISSUANCE-POLICY- GATEKEEPER companion reference for BIMI VMC certificate procurement. Where THIS page documents the BIMI protocol surface from the publisher-deployment-and-render perspective (publish DNS TXT record at default._bimi.<domain> with v=BIMI1; l=<svg-url>; a=<vmc-url> / receiver validates DMARC alignment / receiver fetches and validates SVG Tiny PS / for VMC-requiring receivers receiver fetches and validates VMC X.509 cert chain / receiver renders brand-logo indicator), the CAA-records spoke documents the UPSTREAM PUBLISHER-SIDE PKI-issuance- policy enforcement contract that gates WHICH CA CAN ACTUALLY ISSUE THE VMC the BIMI deployment requires. CAA (RFC 8659) is a DNS-published RR-type-257 record at the publisher's apex domain (or a specific subdomain) carrying property= value pairs that ENUMERATE THE FINITE LIST OF CAs the publisher AUTHORISES TO ISSUE certificates against the domain name: example.com. CAA 0 issue "digicert.com" AUTHORISES only DigiCert as a VMC-eligible CA; example.com. CAA 0 issue "entrust.com" AUTHORISES only Entrust; example.com. CAA 0 issue ";" FORBIDS all CA issuance. The two CURRENT VMC-issuing CAs are DigiCert and Entrust (per the BIMI Group's authorised-CA list); a publisher with CAA "issue" records EXCLUDING the CA chosen for VMC procurement encounters a CA-side refusal-to-issue at the VMC application step regardless of trademark validation and SVG conformance — the CAA record is the binding-publisher-policy- assertion ALL CAs RFC 8659 §4 mandates respecting before issuance. CAA records are ESSENTIAL DEFENSE-IN-DEPTH for BIMI- publishing publishers because they STRUCTURALLY BIND VMC-issuance authority to the publisher's authorised CA set, preventing an attacker-compromised CA from issuing an attacker-controlled VMC against the publisher's brand (an attacker who compromises Sectigo cannot issue against a publisher whose CAA is "issue digicert.com" because RFC 8659 §4 requires Sectigo's pre-issuance check to refuse). Read the CAA-records spoke BEFORE applying for a VMC — the BIMI deployment sequence is: trademark- registration → CAA records published → VMC procurement → SVG finalised → DNS TXT BIMI record published → receiver- side BIMI display. CAA records before VMC procurement is the recommended sequence because amending CAA records AFTER VMC issuance to remove a CA that has already issued an active VMC does NOT revoke the issued certificate (CAA is an issuance-time gate, not a runtime-validation gate); the certificate remains valid until natural expiry or explicit CA-side revocation. CAA also supports an iodef property pointing to a mailto: or https: URL where CAs MUST report attempted-issuance-against-CAA-violating records — this surfaces attacker- attempts at adversarial VMC procurement AGAINST the publisher's brand BEFORE the attacker succeeds.
• DMARC policy rollout — the DMARC-AT-ENFORCE-AS-BIMI-DISPLAY- ELIGIBILITY-PREREQUISITE-RAMP companion to this BIMI protocol pillar. Where THIS page documents the BIMI brand-indicator display protocol (the per-publisher default._bimi.<d> TXT- RR with v=BIMI1 / l= SVG-logo URL / a= VMC certificate URL publication, the SVG Tiny PS 1.2 profile rendering constraints, the X.509 VMC / CMC chain-of-trust via CA/Browser-Forum Mark Certificate Working Group profile), the DMARC policy rollout spoke is the OPERATOR-FACING PHASED-DEPLOYMENT-RAMP documentation whose end-state (p= quarantine or p=reject full-enforcement) is the LOAD-BEARING PUBLISHER-SIDE PREREQUISITE every BIMI- aware mailbox provider (Gmail, Yahoo Mail, AOL, Apple iCloud Mail in iOS 16+) enforces against the publisher's per-domain _dmarc TXT-RR BEFORE the BIMI logo this pillar documents is rendered at the receiver UI. The four-axis BIMI-DISPLAY-VS- DMARC-ROLLOUT-RAMP comparison exposes the structurally-distinct per-ramp- stage prerequisite dimensions: (i) BIMI display gating at every BIMI-aware mailbox provider REQUIRES the publisher's per-domain _dmarc TXT-RR to publish p=quarantine AT MINIMUM (Gmail / Yahoo / AOL accept p=quarantine; Apple iCloud Mail in iOS 16+ requires p=reject per the Apple BIMI deployment guidance) — making the DMARC policy-rollout spoke's terminal-stage commitment the GATING PUBLISHER-SIDE POLICY for BIMI display eligibility, and the publisher's pre-terminal ramp stages (p=none monitoring, p=quarantine pct=<n> partial enforcement) STRUCTURALLY BLOCK the BIMI logo from rendering at the receiver UI — the DMARC policy rollout spoke documents the per-ramp-stage publisher-side commitment curve every BIMI-display- seeking publisher must complete BEFORE the brand-indicator display reward this BIMI pillar documents operationally unlocks; (ii) BIMI display gating additionally requires the publisher's per-domain _dmarc TXT-RR to publish pct=100 (not pct=50 or any partial percentage) — meaning the DMARC policy-rollout spoke's pct= ramp-gate intermediate stages (p=quarantine pct=10 → pct=25 → pct=50 → pct=100) are EACH intermediate publisher-side commitments that BIMI display eligibility STRUCTURALLY GATES ON the terminal-stage pct=100 commitment before unlocking — the DMARC policy rollout spoke documents the per-stage pct=-ramp-gate operational discipline every BIMI- display-seeking publisher must traverse, and the per-stage pct=<n> partial-enforcement intermediate states are EACH STRUCTURAL- DISQUALIFIERS for BIMI display at the receiver UI until the terminal pct=100 commitment publishes; (iii) BIMI display gating at Apple iCloud Mail (iOS 16+) requires the publisher's per-domain _dmarc TXT-RR to publish p=reject AND the per-subdomain sp=-tag coverage commitment (the publisher's subdomain-policy commitment that each subdomain inherits the parent-domain enforcement posture) — making the DMARC policy-rollout spoke's sp=-tag per- subdomain coordination an additional Apple-specific BIMI- display prerequisite — the DMARC policy rollout spoke documents the per-subdomain sp=-tag rollout- coordination discipline every BIMI-display-seeking publisher with subdomain-publishing infrastructure must accommodate BEFORE the Apple-specific BIMI display gate this BIMI pillar documents operationally unlocks; and (iv) BIMI display gating additionally depends on the publisher's per-domain DMARC-evaluation result MATERIALISING dmarc=pass consistently across per-message receiver-side evaluation — making the DMARC policy- rollout spoke's per-source-IP root-cause attribution and per-stage RUA-stream- monitoring discipline the OPERATOR-FACING DIAGNOSTIC SURFACE that converts the per-stage ramp completion into the consistent dmarc=pass materialisation the BIMI display gate consumes at every per-message receiver- side evaluation — the DMARC policy rollout spoke documents the per-ramp-stage per-source-IP root-cause attribution operational discipline every BIMI- display-seeking publisher must execute through every ramp stage to keep the per- message dmarc=pass rate at the per-message- BIMI-display-eligibility- consuming receiver-side threshold. Read the DMARC policy rollout spoke BEFORE publishing the per-domain default._bimi TXT-RR documented on this page (audit the per-domain _dmarc TXT-RR's current ramp stage — must be at p=quarantine / p=reject with pct=100 BEFORE the BIMI publication completes the eligibility chain), and when diagnosing why the BIMI logo this pillar documents is NOT rendering at the receiver UI despite a syntactically- valid BIMI publication (correlate the per-domain _dmarc TXT-RR ramp-stage commitment with the per-receiver BIMI- display gate this BIMI pillar documents).
• DKIM canonicalization — the PER-PUBLISHER-PER-MESSAGE- CANONICALIZATION-ALGORITHM-CHOICE- AS-LOAD-BEARING-UPSTREAM-DETERMINANT- OF-DKIM-PASS-VERDICT-WHOSE-SURVIVAL- UNDER-PER-FORWARDER-HOP-MODIFICATIONS- IS-PRECONDITION-TO-THE-DMARC-ALIGNED- PASS-VERDICT-THE-BIMI-DISPLAY- ELIGIBILITY-GATE-REQUIRES companion to this BIMI pillar. Where THIS page documents the per-receiver per- publisher BIMI-logo display- eligibility evaluation pipeline (the per-publisher default._bimi.<domain> TXT-RR v=BIMI1; l=...; a=... publication discipline, the per- publisher VMC-issuance-discipline precondition, the per-receiver per-publisher per-message DMARC- aligned-pass verdict gate the receiver-side BIMI-display evaluation requires per RFC-pending- IETF-draft-brand-indicators-for- message-identification, the per- receiver per-publisher per-message BIMI-logo render at inbox-display layer), the DKIM-canonicalization spoke is the STRUCTURALLY-UPSTREAM per-publisher per-message canonicalization-algorithm-choice- publication-discipline reference whose RFC 6376 §3.4 simple-vs- relaxed canonicalization-algorithm- pair primitive published in the per- message DKIM-Signature header's c=-tag determines whether the per-message DKIM signature survives per-forwarder- hop header-and-body modifications to produce the dkim=pass verdict the receiver-side DMARC-aligned- pass evaluation requires as the load-bearing message-layer- authentication-input upstream of the per-receiver per-publisher BIMI-logo display-eligibility gate THIS BIMI pillar documents. The DKIM-canonicalization-vs-BIMI- display-eligibility coupling establishes four specific per- publisher canonicalization-choice- to-BIMI-display-eligibility dimensions: (i) per- publisher canonicalization-choice as load-bearing per-publisher per- forwarder-class precondition for per-message BIMI-display- eligibility at the per-receiver inbox-render layer — per-publisher c=simple choice produces per-forwarder-class dkim=fail at near-100% rate for per-publisher mail forwarded through per-mailing-list-server / per-corporate-relay / per-list- management-platform per-source-IP cohorts; the per-message DMARC- aligned-pass verdict fails for those cohorts; the per-receiver per-publisher BIMI-logo display is suppressed at the receiver inbox-render layer; per-publisher canonicalization-discipline (typically c=relaxed/relaxed) is a load-bearing precondition for per-publisher per-forwarder-class BIMI-display coverage; (ii) per-publisher canonicalization-choice as load- bearing per-publisher per-mailing- list-recipient per-message BIMI- display-suppression-vs-display determinant — per- publisher legitimate-marketing- mailing-list mail forwarded through per-list-management- platform with Subject-prefix rewrite + List-Unsubscribe- header injection + mailing- list-footer body-text injection breaks per-publisher per-message DKIM signature under c=simple canonicalization → per-message DMARC-aligned-pass fails → per- receiver per-mailing-list- recipient inbox-render BIMI- logo is suppressed → per- publisher brand-recognition engagement-rate uplift the BIMI- display delivers is lost for the per-mailing-list-recipient cohort; per-publisher canonicalization-migration to c=relaxed/relaxed restores per- forwarder-class BIMI-display coverage; (iii) per- publisher canonicalization-choice as load-bearing per-publisher per- tenant per-DKIM-signing- infrastructure BIMI-display- consistency determinant — per-publisher canonicalization- drift across per-tenant per-DKIM- signing-infrastructure (per-tenant SaaS-sender signing with c=simple while per-tenant marketing-ESP signing with c=relaxed) produces per-publisher per-d=-signing- domain per-selector per-message DKIM-pass-rate variance → per- publisher per-d=-signing-domain per-message DMARC-aligned-pass- rate variance → per-receiver per- publisher per-mail-class BIMI- display-coverage variance the per-publisher brand-recognition programme this BIMI pillar serves observes; (iv) per- publisher canonicalization-choice as load-bearing per-publisher cross-receiver BIMI-display- coverage KPI determinant — per-publisher canonicalization discipline (uniform c=relaxed/ relaxed across per-publisher DKIM-signing infrastructure) is a load-bearing precondition for the per-publisher cross-receiver per- mail-class BIMI-display coverage KPI the per-publisher brand- recognition programme this BIMI pillar documents targets — per- publisher canonicalization- suboptimal-choice silently caps the per-publisher BIMI-display- coverage KPI ceiling regardless of per-publisher DMARC-p=reject + per-publisher VMC-issuance + per-publisher BIMI-RR-publication discipline. Read the DKIM- canonicalization spoke alongside this BIMI pillar when investigating per-publisher per-forwarder-class BIMI-display-suppression cohort root-cause (canonicalization- choice mismatch with per-forwarder- hop modification discipline is a canonical per-publisher per-mail- class BIMI-display-coverage-cap root-cause class), and when planning per-publisher canonicalization- consolidation discipline whose downstream impact on per-publisher per-mail-class BIMI-display- coverage KPI the per-receiver per-publisher BIMI-display- eligibility gate THIS BIMI pillar documents structurally produces.
• DNS Record Generator — interactive wizard for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records with syntax validation and best-practice defaults.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC against any domain.
• Email Header Analyzer — paste a raw email header to see SPF, DKIM, and DMARC pass/fail results inline with explanation — useful for confirming a specific send is DMARC-aligned (and therefore BIMI-eligible).
• DMARC attacker bypass techniques — the 22-TECHNIQUE PER-PUBLISHER PER-DOMAIN BRAND-INDICATOR- ELIGIBILITY-DEFENCE CLASSIFICATION-FRAMEWORK companion to this BIMI pillar reference. Where THIS page documents the BIMI protocol primer (IETF draft-brand- indicators-for-message-identification per-publisher per-domain default._bimi SVG Tiny PS publication discipline, the BIMI-draft §5 DMARC enforcement- mode prerequisite of p=quarantine pct=100 or p=reject, the per-publisher per-domain VMC Verified Mark Certificate publication discipline, the per- receiver per-message Brand- Indicators Authentication-Results verdict), the attacker-bypass spoke is the per-publisher per- domain attacker-side DMARC- alignment-evaluation-bypass technique-classification documenting the FOUR BIMI-targeted attacker- bypass technique-classes the per- publisher per-domain operator MUST defend against at the per-publisher per-domain BIMI-eligibility- prerequisite boundary: (i) cousin-domain BIMI- impersonation via attacker- registered homoglyph cousin-domain VMC procurement — attacker registers a per-publisher per- domain homoglyph cousin-domain (rn-vs-m, l-vs-I, cyrillic-vs- latin), procures a VMC for the cousin-domain (the BIMI ecosystem does not gate VMC issuance on per-publisher per-domain trademark priority across the entire homoglyph space), publishes a cousin-domain BIMI SVG that visually impersonates the per- publisher per-domain brand indicator, and exploits per-receiver UI display of the cousin-domain's attacker-controlled brand indicator adjacent to the cousin-domain's From: header; (ii) BIMI- eligibility downgrade via per-publisher per-domain DMARC- policy-mode rollback attack — attacker observes that the per- publisher per-domain DMARC record publication is the load-bearing BIMI-eligibility prerequisite, and targets the per-publisher per- domain authoritative-nameserver or per-publisher per-domain DNS management control plane to roll back the per-publisher per-domain DMARC-policy-mode from p=reject back to p=none, disabling BIMI-eligibility cross all per- receiver per-message brand- indicator rendering; (iii) BIMI-record-pollution via attacker-controlled default._bimi.<domain> TXT-record-injection — attacker compromises the per- publisher per-domain authoritative nameserver and replaces the per- publisher per-domain default._bimi TXT record's l=-tag SVG URL with an attacker-controlled SVG endpoint serving a malicious brand-indicator SVG that visually diverges from the per-publisher per-domain registered trademark; (iv) per-receiver BIMI- rendering-pipeline VMC-revocation- lag exploitation — attacker procures a VMC, ships malicious per-publisher per-domain impersonation campaigns at scale, and exploits the per-receiver per- message brand-indicator-rendering pipeline's revocation-status- checking lag (VMC revocation- propagation across the per-receiver validator population is not instantaneous) to ship per-receiver per-message attacker-side brand- indicator-decorated messages during the revocation-lag window. Read THIS page when AUTHORING the per- publisher per-domain BIMI pillar publication discipline; read the DMARC-attacker-bypass spoke when DESIGNING the per-publisher per- domain BIMI-eligibility-attacker- defence posture against the 22- technique attacker-bypass classification framework — the spoke is the canonical attacker- bypass technique catalogue the per- publisher per-domain BIMI posture THIS page documents must structurally defend against.
• DKIM cryptography basics (RSA-2048 / Ed25519 / SHA-256) — the PER-PUBLISHER-PER-SELECTOR- CRYPTOGRAPHIC-KEY-PAIR-PUBLICATION- DISCIPLINE-AS-LOAD-BEARING-UPSTREAM- PRIMITIVE companion to this BIMI protocol pillar. Where THIS page documents the BIMI byte-level protocol (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 version prefix, the per-receiver-organisation brand- indicator inbox-list rendering decision, the VMC verified-mark- certificate upgrade tier), the DKIM- cryptography-basics spoke documents the UPSTREAM per-publisher per-selector cryptographic-key-pair publication discipline (RFC 6376 §3.3 rsa-sha256 / ed25519-sha256 algorithm catalogue, the per-selector 2048-bit RSA modulus floor per the Gmail / Yahoo Bulk Sender Requirements February 2024, the per-publisher key-rotation cadence, the per-selector public-key TXT record v=DKIM1; k=rsa; p=<BASE64-key> byte-shape) whose per-publisher per- selector cryptographic primitive publication is the LOAD-BEARING upstream cryptographic anchor every per-message DKIM-verify-pass verdict depends on — and therefore the upstream cryptographic anchor every DMARC-aligned-DKIM-pass verdict that gates the per-receiver BIMI display eligibility evaluation depends on. The BIMI-VS-DKIM-CRYPTOGRAPHY cross- reference establishes FOUR structurally-distinct cryptographic- publication coupling dimensions: (i) BOTH protocols publish per- publisher cryptographic primitives at DNS — DKIM publishes the per-selector public key under <s>._domainkey.<d>; BIMI publishes the brand-indicator SVG + VMC reference under default._bimi.<d-domain> — the per-publisher per-domain DNS- rooted-trust-anchor publication primitive is identical in shape; (ii) BIMI-display eligibility is GATED on a per-message DMARC- aligned-DKIM-pass verdict whose cryptographic correctness this DKIM cryptography spoke documents — Gmail / Yahoo / Apple Mail's BIMI- eligibility evaluator returns FALSE for any message that fails per-message DKIM cryptographic verification, so the per-publisher per-selector cryptographic-key-pair publication discipline is the upstream load- bearing primitive without which BIMI rendering cannot occur; (iii) BIMI VMC certificates (X.509 Verified Mark Certificate, RFC 9162 Certificate Transparency-logged) and DKIM RSA-2048 key pairs are both per-publisher PUBLIC-KEY-INFRASTRUCTURE primitives — the BIMI VMC binds the SVG mark to the publisher's identity via X.509; the DKIM RSA-2048 key pair binds the per-message signature to the publisher's identity via per-selector TXT publication; both are per-publisher cryptographic- identity-binding primitives at complementary protocol layers (display-layer X.509 vs message-layer rsa-sha256); (iv) per-publisher DKIM key-rotation cadence and BIMI VMC renewal cadence share an operational discipline — both require per-publisher per-key-pair-or- certificate scheduled rotation with DNS-propagation-aware overlap windows; operators who manage per-selector DKIM key rotation per RFC 6376 §3.6.1 can transfer the same overlap-window operational discipline directly to per-VMC renewal cadence. Read this BIMI pillar when DEPLOYING the per- publisher per-domain brand-indicator inbox-list rendering posture; read the DKIM-cryptography-basics spoke when UNDERSTANDING the upstream per- publisher per-selector cryptographic- key-pair publication discipline whose per-message DKIM-verify-pass verdict gates the per-receiver BIMI display eligibility this page's protocol contract documents.
• DKIM for Microsoft 365 — the PER-M365-TENANT-DKIM-SIGNING- DISCIPLINE-AS-UPSTREAM-BIMI-ELIGIBILITY- PRIMITIVE companion to this BIMI protocol pillar. Where THIS page documents the BIMI byte-level protocol (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 version prefix, the per-receiver-organisation brand-indicator inbox-list rendering decision, the VMC verified-mark-certificate upgrade tier), the DKIM-for-M365 spoke documents the UPSTREAM per-M365-tenant per-custom-domain DKIM-signing deployment workflow (Exchange Admin Center > mail-flow > DKIM; per- tenant per-custom-domain DKIM-Enable toggle; per-tenant per-custom-domain dual-selector1-and-selector2 rotation under selector1._domainkey.<d> + selector2._domainkey.<d> published as per-tenant CNAME pointers to per-tenant provider-managed selector*-<tenantId>._domainkey.<onmicrosoft-tenant>; per-tenant Rotate-DKIM-Keys cadence) whose per-M365-tenant DKIM-pass-then-DMARC- aligned-DKIM-pass verdict is the LOAD- BEARING upstream cryptographic- authentication primitive every M365-hosted brand's BIMI inbox-list rendering at Gmail / Yahoo / Apple Mail / Fastmail depends on. The BIMI-VS-M365-DKIM cross-reference establishes FOUR structurally-distinct per-M365-tenant per-domain BIMI-rendering coupling dimensions: (i) BIMI- display eligibility at every BIMI- supporting receiver is GATED on a per- message DMARC-aligned-DKIM-pass verdict for the per-M365-tenant per-custom-domain From-header identity — the BIMI Tiny PS SVG file at default._bimi.<d> renders ONLY when the per-M365-tenant per-custom- domain DKIM verification produces a per- message DKIM-pass aligned with the From- header organisational domain; the DKIM- for-M365 spoke documents the per-tenant Exchange-Admin-Center DKIM-Enable deployment workflow whose per-tenant per- custom-domain DKIM-pass output is the load-bearing upstream BIMI-eligibility prerequisite; (ii) M365-hosted brands targeting BIMI display eligibility on Gmail (the load-bearing receiver-side BIMI evaluator for M365-hosted publishers) must complete the per-M365-tenant per- custom-domain DKIM-signing deployment BEFORE publishing the BIMI Tiny PS SVG + VMC certificate references — publishing the per-publisher default._bimi.<d> record without an active per-M365-tenant DKIM- signing posture produces a 100% BIMI- ineligible per-message render decision at Gmail; the DKIM-for-M365 spoke documents the canonical per-tenant deployment ordering (Exchange Admin Center DKIM- Enable → per-selector1 + per-selector2 CNAME publication → DNS-propagation wait → per-tenant DMARC ramp to p=quarantine; pct=100 or p=reject; pct=100 → BIMI SVG + VMC publication); (iii) per-M365-tenant per-custom-domain DKIM-key-rotation cadence (the dual- selector1 / selector2 rotation pattern Microsoft pre-publishes) and per- publisher BIMI VMC renewal cadence share the per-M365-tenant per-domain operational discipline of DNS- propagation-aware overlap windows during rotation events — both require per-M365-tenant per-custom-domain scheduled rotation with the per-tenant Exchange-Admin-Center + per-tenant authoritative-DNS-zone-editor commit cadence; the DKIM-for-M365 spoke documents the per-M365-tenant per- custom-domain Rotate-DKIM-Keys operational discipline that transfers directly to per-tenant per-domain BIMI VMC renewal cadence; (iv) per- M365-tenant per-custom-domain DKIM- Enable activation in the Exchange Admin Center is the canonical per-tenant cryptographic-publication prerequisite without which the per-M365-tenant per- custom-domain BIMI rendering at Gmail returns FALSE — the per-tenant DKIM-Enable toggle is the load-bearing per-M365-tenant cryptographic- authentication-publication primitive every per-tenant BIMI Tiny PS SVG file the M365-hosted brand publishes depends on for receiver-side render eligibility. Read this BIMI protocol pillar when DEPLOYING the per-publisher per-domain brand-indicator inbox-list rendering posture; read the DKIM-for-M365 spoke when DEPLOYING the upstream per-M365- tenant per-custom-domain DKIM-signing posture whose per-message DKIM-pass verdict is the load-bearing cryptographic-authentication primitive gating the per-receiver BIMI display eligibility this page's protocol contract documents.
• DMARC aggregate (RUA) reports — the PER-PUBLISHER-PER-DOMAIN-DMARC- RUA-XML-SCHEMA-AS-LOAD-BEARING-BIMI- ELIGIBILITY-VERIFICATION-EVIDENCE-STREAM companion to this BIMI-explained reference. Where THIS page documents the per-publisher per-domain BIMI protocol contract (DNS- published default._bimi.<domain> TXT record carrying v=BIMI1; l=<svg-uri>; a=<vmc-uri>; whose per-publisher per- domain DMARC p=quarantine-or-p=reject publication is the load-bearing per- publisher per-domain DMARC-alignment- posture-readiness prerequisite for per- receiver BIMI display-eligibility), the DMARC-aggregate-RUA-reports spoke is the per-publisher per-domain operational- evidence stream BIMI publishers consult at FOUR per-publisher per-domain BIMI- observability coordination dimensions: (i) per-publisher per-domain BIMI eligibility verification cycle prerequisite per-publisher per-domain DMARC RUA aggregate-report per-source-IP per- alignment-outcome survey discipline — per-publisher operators committing per- publisher per-domain BIMI publication MUST first verify per-publisher per-domain DMARC p=quarantine-or-p=reject alignment-posture- readiness via per-publisher per-domain DMARC RUA aggregate-report survey (per- publisher per-domain per-source-IP per- author-domain per-alignment-outcome row stream analysis) because per-publisher per-domain DMARC alignment-failure rates directly translate to per-receiver per- message BIMI display-eligibility-rejection rates — the per-publisher per-domain DMARC RUA aggregate-report stream IS the canonical per-publisher per-domain BIMI- eligibility-verification evidence stream; (ii) per-publisher per-domain DMARC RUA aggregate-report per-receiver per-source-IP per-alignment-outcome row stream coordinated with per-publisher per-domain BIMI per-receiver per-message display-eligibility verdict observability — per-publisher per-domain BIMI operators monitor per-publisher per-domain per-receiver per-source-IP per-alignment- outcome row trends in the per-publisher per-domain DMARC RUA aggregate-report stream to detect per-publisher per- domain per-tenant-SaaS-platform per- source-IP authentication drift BEFORE the drift cascades into per-receiver per- message BIMI display-eligibility- rejection events at the per-publisher per-domain BIMI-deployment-deliverability boundary; (iii) per-publisher per-domain DMARC RUA aggregate-report per-receiver per-policy_published-tag survey discipline as per-publisher per- domain BIMI-eligibility-precondition publication discipline-floor verification — per-publisher per-domain BIMI operators audit per-publisher per-domain DMARC RUA aggregate-report's per-receiver policy_published element values (per- publisher per-domain p= / sp= / pct= / adkim= / aspf= / fo= per-receiver-side interpretation evidence) to confirm per- publisher per-domain DMARC publication discipline-floor matches per-publisher per-domain BIMI publication precondition publication discipline-floor at the per- receiver per-message DNS-resolution evaluation boundary; (iv) per- publisher per-domain DMARC RUA aggregate- report per-source-IP per-author-domain per-alignment-outcome row stream coordinated with per-publisher per-domain BIMI publication rollback discipline — when per-publisher per-domain operators detect per-publisher per-domain deliverability KPI degradation OR per- publisher per-domain BIMI display- eligibility-rejection rate spike post per- publisher per-domain BIMI publication commitment, the per-publisher per-domain rollback discipline applies BOTH to the per-publisher per-domain BIMI publication (downshift v=BIMI1 publication scope or downshift a=<vmc-uri> commitment) AND verifies per-publisher per-domain DMARC RUA aggregate-report per-source-IP per- alignment-outcome row stream stability — the per-publisher per-domain DMARC RUA aggregate-report stream is the per- publisher per-domain operational cross- reference per-publisher per-domain operators consult during per-publisher per-domain BIMI rollback coordination. Read the DMARC-aggregate-RUA-reports spoke alongside this BIMI-explained reference when AUTHORING per-publisher per-domain BIMI eligibility-verification runbooks that integrate per-publisher per-domain DMARC RUA aggregate-report per-source-IP per-alignment-outcome survey discipline, when AUDITING per- publisher per-domain DMARC alignment- posture BEFORE committing to per- publisher per-domain BIMI publication, when EXECUTING per-publisher per-domain per-receiver BIMI display-eligibility- rejection trend analysis cross-referenced with per-publisher per-domain DMARC RUA aggregate-report per-source-IP per- author-domain per-alignment-outcome row evidence, or when ESTABLISHING per- publisher per-domain joint per-receiver- side BIMI-display-eligibility-and-DMARC- RUA-evidence coordination discipline- floor.
• IETF draft-brand-indicators-for-message-identification — the BIMI specification itself. Still an Internet Draft, not yet a published RFC.
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — the DMARC specification BIMI depends on.
• BIMI Group (Authindicators Working Group) — the industry consortium publishing the SVG Tiny PS profile and the operational interoperability rules.
• TLS-RPT explained — the canonical protocol-layer TLS-RPT reference whose per-receiver per-publisher per-day aggregate JSON evidence stream is the load- bearing per-message DKIM-Signature header in-transit integrity- observability prerequisite the BIMI brand-indicator rendering pipeline THIS page documents depends on at four TLS-RPT-to-BIMI-rendering- pipeline resolution dimensions: (i) the per-receiver per-source-IP per-day TLS- handshake success-rate aggregate is the canonical load-bearing per-egress-path transport- confidentiality input into the per-message DKIM-Signature header in-transit-integrity gate that BIMI's per-message DKIM-aligned-pass-pre-rendering check depends on — per-source-IP TLS-handshake failures the TLS- RPT JSON-aggregate stream catalogues degrade the per- message DKIM-aligned-pass rate the BIMI rendering gate consumes; (ii) the per-receiver per-publisher certificate-host-mismatch / certificate-expired / certificate-not-trusted failure-type aggregate is the canonical load-bearing per- egress-path TLS-trust-chain- breakage attribution input the BIMI VMC trademark-binding verification depends on — receivers verify the BIMI VMC x.509 trust-chain over TLS- secured DNS-over-TLS or HTTPS-fetch transport, and per-receiver TLS-trust-chain breakage rows in the TLS-RPT aggregate stream are the canonical early-warning signal the publisher consumes; (iii) the per-receiver per-publisher MTA-STS-policy-fetch-outcome aggregate is the canonical load-bearing per-publisher per-receiver MTA-STS-policy- coverage input the BIMI per-receiver brand-indicator- cache-warming workflow depends on — Gmail / Yahoo / Apple Mail / Fastmail BIMI-receiver rendering caches are warmed only after the per-publisher per-receiver MTA-STS-policy- validated TLS-handshake success-rate threshold is met, which the TLS-RPT aggregate stream's MTA-STS-policy-fetch sub-block IS the canonical publisher-side observability feed for; and (iv) the per- publisher per-egress-shard per-TLS-handshake DANE TLSA- record-fetch-outcome aggregate is the canonical load-bearing per-egress-shard transport-confidentiality verification input into the per-message DKIM-Signature header in-transit-integrity gate that BIMI's per-message DKIM-aligned-pass-pre- rendering check consumes — DANE-validated TLS-handshakes carry per-publisher per- egress-shard cryptographic identity-binding the TLS-RPT per-failure-type JSON-row catalogue IS the canonical publisher-side per-receiver observability feed for. Read the TLS-RPT spoke ALONGSIDE this BIMI brand-indicator rendering reference whenever the publisher scopes a per- publisher per-egress-shard TLS-transit-observability coordination plan — the per- receiver per-publisher per-day RFC 8460 JSON- aggregate stream THIS TLS-RPT reference documents the per- receiver emission discipline of IS the canonical load- bearing publisher-side transport-layer integrity- observability prerequisite the BIMI rendering pipeline THIS page's per-message DKIM-Signature header in-transit-integrity evaluation step structurally depends on.
• MTA-STS vs DANE for SMTP — the PER-EGRESS-PATH-TLS- ENFORCEMENT-PROTOCOL-CHOICE decision-matrix companion to this BIMI brand-indicator rendering reference. Where THIS page documents the BIMI byte- level protocol (the default._bimi.<d-domain> TXT record grammar, the v=BIMI1 version- prefix, the per-receiver- organisation brand-indicator rendering decision), the mta_sts _vs_dane spoke documents the RFC-8461-vs-RFC-7672 trust- anchor split that the per- publisher per-egress-shard TLS- encrypted SMTP path THIS page's per-message DKIM-Signature header in-transit-integrity gate structurally depends on resolves to. The PER-BIMI-RENDERING- PIPELINE-VS-TRANSPORT-SECURITY- PROTOCOL-CHOICE-COUPLING cross- reference establishes FOUR structurally-distinct per- protocol-choice-to-BIMI- rendering coupling dimensions: (i) per-publisher _mta-sts.<d-domain> TXT-record + HTTPS-PKI-fetched mta-sts.<d-domain>/.well-known/mta-sts.txt policy-file publication AS RFC- 8461-CANONICAL-TLS-ENFORCEMENT- PROTOCOL-CHOICE that the per- receiver-organisation BIMI- rendering cache-warming workflow structurally consumes — the BIMI rendering pipeline at every BIMI-supporting receiver (Gmail / Yahoo / Apple Mail / Fastmail) gates per-publisher brand-indicator cache-warming on the per-publisher per-receiver MTA-STS-policy-validated TLS- handshake success-rate threshold; the mta_sts_vs_dane spoke documents the RFC 8461 §3.2 policy-file syntax (the version: STSv1 version-prefix, the mode: enforce terminal-state, the mx: mail-flow- authorization invariants, the max_age: policy- rotation-cadence discipline) whose per-publisher publication IS the canonical load-bearing TLS-enforcement-protocol-choice input the per-receiver- organisation BIMI-rendering cache-warming workflow this page documents consumes; (ii) per-publisher per-mail- exchanger _25._tcp.<mx- hostname> DNSSEC- anchored TLSA-record publication AS RFC-7672-CANONICAL-TLS- ENFORCEMENT-PROTOCOL-CHOICE that the per-publisher per-egress- shard cryptographic-identity- binding for per-message DKIM- Signature in-transit-integrity depends on — DANE- validated TLS-handshakes carry per-publisher per-egress-shard cryptographic identity-binding the per-message DKIM-Signature header in-transit-integrity gate BIMI's per-message DKIM-aligned- pass-pre-rendering check consumes; the mta_sts_vs_dane spoke documents the RFC 7672 §3.1 TLSA owner-name convention, the four-field TLSA-record format (usage / selector / matching-type / certificate- association-data), the canonical DANE-EE (usage=3) + SPKI- selector (selector=1) + SHA-256-matching (matching- type=1) deployment shape, and the end-to-end DNSSEC chain-of- trust requirement whose per- publisher publication IS the canonical DANE-side TLS- enforcement-protocol-choice input; (iii) per- publisher per-egress-shard coexistent MTA-STS + DANE publication AS RFC-7672-§1.3- COEXISTENCE-RULE-COMPLIANCE- STATE that maximises BIMI rendering coverage across both RFC-8461-aware and RFC-7672- aware receivers — the mta_sts_vs_dane spoke documents the RFC 7672 §1.3 coexistence rule (DANE-aware senders prefer TLSA when both are published; MTA-STS-only senders fall back to the HTTPS-PKI policy file); per-publisher coexistent publication maximises the canonical BIMI-rendering cache- warming coverage matrix across the receiver population THIS page's BIMI-supporting-receiver list catalogues; (iv) per-publisher per- protocol-choice transport-layer- observability data-stream coordination via TLS-RPT (RFC 8460) AS LOAD-BEARING-PUBLISHER- SIDE-OBSERVABILITY-FEEDBACK-LOOP the BIMI rendering pipeline depends on — both MTA- STS and DANE deployments emit per-receiver per-publisher per- day RFC 8460 JSON-aggregate TLS- handshake-evidence rows diagnosing the per-publisher per-egress-shard TLS-trust-chain integrity the BIMI VMC trademark- binding verification consumes; the mta_sts_vs_dane spoke documents the protocol-choice- specific TLS-RPT failure-type catalogue (sts-policy- invalid for MTA-STS, certificate-not-trusted for DANE-EE TLSA mismatch) whose per-publisher consumption IS the load-bearing TLS-enforcement- protocol-choice-specific observability-feedback-loop input the BIMI rendering pipeline's brand-indicator cache-warming workflow structurally depends on. Read the mta_sts_vs_dane spoke ALONGSIDE this BIMI brand- indicator rendering reference whenever the publisher scopes a per-publisher per-egress-shard TLS-enforcement-protocol-choice deployment plan — the RFC-8461- vs-RFC-7672 decision-matrix THIS comparison spoke documents IS the canonical load-bearing TLS- enforcement-protocol-choice input the BIMI rendering pipeline THIS page's per-message DKIM-Signature header in- transit-integrity evaluation step structurally depends on.
• DANE TLSA explained (RFC 7672) — the PER-PUBLISHER-DANE-EE-TLSA-PINNING- AS-UPSTREAM-PREREQUISITE-FOR-PER-PUBLISHER- BIMI-RENDERING-PIPELINE companion to this BIMI rendering pillar reference. Where THIS page documents the BIMI rendering pipeline (the per-publisher BIMI-record publication, the per-receiver per-message DMARC-aligned-pass + BIMI-VMC-fetch cascade, the per-receiver-mailbox-provider SVG-Tiny mark-render decision), the DANE- TLSA-explained spoke is the RFC 7672 per- publisher per-MX-host DNSSEC-anchored transport-confidentiality reference whose per-publisher per-MX-host TLSA-RR publication-discipline is the LOAD-BEARING UPSTREAM transport-confidentiality primitive the per-publisher BIMI rendering-pipeline structurally depends on at multiple per-receiver-fetch-and- validate boundaries. The PER-PUBLISHER- DANE-TLSA-VS-PER-PUBLISHER-BIMI-RENDERING- PIPELINE cross-reference establishes FOUR structurally-distinct dimensions: (i) per-publisher per-MX-host DANE-EE- TLSA-RR DNSSEC-anchored TLS-handshake- success-rate AS LOAD-BEARING per-message DKIM-Signature byte-fidelity preservation primitive upstream of per-receiver BIMI- render-decision — every per-message delivered to a per-receiver-mailbox- provider via DANE-validated TLS handshake preserves the byte-exact DKIM-Signature header the per-receiver BIMI-renderer verifies during BIMI-render-decision cascade — the per-publisher per-MX-host DANE-EE-TLSA-pinning anti- downgrade enforcement is the per-message DKIM-Signature byte-fidelity preservation primitive the per-receiver BIMI-render- decision cascade depends on at the per- message DKIM-aligned-pass evaluation step THIS page documents the rendering-pipeline consumption of; (ii) per-receiver- BIMI-renderer per-publisher BIMI-VMC-fetch HTTPS-fetch transport-confidentiality AS STRUCTURAL PARALLEL TO per-receiver-MTA per-publisher MX-host SMTP-handshake transport-confidentiality — both per- publisher-published fetch-targets are Web-PKI-trust-chain-validated HTTPS-fetch targets where DANE provides DNSSEC-anchored trust-anchor strengthening — the per-publisher VMC-fetch leg + the per-publisher MX-handshake leg both benefit from per-publisher DANE-TLSA-RR DNSSEC-anchored trust-anchor publication; the DANE-TLSA-explained spoke documents the per-publisher per-MX-host TLSA-RR publication-discipline whose downstream consumer is BOTH the per-receiver-MTA MX-handshake AND structurally parallels the per-receiver-BIMI-renderer VMC-fetch trust-anchor model THIS page documents the BIMI rendering pipeline of; (iii) per-publisher DANE-TLSA-RR rollover-cadence + per-publisher BIMI-VMC renewal-cadence operational coordination — per-publisher operations team coordinates per-MX-host TLSA-RR rollover with per- publisher VMC renewal cadence to avoid per-receiver-MTA cache-window-bounded delivery degradation AND per-receiver- BIMI-renderer cache-window-bounded mark- suppression — both per-publisher rotation-cadence operational disciplines share the per-publisher Web-PKI trust- anchor lifecycle management requirement; the DANE-TLSA-explained spoke documents the per-publisher per-MX-host TLSA-RR rollover discipline whose operational- coordination requirement parallels the per-publisher BIMI-VMC renewal-cadence coordination THIS page documents the BIMI rendering pipeline operational dependency on; (iv) per-publisher DANE-TLSA- validated TLS-handshake-success-rate observability in TLS-RPT JSON-aggregate AS LOAD-BEARING per-publisher BIMI- deployment-quality observability primitive — the per-publisher per-receiver per-day DANE-validated TLS-handshake-success-rate observable in TLS-RPT JSON-aggregate is the per-publisher BIMI-deployment- operational-quality root-cause attribution primitive feeding the per-publisher BIMI- render-rate evidence stream — a per-publisher per-day DANE-TLSA-validated TLS-handshake-success-rate decline detected via TLS-RPT JSON-aggregate is the canonical per-publisher BIMI-render-rate degradation upstream root-cause attribution evidence; the DANE-TLSA-explained spoke documents the per-publisher per-MX-host TLSA-RR publication-discipline whose per-publisher per-receiver per-day TLS-handshake-success- rate observability IS the per-publisher BIMI-deployment-quality observability upstream input THIS page documents the BIMI rendering-pipeline downstream observability output of. Read the DANE- TLSA-explained spoke alongside this BIMI rendering pillar reference whenever the operator scopes a per-publisher BIMI- deployment-AND-transport-confidentiality coordination plan — the per-publisher per- MX-host DANE-EE-TLSA-RR DNSSEC-anchored certificate-pinning IS the canonical UPSTREAM per-publisher transport- confidentiality primitive the per-publisher BIMI rendering-pipeline at multiple per- receiver-fetch-and-validate boundaries depends on for per-publisher mark-rendering operational integrity.
• Email authentication glossary — the PER-BIMI-PROTOCOL-PRIMITIVE- JARGON-CATALOGUE-AS-LOAD-BEARING-CROSS- PROTOCOL-REFERENCE-OF-STANDARDISED- TERMINOLOGY companion to this BIMI rendering-pillar reference. Where THIS page documents the BIMI rendering- pipeline mechanics — the per-publisher default._bimi.<domain> TXT record with v=BIMI1, l= logo URL, a= VMC URL tag-triplet, the SVG Tiny PS profile constraints (baseProfile= "tiny-ps", square aspect-ratio, ≤32 KB, transparent background, no scripts / animations / external references), the VMC / CMC PKI certificate-class distinction, the per-receiver Gmail / Yahoo / Apple Mail BIMI-display-eligibility rules, and the DMARC-at-enforce prerequisite the BIMI-draft §5 codifies — the email- authentication glossary spoke is the LOAD-BEARING cross-protocol reference catalogue of standardised terminology that every per-BIMI-protocol-primitive reader needs alongside this BIMI rendering-pipeline walk-through at FOUR per-BIMI-tag-and-cert-profile-vs- glossary-definition coupling dimensions: (i) per-BIMI-tag jargon (v=BIMI1 protocol-version, l= logo-location URL, a= authority-evidence URL, mti= Mark Type Indicator, the implicit BIMI selector defaulting to default._bimi) is structurally-catalogued in the glossary's per-BIMI-tag entry-set — the glossary spoke documents the canonical per-BIMI-tag definition for every byte- level default._bimi TXT- record field THIS page documents at the per-publisher BIMI publication boundary, so a reader stepping through the per- publisher TXT-record-authoring walk- through THIS page documents has a single cross-cluster definition catalogue to consult when the per-BIMI-tag jargon surfaces at the per-receiver verdict- consumption boundary without context- switching away from the rendering- pipeline mechanics; (ii) per- BIMI-cert-profile jargon (VMC Verified Mark Certificate, CMC Common Mark Certificate, SVG Tiny PS profile, the trademark-registration discipline, the DigiCert / Entrust authorised-CA issuance pipeline) is structurally- catalogued in the glossary's per-BIMI- cert-profile entry-set — the glossary spoke documents the canonical per-BIMI-cert-profile definition for every byte-level VMC .pem certificate-chain field whose RFC 5280 X.509-extension-set is structurally instantiated per the BIMI-draft §6 Logotype extension (RFC 3709), so a reader stepping through the per- publisher VMC procurement walk-through THIS page documents has a single catalogue to consult when the per-VMC- extension jargon surfaces at the per- receiver certificate-validation boundary; (iii) per-DMARC-prerequisite jargon (p=quarantine with pct=100, p=reject , sp= subdomain- policy coordination, adkim= / aspf= alignment-mode, the organisational-domain definition via PSL) is structurally-catalogued in the glossary's per-DMARC-tag entry- set — the glossary spoke documents the canonical per-DMARC-tag definition for every byte-level _dmarc.<domain> TXT- record field whose per-publisher publication discipline is the LOAD- BEARING BIMI-eligibility precondition THIS page documents, so a reader stepping through the per-publisher DMARC ramp-state pre-BIMI walk-through THIS page documents has a single catalogue to consult when the per-DMARC-tag jargon surfaces at the per-receiver BIMI-eligibility-gate consumption boundary; and (iv) per- authentication-standards-set jargon (the eight-standards corpus of DMARC / SPF / DKIM / BIMI / MTA-STS / TLS-RPT / ARC / CAA whose structural inter- relationships position BIMI as the downstream-consumer of the DMARC-aligned- pass evaluation that depends on the upstream SPF / DKIM / ARC verdict- preservation discipline) is structurally- catalogued in the glossary's per- standard entry-set — the glossary spoke documents the canonical per-standard definition for every email- authentication standard the BIMI rendering-pipeline THIS page documents depends on as an upstream operational- readiness prerequisite, so a reader stepping through the per-publisher cross-protocol BIMI-readiness audit walk-through THIS page documents has a single cross-cluster catalogue to consult when the per-standard jargon surfaces at the per-publisher cross- protocol-readiness audit boundary.
• DKIM-Signature header tag anatomy — the per-message DKIM-Signature header per-tag anatomy as load-bearing per- message authentication-primitive whose per-message d=-tag DMARC- alignment evaluation is the upstream authentication-precondition of the per- receiver BIMI-logo-display gate companion to this BIMI protocol-pillar rendering-pipeline reference. Where THIS page documents the per-publisher per-domain BIMI rendering pipeline (publication of _bimi.<domain> TXT-RR with v=BIMI1; l=<SVG-URL>; a=<VMC-URL>, the per-VMC SVG-Tiny- PS logo binding, the Mark Verifying Authority X.509 trust-chain, the per- receiver BIMI-display gate at Yahoo / Gmail / Apple Mail / Fastmail), the DKIM-Signature-anatomy spoke documents the per-message header byte-grammar whose per-tag publication discipline is the LOAD-BEARING upstream per-message cryptographic-authentication primitive every per-receiver per-message BIMI- logo-display-gate STRUCTURALLY DEPENDS on for the SVG asset fetch + render verdict. Four DKIM-SIGNATURE-HEADER- ANATOMY-VS-BIMI-RENDERING-PIPELINE cross-correlation axes the signature- anatomy spoke documents: (i) per- message DKIM-Signature d=<domain> tag value STRUCTURALLY DETERMINES the per-message DKIM-leg DMARC-aligned-pass evaluation whose verdict the per-receiver BIMI- display gate consumes — the per- message d= tag value MUST match the per-message From: header organizational domain under adkim=r for the per-message DKIM-leg DMARC-aligned-pass verdict to emit; the per-receiver per-message BIMI display evaluator at Yahoo / Gmail / Apple Mail / Fastmail consumes the per- message DMARC-aligned-pass DMARC verdict as the LOAD-BEARING upstream per-message authentication precondition for SVG- asset fetch + render; (ii) per- message DKIM-Signature s=<selector> selector tag publication discipline STRUCTURALLY GATES per-receiver BIMI-logo-display rate — a per-publisher per-selector public- key TXT-RR publication regression at <selector>._domainkey.<d-value> produces per-receiver dkim=permerror verdicts that collapse the per-domain DKIM-aligned-pass coverage rate AND the per-receiver BIMI- logo-display rate at every BIMI-aware mailbox provider; (iii) per- message DKIM-Signature bh= body-hash tag computation discipline STRUCTURALLY GATES per-receiver BIMI-display continuity across intermediary forwarders — per-message body- hash mismatch under c=simple canonicalization mode (caused by per- intermediary footer-injection or per- line-ending normalization) produces per- message dkim=fail verdicts that disengage the per-receiver BIMI- display gate even when the per-publisher per-domain BIMI VMC is current and the per-receiver supports BIMI rendering; (iv) per-message DKIM-Signature a=<algorithm> algorithm tag value STRUCTURALLY GATES per-receiver BIMI-display continuity at per-receiver Ed25519-aware-vs-RSA-only verifier boundary — the per-message a= tag identifies the per- message signature algorithm; per-publisher per-domain dual-algorithm signing posture (RSA-2048 + Ed25519 per RFC 8463) is the LOAD-BEARING per-publisher per-domain cryptographic-authentication-algorithm posture every BIMI-VMC-ready deployment requires to preserve the per-receiver BIMI-display rate at Apple Mail / Fastmail / Yahoo / Gmail simultaneously across the per-receiver verifier-algorithm coverage divergence. Read THIS page when SHIPPING the per-publisher per-domain BIMI rendering pipeline; read the DKIM- Signature-anatomy spoke when AUDITING the per-message header byte-grammar per-tag publication discipline whose d= tag value, s= selector publication, bh= body-hash computation, and a= algorithm choice are the LOAD-BEARING upstream per-message cryptographic-authentication primitives every per-receiver per-message BIMI-logo- display-gate STRUCTURALLY DEPENDS on as the per-message DMARC-aligned-pass DMARC verdict the BIMI display evaluator consumes.
• SPF mechanism-choice decision matrix
• DMARC monitoring
• DMARC forensic reports
• MTA-STS for Microsoft 365 — the PER-M365-TENANT-PER-CUSTOM- DOMAIN-MTA-STS-TRANSPORT-LAYER-INTEGRITY- AS-LOAD-BEARING-INBOUND-PIPELINE-PRECONDITION- FOR-PER-RECIPIENT-BIMI-INDICATOR-RENDERING companion to this BIMI deep-dive reference. Where THIS page documents the per-publisher per-domain BIMI logo-display deployment chain (per-publisher per-domain BIMI Indicator-record v=BIMI1; l=<svg-url>; a=<vmc-url> publication, per-publisher per-VMC certificate-issuance Brand-Indicator- eligibility audit, per-recipient per- message brand-indicator-rendering cascade), the M365 MTA-STS spoke is the PER-M365- TENANT TRANSPORT-LAYER INTEGRITY reference gating whether the per-recipient inbound pipeline preserves the per-message DKIM-Signature + envelope integrity the downstream BIMI brand-indicator-rendering evaluator depends on. Four per-M365- recipient-tenant MTA-STS-vs-BIMI-rendering coordination dimensions: (i) PER-M365- TENANT-MTA-STS-ENFORCE-MODE-AS-LOAD-BEARING- INBOUND-STARTTLS-INTEGRITY (per-M365-tenant mode: enforce publication guarantees the inbound BIMI-publishing sender’s outbound DKIM-Signature survives unmodified through a STARTTLS- encrypted handshake — STARTTLS downgrade attacks against the inbound pipeline would otherwise enable per-message DKIM-Signature mutation breaking per- recipient BIMI-eligibility); (ii) PER-M365- TENANT-MTA-STS-POLICY-FETCH-FAILURE-VS- PER-RECIPIENT-BIMI-ELIGIBILITY-LOSS (per- M365-tenant MTA-STS HTTPS-served-policy cert-chain failure cascades to opportunistic- STARTTLS or hard-bounce — either outcome degrades per-recipient inbound BIMI- publishing sender’s per-message delivery, dropping per-recipient BIMI- indicator-rendering opportunity altogether); (iii) PER-M365-TENANT-MTA-STS-MX-ALLOW-LIST- VS-BIMI-PUBLISHING-SENDER-EGRESS-IP-POOL (per-M365-tenant mx:-directive list authorisation determines which BIMI- publishing sender egress IP pools can successfully deliver inbound mail to the M365 recipient — misconfigured allow- lists silently drop per-publisher inbound BIMI-publishing mail that would otherwise render with brand-indicator); (iv) PER-M365- TENANT-MTA-STS-TLS-RPT-OBSERVABILITY-VS- PER-RECIPIENT-BIMI-RENDERING-DEGRADATION (per-M365-tenant TLS-RPT JSON sts-policy-fetch-error result- type rows IS structurally parallel evidence stream to per-publisher per-domain DMARC RUA aggregate-report rows the BIMI evaluator consumes — cross-correlation identifies per-recipient BIMI-rendering degradation correlating with per-M365- recipient-tenant MTA-STS publication breakage). Read the M365 MTA-STS spoke alongside this BIMI deep-dive guide when AUDITING per-recipient-population BIMI- indicator-rendering coverage across M365- recipient-tenant inbound pipelines, when INVESTIGATING per-publisher per-domain BIMI-publishing campaign rendering coverage drops correlating with M365- recipient-tenant TLS-RPT breakage, or when PLANNING the per-recipient-population composite cross-layer DMARC-aligned-pass- rate-floor + transport-layer-integrity- floor coordination discipline the per- recipient BIMI-rendering eligibility cascade depends on.
• DMARC identifier-alignment
• DKIM key rotation
• DMARC records explained
• DMARC for cPanel hosting — the PER-CPANEL-TENANT-PER-CUSTOM-DOMAIN-DMARC-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-PER-TENANT-PER-CUSTOM-DOMAIN-AUTHENTICATION-POLICY-PUBLICATION-PRECONDITION-OF-PER-CPANEL-TENANT-PER-CUSTOM-DOMAIN-BIMI-INDICATOR-RENDERING-ELIGIBILITY-CASCADE companion at four cPanel-shared-hosting-DMARC-deployment-vs-BIMI-indicator-rendering-eligibility coupling dimensions: (1) per-cPanel-tenant per-custom-domain DMARC p=quarantine / p=reject enforcement-mode publication-decision IS the per-tenant per-custom-domain application-layer authentication-policy publication-prerequisite for BIMI Indicator-record brand-indicator-rendering eligibility per BIMI RFC 9716 §4.1 every per-cPanel-tenant per-custom-domain seeking per-recipient per-message brand-indicator-rendering must satisfy; (2) per-cPanel-tenant per-custom-domain DKIM-aligned-pass-rate floor preservation across shared-IP-pool egress IS the per-tenant per-custom-domain BIMI-eligibility-prerequisite DMARC-aligned-pass-rate floor preservation precondition — per-cPanel-tenant per-custom-domain shared-MX-cluster cross-tenant verdict-noise must not collapse the per-tenant identity-attribution leg the per-cPanel hosting page documents per-tenant DKIM publication discipline for; (3) per-cPanel-tenant per-custom-domain DMARC rua=mailto: aggregate-report-URI publication per RFC 7489 §6.2 surfaces per-tenant per-custom-domain per-day per-receiver per-source-IP per-row attribution stream which IS the per-tenant per-custom-domain operator-actionable evidence channel through which BIMI-eligibility-prerequisite DMARC-aligned-pass-rate floor preservation surfaces and through which per-tenant per-custom-domain BIMI-readiness ramp progresses; (4) per-cPanel-tenant per-custom-domain BIMI Indicator-record publication at default._bimi.<custom-domain> IS structurally parallel to per-tenant per-custom-domain DMARC TXT-RR publication at _dmarc.<custom-domain> the per-cPanel hosting page documents per-tenant per-custom-domain publication discipline of — both per-tenant per-custom-domain DNS-TXT-RR publication-discipline references jointly underpin the per-cPanel-tenant per-custom-domain composite cross-protocol authentication-policy-and-brand-indicator publication-portfolio coordination underpinning per-recipient per-message brand-indicator-rendering eligibility.
• SPF qualifiers explained — the per-publisher per-domain SPF qualifier-prefix envelope-MAIL-FROM-layer publication-discipline companion at four per-publisher per-domain SPF-qualifier-prefix-vs-BIMI-eligibility coupling dimensions: (i) per-publisher per-domain SPF terminal-qualifier publication-decision -all strict-fail per RFC 7208 §4.6.2 IS the load-bearing envelope-MAIL-FROM-layer enforcement-floor publication-decision whose per-receiver per-message SPF-aligned-pass discipline feeds the per-publisher per-domain DMARC composite-aligned-pass-rate floor preservation underpinning the per-publisher per-domain BIMI Indicator-record brand-indicator-rendering eligibility cascade per BIMI RFC 9716 §4.1 enforcement-mode prerequisite; (ii) per-publisher per-domain SPF qualifier-prefix publication-decision (+/-/~/? per RFC 7208 §4.6.2) IS structurally parallel envelope-MAIL-FROM-layer authorization-discipline publication-decision matrix to per-publisher per-domain BIMI Indicator-record cryptographic-trust-anchor publication-decision matrix (per-publisher per-VMC Verified Mark Certificate cryptographic-trust-chain choice + per-publisher per-domain BIMI default-vs-selector-specific Indicator-record publication-decision) the BIMI deep-dive THIS page documents the per-publisher per-domain BIMI Indicator-record publication-discipline of materially depends on; (iii) per-publisher per-domain SPF terminal-qualifier ~all softfail vs -all hardfail publication-decision IS structurally parallel envelope-MAIL-FROM-layer enforcement-mode ramp-progression discipline to per-publisher per-domain DMARC p=none → p=quarantine → p=reject three-stage application-layer enforcement-mode ramp per RFC 7489 §6.3 whose terminal-stage gating per-publisher per-domain BIMI Indicator-record brand-indicator-rendering eligibility per BIMI RFC 9716 §4.1 enforcement-mode prerequisite cascade the BIMI deep-dive THIS page documents materially depends on; (iv) per-publisher per-domain SPF qualifier-prefix mechanism-class publication-decision discipline drift (premature -all hardfail cutover surfacing as per-source-IP per-day DMARC RUA policy_evaluated/spf=fail attribution-distortion + ~all-stuck publication-discipline drift surfacing as per-publisher per-domain SPF-aligned-pass-rate floor erosion) directly opens per-publisher per-domain DMARC composite-aligned-pass-rate floor regression that the per-publisher per-domain BIMI Indicator-record brand-indicator-rendering eligibility cascade THIS page documents the per-mailbox-provider per-recipient-tenant display-gate evaluation pipeline of structurally depends on for per-recipient per-message brand-indicator-rendering eligibility coverage floor preservation.
• SPF 10-DNS-lookup limit
• Email authentication ecosystem — the PER-PUBLISHER-PER-DOMAIN-BIMI- INDICATOR-RECORD-RENDERING-ELIGIBILITY- CASCADE-AS-DOWNSTREAM-BRAND-INDICATOR- RENDERING-ELIGIBILITY-LEG-OF-THE-CROSS- PROTOCOL-EMAIL-AUTHENTICATION-ECOSYSTEM companion to this BIMI Indicator-record publication-discipline reference. Where THIS page documents the per-publisher per-domain BIMI Indicator-record byte- grammar publication-discipline (v=BIMI1 version-tag + l= SVG-logo-URL + a= VMC-asset-URL per RFC 9716 §3) published at default._bimi.<domain> plus the per-publisher per-domain BIMI Indicator-record brand-indicator-rendering eligibility cascade per RFC 9716 §4.1 DMARC-enforcement-mode prerequisite, the email-authentication-ecosystem spoke is the CROSS-PROTOCOL OVERVIEW reference whose per-publisher per-domain SPF + DKIM + DMARC + ARC + BIMI publication-portfolio THIS BIMI Indicator-record byte-grammar page is the DOWNSTREAM brand-indicator- rendering-eligibility-leg of at FOUR per- publisher per-domain BIMI-publication- discipline-vs-cross-protocol-ecosystem coupling dimensions: (i) per- publisher per-domain BIMI Indicator-record brand-indicator-rendering eligibility per RFC 9716 §4.1 AS load-bearing downstream consumer of per-publisher per- domain DMARC enforcement-mode publication- decision — per-publisher per-domain DMARC p=quarantine or p=reject enforcement-tag publication IS the load-bearing upstream application-layer authentication-policy prerequisite gating BIMI Indicator-record brand-indicator-rendering eligibility; the email-authentication-ecosystem reference documents the cross-protocol enforcement- mode prerequisite cascade publication- portfolio of which THIS BIMI page is the downstream brand-indicator-rendering- eligibility-leg; (ii) per- publisher per-domain BIMI Indicator-record publication-cadence vs per-publisher per- domain DMARC enforcement-mode publication- cadence vs per-publisher per-domain composite SPF + DKIM authentication-leg- aligned-pass-rate-floor preservation cadence cross-protocol coordination — per-publisher per-domain BIMI publication-discipline cadence THIS page documents IS the load-bearing per- publisher per-domain operator-side cross- protocol publication-cadence-coordination downstream-leg whose per-publisher per- domain BIMI-eligibility readiness ramp depends on per-publisher per-domain DMARC enforcement-mode ramp + per-publisher per- domain SPF + DKIM authentication-leg- aligned-pass-rate-floor preservation cadence the email-authentication-ecosystem reference documents the cross-protocol publication-portfolio of; (iii) per-publisher per-domain BIMI Indicator- record VMC cryptographic-trust-chain publication-discipline AS load-bearing per-publisher per-domain brand-cryptographic- attribution downstream-leg of the cross- protocol authentication-ecosystem — per-publisher per-domain BIMI VMC (Verified Mark Certificate) cryptographic- trust-chain publication-discipline IS structurally parallel to per-publisher per-selector DKIM TXT-RR public-key publication-discipline + per-publisher per-domain DMARC enforcement-mode publication-discipline + per-publisher per-domain composite cross-protocol per- message authentication-leg-cryptographic- attribution discipline the email- authentication-ecosystem reference documents the cross-protocol publication- portfolio of; (iv) per-publisher per-domain BIMI Indicator-record DNS-TXT- RR publication AT default._bimi.<domain> vs per-publisher per-domain composite SPF apex-TXT-RR + DKIM <selector>._domainkey.<domain> TXT-RR + DMARC _dmarc.<domain> TXT-RR publication-portfolio structural parallel — all four per- publisher per-domain DNS-TXT-RR publication-discipline primitives jointly underpin the per-publisher per-domain composite cross-protocol authentication- and-brand-indicator-publication-portfolio coordination the email-authentication- ecosystem reference documents the cross- protocol publication-portfolio of. Read the email-authentication-ecosystem spoke WITH this BIMI Indicator-record publication-discipline reference when AUTHORING per-publisher per-domain composite cross-protocol authentication- and-brand-indicator publication-discipline portfolio at the per-publisher per-domain composite cross-protocol-email- authentication-ecosystem-and-BIMI- Indicator-record coordination boundary.
• ARC (Authenticated Received Chain) explained — the PER-PUBLISHER-PER-DOMAIN-ARC- CHAIN-OF-CUSTODY-AS-LOAD-BEARING-FORWARDER- SURVIVAL-PREREQUISITE-FOR-BIMI-INDICATOR- RENDERING-ELIGIBILITY companion at four per-publisher per-domain ARC-vs-BIMI- rendering-pipeline coupling dimensions: (i) per-receiver-side per-mailbox-provider BIMI Indicator-rendering eligibility per BIMI-Group draft §4.1 requires a per- message DMARC-aligned-pass verdict at the per-receiver per-message verdict-attribution boundary; per-publisher per-message DKIM cryptographic signatures are STRUCTURALLY INVALIDATED at forwarder body-rewrite boundaries (mailing-list footer injection, gateway content-rewriting) breaking the per-message DKIM-aligned-pass leg of the DMARC composite-verdict disjunction cascading into per-receiver-side BIMI Indicator-rendering INELIGIBILITY — ARC per RFC 8617 IS the cryptographic- chain-of-custody mechanism preserving the original-hop DKIM verdict across the forwarder boundary, restoring BIMI rendering eligibility at receivers that honour per-forwarder per-hop ARC chains (Gmail honours valid ARC chains from trusted ARC-signers; Microsoft EOP honours conditionally per ARC trust configuration); (ii) per-publisher per-domain BIMI Indicator publication-discipline (per-publisher per- domain BIMI TXT-RR at default._bimi.<domain> + SVG-asset HTTPS-fetch infrastructure + per-publisher per-domain VMC certificate chain THIS page documents the per-publisher per-domain publication-discipline of) IS per-publisher per-domain application-layer publication-discipline whose per-message BIMI rendering eligibility floor depends on per-forwarder per-hop ARC chain-of- custody preservation discipline that the ARC explained spoke documents the per- forwarder per-hop sealing protocol of; (iii) per-publisher per-domain BIMI Indicator publication-discipline + per- forwarder per-hop ARC-chain-of-custody preservation discipline JOINTLY underpin per-publisher per-domain composite per- receiver per-message BIMI-rendering- eligibility floor across forwarder- survival boundaries; (iv) per-publisher per-domain BIMI rendering eligibility regression (per-receiver-side per-mailbox- provider BIMI Indicator rendering INELIGIBILITY surfacing across forwarder-routed mail) traceable to per- forwarder per-hop ARC chain-of-custody breakage (per-forwarder ARC-Authentication- Results / ARC-Message-Signature / ARC-Seal missing or invalid) IS the per-publisher per-domain composite cross-protocol BIMI-rendering-eligibility-floor- preservation-discipline drift class the ARC explained spoke documents the per- forwarder per-hop diagnostic-and- remediation discipline of. Read the ARC explained spoke when AUTHORING per- publisher per-domain composite BIMI Indicator publication discipline coordinated with per-forwarder per-hop ARC chain-of- custody preservation discipline at the per-publisher per-domain composite cross- protocol BIMI-rendering-eligibility-and- forwarder-survival publication-discipline coordination boundary.
• DMARC troubleshooting — the diagnostic-prerequisite companion to this BIMI explainer. Where this page documents the BIMI rendering chain (the default._bimi.<domain> record, the l= SVG-asset and a= VMC references, and the enforcement-policy precondition that gates whether mailbox providers display the indicator), the DMARC-troubleshooting spoke documents the diagnostic path the operator follows when the indicator does not render because DMARC itself is failing: the per-source dkim=fail / spf=fail rows in the RUA aggregate stream that hold the composite verdict below the enforcement floor BIMI requires, the stalled p=none publication that never reaches the p=quarantine/p=reject BIMI prerequisite, and the alignment failures that keep the aligned-pass rate too low for a safe enforcement commitment. Read the DMARC-troubleshooting spoke when BIMI is correctly configured on this page but the indicator still does not appear — the root cause is almost always an underlying DMARC-fail the troubleshooting spoke triages from symptom back to the SPF, DKIM, or alignment defect suppressing it.
• Forwarding issues with SPF — the SRS / ARC / mailing-list / .forward catalogue of forwarder-induced SPF failures. BIMI logo display requires DMARC enforcement (p=quarantine or p=reject); unaddressed forwarder SPF breakage that DKIM does not compensate erodes the aligned-pass rate needed to ramp safely to the enforcement level BIMI depends on.
• DMARC for SaaS & platform senders — BIMI is the payoff at the end of that road. A SaaS sender only earns an inbox logo once its sending domain holds DMARC enforcement with a sustained aligned-pass, so the platform-sender deployment path this guide lays out is the prerequisite work before publishing a default._bimi record and a conformant logo. Read it when you are a platform sending on behalf of customers and want BIMI to light up.
• DMARC for Microsoft 365 — BIMI only lights up once the sending domain reaches p=quarantine or p=reject with a sustained aligned-pass, and for a Microsoft 365 / Exchange Online tenant that enforcement floor is reached by publishing the SPF include, the tenant DKIM signing, and the _dmarc policy this guide walks through. Read it to do the prerequisite authentication work on an M365 domain before publishing a default._bimi record.
• TLS-RPT record syntax — the PER-DOMAIN-UNDERSCORE-LABEL-TXT-RECORD-PUBLICATION-PARALLEL companion to this BIMI primer: the default._bimi.<domain> TXT-RR this page documents and the _smtp._tls.<domain> TXT-RR the TLS-RPT spoke documents are both strict-byte-grammar underscore-prefixed per-domain DNS-TXT records an operator publishes for the same domain — and the authenticated, DMARC-passing mail that earns the BIMI inbox logo rides the very STARTTLS transport hops the TLS-RPT record makes observable. Read the TLS-RPT-record-syntax spoke when rounding out a brand's DNS publication portfolio from the brand-indicator record into the transport-layer reporting record.
• DMARC deployment checklist — BIMI is the reward at the finish line of this checklist. The brand indicator only renders once the domain reaches p=quarantine or p=reject with a sustained aligned-pass, and the deployment checklist is the phased ramp — monitor at p=none, fix the failing SPF/DKIM legs, then tighten policy — that gets a domain to that enforcement floor safely. Read it for the step-by-step path you must complete before publishing a default._bimi record.
• Microsoft SNDS + JMRP monitoring — a BIMI logo only renders on mail that reaches the inbox: at Outlook.com/Hotmail that means a clean per-IP SNDS filter verdict and a low JMRP complaint rate before any logo work pays off.

13. Audit your BIMI setup now

DMARC Analyzer's free Domain Security Checker performs live BIMI record lookups, validates the published v=BIMI1 syntax, confirms the SVG and VMC URLs are reachable over HTTPS, and surfaces missing or expired VMC certificates. It also cross-checks the DMARC policy (p=quarantine or p=reject is required for BIMI eligibility) so you can spot the most common deployment-blocker before going live.

Check my BIMI record Sign up — Free plan