DMARC Analyzer

TL;DR

• 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. Required by Gmail, Apple Mail, Yahoo, AOL, and (gradually) Outlook before they display the BIMI logo.
• Two authorised CAs as of 2026: DigiCert and Entrust. Both issue under the CA/Browser Forum Mark Certificate profile (id-pe-logotype OID 1.3.6.1.5.5.7.1.12).
• VMC vs CMC: VMC requires a registered trademark; CMC accepts unregistered common-law marks proven in commerce for 12+ months. Gmail extended CMC support in 2024 for the blue checkmark, but the SVG-display path still requires a full VMC at most receivers.
• Accepted trademark registries: USPTO (US), EUIPO (EU), UKIPO (UK), JPO (Japan), IP Australia (AU), CIPO (Canada), plus a small set of additional regional registries on a per-CA basis.
• Issuance timeline: 3-6 weeks. Registry coordination is the long pole and is not under CA control. Plan VMC as a procurement task, not a same-day order.
• SVG-hash binding: the CA embeds SHA-256 of the canonicalised SVG bytes in the VMC (RFC 3709 LogotypeExtn). Any byte-level edit to the SVG breaks the binding and requires VMC re-issuance.
• Annual renewal: certificate lifetime is 12-13 months. Set calendar reminders 90 / 60 / 30 days before Not After. Expired VMCs silently suppress logo display.
• Cost: USD 1,000-3,000 per year typical range; trademark research is the dominant cost component.

1. What is a Verified Mark Certificate?

A Verified Mark Certificate (VMC) is an X.509 PKI certificate that cryptographically attests:

1. The publishing domain owns a registered trademark in one of the accepted jurisdictions.
2. The specific SVG file referenced in the BIMI record corresponds to that trademark (binding via SHA-256 hash of the canonicalised SVG bytes).
3. The Certificate Authority (DigiCert or Entrust) validated the trademark registration with the registry and validated domain control.

The certificate is issued under the CA/Browser Forum Mark Certificate Working Group profile, which extends the standard X.509 profile (RFC 5280) with the id-pe-logotype extension (RFC 3709 OID 1.3.6.1.5.5.7.1.12) and a Verified Mark extension carrying the trademark registration identifier and the registry jurisdiction.

Mailbox providers fetch the VMC from the URL in the BIMI record a= tag, validate the certificate chain against their trusted-root store (DigiCert and Entrust roots), confirm the SVG hash matches the hash in the VMC, and only then render the logo in the mailbox UI. The VMC is the authentication primitive that makes inline inbox-logo rendering trustworthy.

The VMC does not replace DMARC or DKIM — it is layered on top. A send must still pass DMARC alignment for the SVG to render; the VMC merely authenticates the relationship between trademark and logo so the receiver knows the logo is genuinely from the trademark holder. See BIMI explained for the end-to-end pipeline (DMARC → BIMI record → SVG → VMC → render).

2. VMC vs CMC (Common Mark Certificate)

The CA/Browser Forum Mark Certificate profile defines two certificate types differentiated by the underlying trademark evidence:

Pragmatic guidance: if the trademark is registered, get a VMC — the SVG-display path is the higher-value outcome and most receivers only enable it for VMCs. If the trademark is not registered and the brand needs to start the trademark process, consider whether the 6-12 month registry filing timeline plus the 3-6 week issuance timeline fits the deployment window. A CMC can be a stop-gap to get the Gmail blue checkmark while the trademark application is in flight; refresh to a VMC once the registration grants.

3. Authorised issuing CAs

As of 2026, the two production-issuing CAs approved by the BIMI Group are:

The two CAs issue under the same CA/Browser Forum profile and produce certificates that are interchangeable from the receiver's perspective. The receiver chains the leaf VMC to either the DigiCert or Entrust root certificate in its trust store; both roots are pre-trusted by Gmail, Apple Mail, Yahoo, AOL, and the other BIMI-enabled mailbox providers.

Certificates from other PKI CAs are not trusted for BIMI even if structurally identical and even if the issuing CA is publicly trusted for TLS. The BIMI Group maintains an explicit authorised-issuer list; only the BIMI Group-approved CAs are recognised by receivers.

Procurement guidance: the issuer choice is a vendor-relationship and pricing decision, not a technical decision. Both CAs offer multi-domain Subject Alternative Names support, multi-year pre-payment discounts, and consolidated billing with their TLS certificate products. If your organisation already has a vendor relationship with one of the two, that is usually the easiest procurement path. If both, request quotes from both and compare.

4. Accepted trademark registries

The BIMI Group profile accepts trademarks registered with the following national or regional IP offices:

WIPO international filings: the Madrid Protocol (WIPO international trademark filing system) is recognised through the underlying national registrations that it produces, not as a standalone validated identity. A WIPO filing that designates USPTO, EUIPO, etc. as designated offices counts as those national registrations once the national-phase examinations complete.

The trademark mark itself must be a figurative mark (a graphic mark including word + design, or design-only) — a word-only mark (text without a distinct visual treatment) cannot be the BIMI logo because there is no figurative element to render. Word-only marks that lack a visual brand can apply for the supplementary stylised version of the mark to satisfy the figurative-mark requirement.

5. End-to-end acquisition workflow

The end-to-end VMC acquisition workflow, in order:

1. Prerequisite: DMARC at p=quarantine or p=reject. The receiver-side BIMI evaluation is gated on DMARC enforcement; a VMC for a domain at p=none is wasted procurement. Confirm with Domain Security Checker before starting VMC procurement.
2. Prerequisite: SVG Tiny PS logo. Produce the final SVG file that conforms to the BIMI Group SVG Tiny PS profile — see BIMI SVG Tiny PS logo requirements for the byte-by-byte file-format reference. The CA hashes this exact file at issuance time; any post-issuance edit invalidates the VMC.
3. Prerequisite: registered trademark. Confirm the trademark is registered with one of the accepted registries (section 4 above) and that the registered mark IS the figurative element in the SVG. The trademark registration certificate is the primary evidence the CA validates.
4. Choose a CA: DigiCert or Entrust. Procurement decision based on existing vendor relationships, pricing, multi-year discount availability, and SAN (Subject Alternative Names) requirements.
5. Open the CA portal application: upload the SVG (the CA validates against the Tiny PS profile and computes the SHA-256 hash), upload the trademark registration certificate (PDF from the registry), list the publishing domain(s) for SAN coverage, provide legal entity details for the certificate Subject.
6. CA validates the trademark with the registry: this is the long-pole step (1-2 weeks typical) — the CA cross-checks the registration with the IP office to confirm it is current, in the applicant's name, and covers the figurative mark in the SVG. Registry coordination is not under the CA's control; this is the dominant timeline contributor.
7. CA validates domain control: DNS TXT challenge (a CA-supplied token published at _dnsauth.<domain> or similar) OR an HTTPS file-upload challenge (a CA-supplied token served at /.well-known/pki-validation/<file>). Same-day turnaround once the challenge is published.
8. CA validates the SVG: the SVG Tiny PS profile compliance check. If the SVG fails validation (e.g. baseProfile attribute missing, non-square viewBox, embedded raster, <script>), the CA reports the failure mode and the applicant re-uploads a corrected SVG. The SHA-256 hash is computed only after the SVG passes profile validation.
9. CA issues the PEM chain: leaf VMC + intermediate(s) chained to the DigiCert or Entrust root. Delivered as a single PEM file containing all certificates in chain order. The applicant downloads from the CA portal.
10. Publish the PEM to the BIMI a= URL: serve from HTTPS with Content-Type: application/pem-certificate-chain and a long-lived Cache-Control header. See section 7 below for the serving requirements in detail.
11. Publish the BIMI DNS record: v=BIMI1; l=https://...svg; a=https://...pem at default._bimi.<domain>. See DNS Record Generator for the syntax-validating wizard.
12. Verify with a test send: send a DMARC-aligned message to a Gmail or Yahoo recipient and confirm the logo renders. If not, use Domain Security Checker and Email Header Analyzer to triage (DMARC alignment, BIMI record syntax, SVG fetch, VMC chain, hash binding).

Plan as a 6-week procurement task. The registry-coordination step (item 6) is the long pole; expedited issuance is not generally available because the registry timeline is not under CA control. Internal coordination (legal team approval of the SAN list, trademark file retrieval, DNS change-management) often adds another 1-2 weeks on top.

6. SVG-hash binding mechanism

The VMC cryptographically binds the certificate to the SVG bytes via the RFC 3709 LogotypeExtn X.509 extension. The mechanism in detail:

1. At issuance time, the CA receives the SVG file, validates it against the Tiny PS profile, canonicalises the byte stream (UTF-8 encoding, line-ending normalisation), and computes the SHA-256 hash of the canonicalised bytes.
2. The hash is embedded in the VMC inside the id-pe-logotype extension as a HashedLogotype sequence with hashAlg = sha-256 and hashValue equal to the SHA-256 digest.
3. The extension also carries the logo URL (https://.../logo.svg) and the media type (image/svg+xml) — the receiver cross-checks the URL it fetched against the URL encoded in the extension.
4. At verification time, the receiver fetches the SVG from the URL in the BIMI record l= tag, re-computes the SHA-256 of the received bytes, and compares to hashValue in the VMC. Match → logo renders. Mismatch → logo display is suppressed (the message still delivers normally; only the logo is missing).

The binding is one-shot at issuance. Any subsequent edit to the SVG — even a single byte change for whitespace, encoding, or comment cleanup — produces a different SHA-256 hash and breaks the binding. The most common operator surprise is "I optimised the SVG with SVGO after issuance and now my logo is gone" — re-issuance is required.

SVG canonicalisation: the CA may apply a canonicalisation pass before hashing (XML canonical form per XML C14N 1.1 or BIMI Group-specific normalisation). Operator practice is to NOT rely on canonicalisation catching their edits — treat the bytes as hash-locked from the moment the VMC is issued.

Inspecting the hash binding: extract the hash from the VMC with:

openssl x509 -in vmc.pem -text -noout | grep -A 4 'id-pe-logotype'
# or, for the raw extension:
openssl asn1parse -in vmc.pem -strparse <offset>

Re-compute the SVG hash with:

sha256sum logo.svg
# or, equivalently:
openssl dgst -sha256 logo.svg

A mismatch in those two values indicates the SVG has drifted from the VMC binding and the certificate needs re-issuance.

7. PEM file serving rules

The VMC PEM file is served from the URL declared in the BIMI record a= tag. Receivers fetch it during BIMI evaluation. Serving requirements:

Recommended serving topology: dedicated subdomain (bimi.example.com) hosting both logo.svg and vmc.pem, fronted by a CDN with long-lived cache headers and chained certificate served by the CDN edge.

8. Renewal calendar and re-issuance triggers

A VMC has a finite validity period (typical 12-13 months). After the Not After date the certificate is expired and receivers will suppress logo display.

Annual renewal calendar:

• T-90 days: open a renewal ticket with the CA. Re-confirm the trademark registration is still current with the registry (registry-side renewal is independent of the VMC and easy to forget).
• T-60 days: kick off the renewal workflow in the CA portal. The re-validation cycle is shorter than original issuance (no fresh trademark research if the underlying registration is unchanged) but plan 2-3 weeks.
• T-30 days: re-confirm the renewal PEM is published at the a= URL. Test with a fresh send.
• T+0: expiry. Receivers suppress logo display silently — there is no bounce, no DSN, no operator-visible signal unless you check the Domain Security Checker result for the BIMI record.

Other re-issuance triggers (outside the annual calendar):

• SVG bytes changed: any byte-level edit to the SVG breaks the SHA-256 hash binding. Plan SVG edits as joint SVG + VMC re-issuance windows. Cost is full re-issuance.
• Publishing domain set changed: adding a new sending domain to the certificate SAN list requires a new VMC. Existing VMC remains valid for the original SAN coverage until expiry.
• Legal entity changed: corporate restructure, M&A, brand-name rebranding. The certificate Subject changes and re-issuance is mandatory; the underlying trademark may also need re-registration with the new entity name.
• Trademark registration lapsed: registry-side renewal first, then VMC refresh. A VMC bound to a lapsed trademark registration becomes invalid even before its own Not After date — the CA revokes per the CA/Browser Forum requirements.
• Private key compromise: same revocation + re-issuance procedure as any other X.509 certificate. The CA revokes via OCSP / CRL, the receiver picks up the revocation within its cache window, and a new VMC is issued under the existing trademark + domain validation evidence.

Renewal as an operational discipline: set calendar reminders at 90 / 60 / 30 days before Not After. Add a monthly check of openssl x509 -in vmc.pem -noout -dates to the brand operations playbook. The cost of a silent BIMI outage (logo absent for the entire receiver cache window after expiry) is higher than the cost of one calendar reminder.

9. Common VMC rejection causes

When a BIMI logo fails to render despite a VMC being in place, the diagnostic funnel is:

1. DMARC not enforcing — the domain is at p=none. Move to p=quarantine or p=reject first; BIMI is ineligible regardless of VMC validity at p=none. See DMARC policy modes.
2. DMARC failed alignment for this send — even with p=quarantine in place, an individual message can fail alignment (SPF / DKIM not aligned with the From: domain). BIMI is per-message, not per-domain — see DMARC alignment.
3. SVG bytes drifted from VMC hash — someone edited the SVG (re-optimised with SVGO, fixed a typo in <title>, changed a fill colour) without re-issuing the VMC. The SHA-256 binding is broken. Re-issue or revert the SVG to the byte-exact version at issuance time.
4. VMC expired — check openssl x509 -in vmc.pem -noout -dates. Renewal cycle described in section 8.
5. VMC revoked — check OCSP with openssl ocsp -issuer chain.pem -cert vmc.pem -url <ocsp_url>. Revocation happens when the underlying trademark registration lapses, the CA detects fraud, or the customer requests revocation.
6. VMC URL not HTTPS — check the BIMI record a= tag. Receivers reject plain HTTP outright.
7. VMC URL returns wrong Content-Type — check with curl -I https://.../vmc.pem. Some receivers accept text/plain but the canonical value is application/pem-certificate-chain.
8. VMC PEM missing intermediates — the serving response includes only the leaf certificate, no intermediates. Some receivers do not chain-build; serve the full chain.
9. VMC chained to wrong root — the leaf certificate is signed by a root outside the BIMI Group-approved set (DigiCert and Entrust roots). Re-issue through an approved CA.
10. Receiver-specific reputation gating — the receiver has independent brand-reputation logic on top of the technical validation. Logo display is best interpreted as opportunistic, not guaranteed, even with a perfectly valid VMC.

Diagnostic workflow: run Domain Security Checker for the live DNS lookup and chain validation, then send a test message to a Gmail or Yahoo recipient and use Email Header Analyzer on the received message to confirm DMARC alignment for the specific send.

10. Examples

10.1 Inspecting a VMC with openssl

# Dump the full certificate as text:
openssl x509 -in vmc.pem -text -noout

# Validity dates only:
openssl x509 -in vmc.pem -noout -dates
# notBefore=Jan  1 00:00:00 2026 GMT
# notAfter=Jan 15 23:59:59 2027 GMT

# Subject (legal entity):
openssl x509 -in vmc.pem -noout -subject

# Subject Alternative Names (publishing domains):
openssl x509 -in vmc.pem -noout -ext subjectAltName

# Issuer (CA):
openssl x509 -in vmc.pem -noout -issuer

# id-pe-logotype extension (the SVG-binding extension):
openssl x509 -in vmc.pem -text -noout | grep -A 8 'Logotype'

10.2 Verifying the SVG hash matches the VMC binding

# Compute the SVG hash:
sha256sum logo.svg
# 8f3a5e7c1d2b9a4e6f0c8b7d3e5a1f9c2b4d6e8a0c7f3b5d9e2a4c6f8b1d3e5a  logo.svg

# Extract the hash from the VMC LogotypeExtn extension:
openssl x509 -in vmc.pem -text -noout | awk '/Logotype/,/^[A-Z]/' | grep -oE '[0-9a-f]{2}(:[0-9a-f]{2}){31}'

# The two values must match byte-for-byte. A mismatch means the SVG
# bytes drifted from the VMC binding and re-issuance is required.

10.3 BIMI record referencing the VMC

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

The a= tag carries the absolute HTTPS URL of the VMC PEM. Both l= and a= are typically hosted on the same dedicated subdomain (bimi.example.com) so the BIMI assets have an independent caching profile.

10.4 Curl checks against the serving endpoint

# Check Content-Type and Cache-Control:
curl -I https://bimi.example.com/vmc.pem

# Expected response headers:
#   HTTP/2 200
#   content-type: application/pem-certificate-chain
#   cache-control: public, max-age=86400
#   content-length: 4096   (typical leaf + intermediates payload)

# Confirm the full chain is served (not leaf-only):
curl -s https://bimi.example.com/vmc.pem | grep -c 'BEGIN CERTIFICATE'
# Should print 2 or 3 (leaf + 1-2 intermediates).

10.5 OCSP revocation check

# Extract OCSP responder URL from the leaf:
openssl x509 -in vmc.pem -noout -ocsp_uri
# http://ocsp.digicert.com

# Perform OCSP query (requires both leaf and chain):
openssl ocsp -issuer chain.pem -cert vmc.pem \
    -url http://ocsp.digicert.com \
    -header "HOST=ocsp.digicert.com" \
    -resp_text

# Expected status: Cert Status: good
# Revoked: Revoked status with revocation reason and revocationTime.

10.6 SAN list for a multi-domain VMC

# Multi-domain VMCs cover several publishing domains under one
# certificate Subject. The SAN list is the authoritative scope:
openssl x509 -in vmc.pem -noout -ext subjectAltName
# X509v3 Subject Alternative Name:
#     DNS:example.com, DNS:example.net, DNS:example.co.uk

# Adding a new sending domain to the SAN list requires re-issuance
# (a new VMC binding) — the existing certificate cannot be amended
# in place.

11. Frequently Asked Questions

What is a VMC?

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. The certificate is issued under the CA/Browser Forum Mark Certificate profile and embeds the SVG hash, the verified trademark identifier, and the authorised domains. Mailbox providers (Gmail, Apple Mail, Yahoo, AOL) require a VMC before they will display the BIMI logo alongside authenticated mail.

What is the difference between a VMC and a CMC?

A VMC requires a registered trademark in one of the accepted jurisdictions (USPTO, EUIPO, UKIPO, JPO, IP Australia, CIPO). A CMC (Common Mark Certificate) accepts unregistered common-law marks proven to have been used in commerce for at least 12 months. Gmail extended CMC support in 2024 for the blue verified-mark badge feature, but the SVG-display path still requires a full VMC at most major receivers. Pricing for CMC is typically lower than VMC because the validation workload is lower; trademark research is the dominant cost component of VMC issuance.

Which Certificate Authorities issue VMCs?

As of 2026, the two production-issuing CAs approved by the BIMI Group are DigiCert and Entrust. Both issue under the CA/Browser Forum Mark Certificate profile (id-pe-logotype OID 1.3.6.1.5.5.7.1.12). DigiCert and Entrust are the only CAs whose root certificates the major mailbox providers trust for VMC chain validation; certificates from other PKI CAs are rejected even if structurally identical. Issuer choice is a procurement decision, not a technical one — the certificate format and behaviour are identical between the two.

How long does VMC issuance take?

The end-to-end VMC issuance workflow typically takes 3-6 weeks: the CA validates the trademark registration with the registry (1-2 weeks of registry-coordination delay), validates domain control via DNS or HTTPS challenge (1-2 days), validates the SVG against the BIMI Group profile and computes the SVG hash (same-day), and issues the PEM chain (same-day after validation). Plan VMC acquisition as a 6-week procurement task, not a same-day order; the registry-coordination step is the long pole and is not under the CA control.

Which trademark registries are accepted?

The BIMI Group profile accepts trademarks registered with USPTO (United States Patent and Trademark Office), EUIPO (European Union Intellectual Property Office), UKIPO (UK Intellectual Property Office), JPO (Japan Patent Office), IP Australia, and CIPO (Canadian Intellectual Property Office). A small set of additional regional registries is recognised on a per-CA basis; check the current DigiCert and Entrust documentation at issuance time because registry coverage expands periodically. WIPO international filings are recognised through their underlying national registrations, not as a separate validated identity.

How is the SVG bound to the VMC?

At issuance time the CA computes the SHA-256 hash of the canonicalised SVG bytes and embeds the hash in the VMC certificate inside the LogotypeExtn extension (RFC 3709). When a receiver validates a BIMI send, it fetches the SVG from the URL in the BIMI record l= tag and re-computes the SHA-256 hash of the bytes it received, then compares to the hash in the VMC. Any mismatch causes the receiver to suppress logo display. The binding is one-shot at issuance — any subsequent edit to the SVG (even a single byte change) invalidates the binding and requires VMC re-issuance.

How is the VMC PEM served?

The VMC PEM file is served from the URL in the BIMI record a= tag. The serving requirements are: HTTPS only (HTTP is rejected), Content-Type application/pem-certificate-chain (with text/plain or application/x-pem-file as fallback for some receivers), a long-lived Cache-Control header (typical max-age=86400 or longer to align with receiver cache windows), and the certificate chain must be the full chain (leaf + intermediates), not just the leaf. Some receivers do not chain-build from a trust store and require the intermediate certificates to be served alongside the leaf in the PEM file.

When does a VMC need to be re-issued?

A VMC needs to be re-issued at annual renewal (the certificate lifetime is 12-13 months), when the SVG bytes change (the hash binding is broken by any edit), when the publishing domain set changes (adding a new sending domain to the certificate Subject Alternative Names list), when the legal entity owning the trademark changes (corporate restructure, M&A), and when the trademark registration lapses (renew with the registry first, then refresh the VMC). Plan SVG edits as joint SVG + VMC re-issuance windows; the certificate cost is significant and unplanned re-issuances are an operational expense.

Why is my BIMI logo not displaying despite a valid VMC?

The most common causes are: DMARC is at p=none (must be p=quarantine or p=reject for BIMI eligibility), the message failed DMARC alignment for this specific send, the SVG bytes on the server no longer match the hash in the VMC (someone edited the SVG without re-issuing), the VMC is expired (check Not After date with openssl x509 -in vmc.pem -noout -dates), the VMC URL is not served over HTTPS or has the wrong Content-Type, the certificate chain is incomplete (leaf-only serving), or the receiver has independent brand-reputation gating layered on top of the technical validation.

How much does a VMC cost?

VMC pricing is typically in the USD 1,000-3,000 per year range as of 2026, with significant variation by CA, by trademark research complexity, by domain count (Subject Alternative Names), and by negotiated volume discount for larger customers. Trademark validation is the dominant cost component because it requires legal-grade verification with the registry; pricing changes when registry-coordination workload changes. The cost is a sunk-cost overhead of the BIMI deployment regardless of how many messages the domain sends — there is no per-message charge.

12. Related guides

• BIMI explained — the BIMI pillar page covering the protocol surface: DNS TXT syntax (default._bimi, v=BIMI1; l=; a=), Verified Mark Certificates (VMC) at high level, mailbox-provider compatibility, and the DMARC prerequisite. Start there if you have not yet published a BIMI record.
• BIMI SVG Tiny PS logo requirements — the byte-by-byte file-format reference for the SVG Tiny PS profile every BIMI logo must conform to. Read this before applying for a VMC — the CA validates the SVG and computes its SHA-256 hash at issuance time, so the SVG must be finalized before the procurement starts.
• DMARC explained — the policy + reporting standard BIMI builds on top of. BIMI (and therefore the VMC investment) is ineligible without DMARC at p=quarantine or p=reject; the SVG never renders unless the message passes DMARC alignment for the specific send.
• DKIM explained — DomainKeys Identified Mail (RFC 6376): the cryptographic signature that, together with SPF, feeds DMARC alignment — the prerequisite for BIMI logo display.
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-PASS-AS-BIMI- VMC-RENDERING-PRECONDITION companion to this BIMI VMC certificate-procurement pillar. Where THIS page documents the VMC-vs-CMC certificate-type distinction (the Verified Mark Certificate requiring a registered trademark, the Common Mark Certificate accepting unregistered marks but only honoured by Gmail), the two issuing CAs (DigiCert and Entrust), the trademark-evidence pack each CA validates, the PEM-bundle file format the BIMI record's a= URL serves, the 13-month VMC validity window, the per-issuing-CA pricing landscape, and the BIMI-logo-display- contract at the four primary BIMI- receiving consumer inboxes (Gmail, Outlook, Apple Mail, Yahoo, Fastmail) — i.e. the APPLICATION-LAYER-BRAND- INDICATOR-DISPLAY-CERTIFICATE-CHAIN side of the BIMI deployment — the M365- DKIM spoke is the M365-TENANT-DKIM- PASS-VERDICT-PROVIDER companion documenting the M365-tenant-specific DKIM deployment topology whose dkim= pass-with-Friendly-From-header- alignment verdict at the receiver-side DMARC evaluator is the LOAD-BEARING application-layer precondition for the VMC-attested BIMI logo display contract THIS page documents. Concretely, the spoke documents FOUR M365-tenant-DKIM- signing-as-BIMI-VMC-precondition dimensions: (i) M365-tenant BIMI VMC rendering at Outlook / Outlook.com / Outlook-web-and-mobile consumer inbox structurally requires DMARC-pass-with-Friendly-From-header- alignment-enforcement on the protected M365-tenant domain — the BIMI VMC indicator-display contract THIS page documents requires the publishing domain to publish p=quarantine or p=reject DMARC posture with pct=100, and the M365-DKIM spoke documents the M365- tenant-specific dual-selector CNAME- delegated DKIM signing topology whose dkim=pass verdict at the receiver-side DMARC evaluator is one of the TWO alignment-pathways (alongside SPF) producing the DMARC-pass verdict the BIMI VMC indicator-display contract depends on; (ii) M365-tenant dkim=pass verdict directly unlocks BIMI VMC rendering at receiver-side consumer-inbox boundary — absent the M365-tenant-DKIM-pass- with-alignment verdict the spoke documents (e.g., during a Microsoft- managed dual-selector rotation midpoint when one selector returns dkim=temperror, or during a DNS- propagation window where the customer- vanity-domain CNAME-delegation to the Microsoft-managed target zone is still propagating), the BIMI VMC indicator-display contract THIS page documents fails to fire even though the VMC cert-chain itself remains cryptographically valid — the M365- DKIM-deployment-correctness-invariant is a LOAD-BEARING application-layer precondition for the BIMI VMC display contract; (iii) M365-tenant BIMI VMC chain validation runs structurally SEPARATELY from M365- DKIM cryptographic signature validation but BOTH cryptographic validation contracts must succeed for BIMI rendering to fire — the BIMI VMC PEM-bundle chain validates at receiver-side message-rendering time against the BIMI-WG-approved-CA root list (DigiCert and Entrust as the two issuing-CA family roots THIS page documents), and the M365-DKIM-signature validates at receiver-side DKIM-Auth- Results-header generation time against the M365-tenant-customer-vanity-domain DNS-published public-key (per the dual-selector CNAME-delegated topology the spoke documents) — these two cryptographic validation contracts run at STRUCTURALLY-DISTINCT cryptographic validation timepoints but BOTH must succeed for BIMI VMC rendering to fire; and (iv) M365-tenant BIMI VMC procurement coordination with M365- DKIM-key-rotation cadence is operationally manageable through the Microsoft-managed DKIM-key-rotation cadence the spoke documents — the M365-tenant operator's BIMI VMC procurement timeline (13-month VMC validity, ~$1,500-$2,500 USD per year per domain, trademark-evidence pack coordination with brand legal team) coordinates with the Microsoft-managed M365-DKIM-dual-selector rotation cadence the spoke documents — the Microsoft-managed M365-DKIM rotation is operationally INVISIBLE to the BIMI VMC indicator-display contract THIS page documents because the receiver- side DMARC evaluator consumes either selector's dkim=pass verdict identically, making the BIMI VMC procurement decoupled from the M365- DKIM-rotation midpoint at the operational level. Read the DKIM-for- Microsoft-365 spoke alongside this BIMI VMC certificate-procurement pillar when the M365-tenant operator is planning BIMI VMC indicator-display deployment on an M365-hosted publishing domain — the M365-tenant- specific dual-selector CNAME-delegated DKIM deployment topology the spoke documents is the load-bearing application-layer-DKIM-pass-with- alignment precondition consumer-role whose operational integrity the BIMI VMC indicator-display contract THIS page documents depends on.
• DKIM for Google Workspace — the WORKSPACE-TENANT-DKIM-PASS-AS- BIMI-VMC-RENDERING-PRECONDITION companion to this BIMI VMC certificate- procurement pillar. Where THIS page documents the VMC-vs-CMC certificate- type distinction (the Verified Mark Certificate requiring a registered trademark, the Common Mark Certificate accepting unregistered marks but only honoured by Gmail), the two issuing CAs (DigiCert and Entrust), the trademark-evidence pack each CA validates, the PEM-bundle file format the BIMI record's a= URL serves, the 13-month VMC validity window, the per-issuing-CA pricing landscape, and the BIMI-logo-display- contract at the four primary BIMI- receiving consumer inboxes (Gmail, Outlook, Apple Mail, Yahoo, Fastmail) — i.e. the APPLICATION-LAYER-BRAND- INDICATOR-DISPLAY-CERTIFICATE-CHAIN side of the BIMI deployment — the Workspace-DKIM spoke is the WORKSPACE- TENANT-DKIM-PASS-VERDICT-PROVIDER companion documenting the Workspace- tenant-specific DKIM deployment topology whose dkim=pass-with-Friendly- From-header-alignment verdict at the receiver-side DMARC evaluator is the LOAD-BEARING application-layer precondition for the VMC-attested BIMI logo display contract THIS page documents. Concretely, the spoke documents FOUR Workspace-tenant-DKIM- signing-as-BIMI-VMC-precondition dimensions: (i) Workspace- tenant BIMI VMC rendering at Gmail consumer inbox structurally requires DMARC-pass-with-Friendly-From-header- alignment-enforcement on the protected Workspace-tenant domain — the BIMI VMC indicator-display contract THIS page documents requires the publishing domain to publish p=quarantine or p=reject DMARC posture with pct=100, AND Gmail was the FIRST major receiver to support BIMI VMC rendering at consumer-inbox (Gmail rolled out BIMI VMC rendering in 2021 — predating Yahoo and Apple Mail by months, predating Outlook by ~2 years) which makes Workspace-tenant BIMI VMC rendering AT-GMAIL the PRIMARY commercial-value milestone BIMI deployments target; the Workspace-DKIM spoke documents the Workspace-tenant-specific single- selector operator-published TXT-record DKIM signing topology whose dkim=pass verdict at the receiver-side DMARC evaluator is one of the TWO alignment- pathways (alongside SPF) producing the DMARC-pass verdict the BIMI VMC indicator-display contract depends on; (ii) Workspace-tenant dkim= pass verdict directly unlocks BIMI VMC rendering at receiver-side consumer- inbox boundary — absent the Workspace-tenant-DKIM-pass-with- alignment verdict the spoke documents (e.g., during an operator-controlled single-selector rotation midpoint when the new-selector TXT record is not yet published at the customer-vanity- domain DNS zone, or during a per- rotation overlap-window where the old-selector TXT record was retired prematurely), the BIMI VMC indicator- display contract THIS page documents fails to fire even though the VMC cert-chain itself remains cryptographically valid — the Workspace-DKIM-deployment-correctness invariant is a LOAD-BEARING application-layer precondition for the BIMI VMC display contract; (iii) Workspace-tenant BIMI VMC chain validation runs structurally SEPARATELY from Workspace-DKIM cryptographic signature validation but BOTH cryptographic validation contracts must succeed for BIMI rendering to fire — the BIMI VMC PEM-bundle chain validates at receiver-side message-rendering time against the BIMI-WG-approved-CA root list (DigiCert and Entrust as the two issuing-CA family roots THIS page documents), and the Workspace-DKIM- signature validates at receiver-side DKIM-Auth-Results-header generation time against the Workspace-tenant- customer-vanity-domain DNS-published public-key (per the operator-published TXT-record single-selector topology the spoke documents) — these two cryptographic validation contracts run at STRUCTURALLY-DISTINCT cryptographic validation timepoints but BOTH must succeed for BIMI VMC rendering to fire; and (iv) Workspace-tenant BIMI VMC procurement coordination with operator-controlled Workspace-DKIM- key-rotation cadence requires explicit operator coordination through the Workspace Admin Console — the Workspace-tenant operator's BIMI VMC procurement timeline (13-month VMC validity, ~$1,500-$2,500 USD per year per domain, trademark-evidence pack coordination with brand legal team) coordinates with the operator-managed Workspace-DKIM-key-rotation cadence the spoke documents — UNLIKE the Microsoft-managed M365-DKIM-rotation that runs operationally invisible to the BIMI VMC contract, the operator- managed Workspace-DKIM-rotation REQUIRES OPERATOR COORDINATION at the per-rotation overlap-window boundary to maintain the BIMI VMC indicator- display contract's load-bearing application-layer precondition stable across rotation midpoints. Read the DKIM-for-Google-Workspace spoke alongside this BIMI VMC certificate- procurement pillar when the Workspace- tenant operator is planning BIMI VMC indicator-display deployment on a Workspace-hosted publishing domain — the Workspace-tenant-specific single- selector operator-published TXT-record DKIM deployment topology the spoke documents is the load-bearing application-layer-DKIM-pass-with- alignment precondition consumer-role whose operational integrity the BIMI VMC indicator-display contract THIS page documents depends on.
• SPF explained — Sender Policy Framework (RFC 7208): the envelope-sender authorisation mechanism complementary to DKIM. Together SPF + DKIM produce the DMARC verdict BIMI piggybacks on.
• DMARC alignment explained — the alignment-evaluation algorithm (RFC 7489 §3.1) every send must pass before BIMI is even considered.
• DMARC policy modes — the p=none / p=quarantine / p=reject spectrum. BIMI is ineligible at p=none; the policy migration is a prerequisite for VMC procurement.
• TLS-RPT record syntax — the PARALLEL-DNS-TXT-RR-PUBLISHED- POLICY-WITH-TAG-GRAMMAR companion documenting the byte-anatomy of the TLS-RPT TXT record whose v=TLSRPTv1 / rua=mailto: / rua=https: tag-grammar STRUCTURALLY PARALLELS the v=BIMI1 / l= / a= tag-grammar of this BIMI page's default._bimi.<domain> TXT record at the DNS-TXT-RR-published- policy-with-tag-grammar architecture layer. Where THIS page documents the BIMI VMC certificate-acquisition workflow (the X.509 cert + SVG Tiny PS + trademark-jurisdiction binding the default._bimi.<domain> TXT record's l= and a= tag values point to), the TLS-RPT-record-syntax spoke documents the parallel DNS-TXT-RR- published policy where the rua= tag points to an operator-published failure-report ingestion endpoint at the SMTP-receive transport boundary. The four-axis BIMI-VMC-PUBLICATION-DISCIPLINE-VS-TLS- RPT-PUBLICATION-DISCIPLINE comparison exposes the structurally-distinct DNS- TXT-RR-PUBLISHED-POLICY parallels: (i) BIMI default._bimi.<domain> TXT-record byte-anatomy → TLS-RPT _smtp._tls.<domain> TXT-record byte-anatomy — both records publish at per-subdomain underscore-prefixed locations (the BIMI default._bimi subdomain following the BIMI-Group convention, the TLS-RPT _smtp._tls subdomain following the RFC 8460 §3 convention), both use the v=<protocol-version> version-tag-first conformance pattern, both are subject to the same single-record-per-subdomain DNS-TXT-RR publication-discipline constraint THIS page's BIMI publication discipline manages — the spoke documents the TLS- RPT-specific tag-grammar (the rua= reporting URI tag accepting mailto: + https: per-URI-form publication options) parallel to BIMI's l= + a= tag- grammar; (ii) BIMI policy- ineligibility-at-p=none-DMARC publication-prerequisite → TLS-RPT publication-prerequisite at MTA-STS-or- DANE deployment — the BIMI page's prerequisite that DMARC must be at p=quarantine or p=reject for VMC eligibility STRUCTURALLY PARALLELS the TLS-RPT prerequisite that MTA-STS or DANE be deployed for TLS-RPT failure reporting to surface meaningful data (the spoke documents the receiver-side observation whereby publishing TLS-RPT WITHOUT MTA-STS or DANE produces empty / sparse report streams because there is no transport-policy to observe failures against — the prerequisite-stack discipline parallel applies to both DNS-RR-published policy families); (iii) BIMI publication-time syntax- error class → TLS-RPT publication- time syntax-error class — the BIMI default._bimi.<domain> TXT record's canonical publication-time defects (mis-escaped l=https:// URL, mis-formatted a=https:// URL pointing to the PEM endpoint, missing required version tag, accidentally-truncated record at 255-byte string-segment boundary) STRUCTURALLY PARALLEL the TLS-RPT _smtp._tls.<domain> TXT record's canonical publication- time defects (mis-formatted rua=mailto: with comma- separated multi-target URI breaking the RFC 8460 §3 grammar, missing required version tag, accidentally-truncated record at 255-byte boundary) — both are publication-time DNS-TXT-RR byte- grammar violations the spoke documents at the parallel transport-layer-policy- publication boundary; (iv) BIMI publication-quality KPI → TLS-RPT publication-quality KPI as DNS-TXT-RR- policy-pipeline holistic-health observability — when the operator manages BIMI VMC procurement + default._bimi.<domain> publication, the same operator-side DNS-TXT-RR publication-quality discipline parallel-applies to TLS-RPT _smtp._tls.<domain> publication; the spoke documents the operator-side per-domain TLS-RPT- publication-pass-rate as the structurally- parallel observability KPI to BIMI's per-domain VMC-renewal-cadence-tracking KPI, exposing the holistic DNS-TXT-RR- publication-pipeline health across both application-layer policy families. Read the TLS-RPT-record-syntax spoke when the operator's DNS-TXT-RR publication discipline mature enough to ship BIMI VMC procurement is being extended to the transport-layer policy-publication boundary — the spoke is the byte- anatomy reference whose tag-grammar the BIMI-publishing operator already has the DNS-TXT-RR-publication- discipline pattern for.
• DKIM cryptography basics — the PARALLEL-APPLICATION-LAYER-RSA- PUBLIC-KEY-CRYPTOGRAPHIC-ANCHOR companion reference. Where THIS page documents BIMI's VMC / CMC X.509 certificate-chain cryptographic-anchor surface (mark-anchor +1.3.6.1.5.5.7.1.12 logotype extension binding the SHA-256 hash of the SVG Tiny PS file to the VMC cert / trademark- validated mark-binding-to-domain via subject-CN-equals-VMC-SAN-dnsName / DigiCert and Entrust CA-issued / RFC 5280 PKIX cert-chain validation by the mailbox-provider's BIMI verifier), the DKIM-cryptography-basics spoke documents the PARALLEL APPLICATION-LAYER publisher-cryptographic-anchor surface at the message-signing layer: the publisher publishes its DKIM PUBLIC KEY as a TXT record at <selector>. _domainkey.<domain> / RSA-2048 modulus-encoded as base64 / receiver retrieves the public key via DNS at verification time / receiver computes SHA-256 hash over canonicalised headers + body / receiver verifies the b= base64-encoded RSA signature blob against the publisher's public key / verification-result emitted as Authentication-Results dkim=pass / dkim=fail / dkim=neutral / dkim=permerror / dkim=temperror. The TWO cryptographic-anchor surfaces form COMPLEMENTARY layers in the BIMI- eligibility-and-display chain: (i) publisher-DKIM-RSA-key-signing anchors the MESSAGE-LEVEL authenticity proof (the DMARC-alignment-determining-input BIMI eligibility piggybacks on); (ii) publisher-VMC-X.509-cert-chain anchors the LOGO-LEVEL authenticity proof (the SVG-bytes-to-trademark-registered-mark binding the mailbox provider validates before rendering the indicator). Both layers must hold simultaneously for the BIMI display to occur — a publisher with VMC-X.509-chain-validating but DKIM-key-compromised (or DKIM-key- rotation-discipline-failing per the spoke's HSM / per-customer-isolation / no-export-attribute discipline) emits messages that fail DMARC alignment and therefore are ineligible for BIMI display regardless of how strongly the VMC-X.509-chain validates; conversely a publisher with DKIM-RSA-key-signing- flawless but VMC-cert-revoked / SVG-hash-changed-without-CA-revalidation / trademark-registration-lapsed emits messages that pass DMARC but are ineligible for BIMI display. Read the spoke alongside this page to understand the WHY behind the BIMI deployment prerequisite that DMARC alignment be cryptographically-provable in addition to the VMC trademark-validated mark- binding this page documents — the spoke documents the cryptographic-primitive- level discipline (RSA-2048 floor / rsa-sha256 algorithm tag floor / quarterly selector rotation cadence / HSM-backed private-key storage / per- customer key isolation in SaaS) that the message-level half of the BIMI cryptographic-anchor compound requires.
• DANE for SMTP — the PER-MX-HOST-DNSSEC-ANCHORED- TLSA-RR-AS-DNS-PUBLISHED-CRYPTOGRAPHIC- ANCHOR-PARALLEL-TO-VMC-CA-ISSUED-X-509- CERTIFICATE-AS-PKI-PUBLISHED- CRYPTOGRAPHIC-ANCHOR companion documenting how the publisher-side per- MX-host RFC 7672 TLSA-RR DNSSEC-anchored TLS-certificate-binding publication discipline this DANE spoke documents is the structurally-analogous-but-distinct cryptographic-anchor publication discipline that the BIMI VMC X.509 certificate publication this page documents shares load-bearing cross-PKI publication-discipline properties with. Where THIS page documents the BIMI VMC (Verified Mark Certificate) CA-issued X.509 publication discipline (per- publisher trademark-verified Subject Alternative Name brand-domain binding, per-publisher Logotype extension carrying the SVG Tiny PS asset, per- publisher AIA/CRL revocation chain consumed by the per-receiver display- eligibility evaluator, per-publisher BIMI Working Group authorised CA issuance + annual renewal lifecycle), the DANE-for-SMTP spoke is the structurally-analogous cross-PKI cryptographic-anchor-publication reference at four cross-PKI per- publisher cryptographic-anchor- publication coupling dimensions: (i) per-publisher cryptographic- anchor publication topology — DNS- published TLSA-RR for DANE vs PKI- published X.509-VMC for BIMI — as structurally-distinct publication channels of the SAME load-bearing publisher-side cryptographic-anchor publication primitive — DANE publishes per-MX-host _25._tcp.<mx-host> TLSA-RR carrying the per-cert cryptographic anchor (DNSSEC-validated DNS-publication channel); BIMI VMC publishes per-publisher CA-issued X.509 certificate retrievable at the a=-tag URL in the BIMI TXT-RR (PKI-publication channel anchored in the BIMI Working Group authorised CA set); both protocols bind a per-publisher cryptographic anchor to a per-publisher attribute (per-MX-host TLS-cert for DANE, per- publisher brand-logo for BIMI VMC), framing both as structurally-similar publisher-side cryptographic-anchor- publication disciplines despite different publication channels; (ii) per-publisher trust-anchor rooting — DNSSEC for DANE vs CA-list for BIMI VMC — as load-bearing cryptographic-anchor-rooting choice — DANE roots trust in DNSSEC validation per RFC 7672 §1.3.4 (any non-DNSSEC-validated TLSA-RR is treated as absent); BIMI VMC roots trust in the BIMI Working Group authorised CA set (DigiCert, Entrust — currently a small set per the draft-brand-indicators-for- message-identification specification); the per-receiver verification stack consumes each per-publisher cryptographic anchor through the respective trust-anchor-rooting infrastructure — the publisher operates BOTH anchor-publication disciplines on a per-domain basis when they choose to publish a per-MX TLSA-RR AND a per-publisher BIMI VMC; (iii) per-publisher cryptographic-anchor lifecycle — per-MX-host TLSA rotation vs per- publisher VMC annual renewal — as parallel cadence-coordination disciplines — DANE publishers rotate TLSA records (publish new TLSA-RR for incoming cert → wait DNSSEC-anchored propagation → deploy new cert → retire old TLSA-RR after overlap window); BIMI VMC publishers renew annually with the CA (re-validate trademark binding → CA issues new VMC → publisher updates the BIMI TXT-RR a=-tag URL pointing to the renewed VMC); the same per-publisher publish- then-verify cycle discipline applies to both, with the per-publisher per-anchor renewal-cadence the load-bearing operational discipline operators must coordinate across per-domain anchors; (iv) per- publisher cross-PKI cryptographic- anchor publication stack — transport- layer DANE + display-layer BIMI VMC — as per-publisher per-domain complete cryptographic-anchor- publication scope — every per-publisher per-domain cryptographic- anchor-publication catalogue (DKIM at message-layer + DANE at transport- layer + MTA-STS at HTTPS-CA-anchored transport-layer + BIMI VMC at display-layer) composes into a per- publisher complete per-domain cross- PKI cryptographic-anchor-publication discipline; the DANE-explained spoke is the canonical per-publisher transport-layer-DNSSEC-anchored- cryptographic-publication reference BIMI VMC publishers consume alongside this VMC publication-discipline page when scoping the per-publisher per- domain cross-PKI cryptographic-anchor- publication discipline the display- layer BIMI VMC trademark-verified publication this page documents is one layer of, alongside the transport-layer DANE TLS-anchored cryptographic-publication the DANE spoke documents.
• DNS Record Generator — interactive wizard for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records with syntax validation. Use this when publishing the BIMI record with the new VMC URL.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC against any domain. Confirms the BIMI record points to a reachable HTTPS SVG and VMC and that the certificate chain validates.
• Email Header Analyzer — paste a raw email header to see SPF, DKIM, and DMARC pass/fail results inline — useful for confirming a specific send is DMARC-aligned (and therefore BIMI-eligible).
• DKIM key rotation — the DKIM-ROTATION-WINDOW-AS-BIMI- DISPLAY-CONTINUITY-INTERRUPTION-RISK companion to this BIMI Verified Mark Certificate / Common Mark Certificate reference. Where THIS page documents the BIMI VMC / CMC procurement workflow (the DigiCert / Entrust Mark Verifying Authority trademark-evidence-validation gate, the X.509 certificate chain embedding the verified-trademark SVG- Tiny-PS image per IETF RFC 3709 logotype extension, the CAA-record authorization prerequisite, the l= / a= BIMI-record-tag publication discipline, the receiver-side major-mailbox-provider display-eligibility check chain), the dkim-key-rotation spoke documents the UPSTREAM KEY-LIFECYCLE DISCIPLINE whose rotation-window misconfigurations TRANSIENTLY BREAK the upstream DMARC-pass- aligned chain that the BIMI display gate this page documents PRESUPPOSES is continuously satisfied. The structural relationship: BIMI display at the major mailbox provider's render chain (Gmail BIMI-eligible display, Apple Mail iOS-17+ display, Yahoo Mail BIMI-eligible display, Fastmail BIMI-eligible display) is GATED on the receiver-side observing BOTH (i) DMARC-pass-aligned on the incoming message AND (ii) the steady- state DMARC-pass-aligned-rate floor on the publisher's domain history (typically 12+ weeks of ≥95%-aligned-rate per RUA- stream evidence) — and BOTH conditions depend on the publisher's DKIM-side signing-and-alignment chain functioning WITHOUT the transient rotation-window misconfigurations the dkim-key-rotation spoke catalogues (old-key-published-and- new-key-signed window producing NXDOMAIN on signing-side, new-key-published-and- old-key-signed window producing NXDOMAIN on verifier-side). A rotation-window misconfiguration on the publisher's DKIM-side that produces a multi-hour or multi-day DKIM-fail burst transiently breaks the DMARC-pass-aligned chain at the receiver, REVOKING BIMI display eligibility for affected messages sent during that rotation window AND contaminating the publisher's domain history with a DMARC-aligned-rate regression that takes weeks of clean sending to recover from. Pair this page (the BIMI VMC procurement reference) with the dkim-key-rotation spoke (the upstream-DKIM-key-lifecycle discipline) when investing in a VMC: the spoke documents the safe-rotation procedure whose phase-ordering eliminates the rotation-window DKIM-pause vector whose DMARC-aligned-rate consequences would otherwise revoke the BIMI display gate this page documents the certificate- procurement side of, defending the publisher's BIMI-display-continuity investment against the rotation-window misconfiguration class of unforced operational errors.
• CAA records explained — Certification Authority Authorization (RFC 8659). The CAA record published at the apex domain (or inherited from a parent zone via RFC 8659 §3 issuer-iteration) constrains WHICH CAs may issue certificates for the domain. BIMI's two production-issuing CAs — DigiCert and Entrust — must each be explicitly listed in an issue directive (or the apex must omit CAA entirely) for the VMC procurement to pass the CA's issuance-time pre-flight authorization check. A domain that has previously tightened CAA to a specific non-MVA CA for general TLS hygiene will see the VMC application fail at the CA's order-validation step with a CAA-authorization error — surfaced from the CA side, not the BIMI deployment side, so the failure can take days of vendor-support triage to diagnose. Audit and amend CAA BEFORE paying the trademark-validation fee.
• DNS propagation — the BIMI-VMC-DEPLOYMENT-AS-MULTI- RECORD-DNS-AND-HTTPS-COORDINATED- PUBLICATION-CYCLE companion to this BIMI VMC certificate page. The DNS propagation spoke is the publisher- side publish-and-verify-cycle reference that mediates how long a BIMI deployment change takes to materialise at the major-mailbox- provider BIMI-indexer-side render-eligibility decision at FOUR BIMI-publication-coordination dimensions: (i) publisher publishes new default._bimi.<d> TXT record with VMC a= URL → receiver-side BIMI-indexer cache invalidates at TTL expiry → Gmail / Apple Mail / Yahoo BIMI-display gate begins evaluating the new VMC against the publisher's SVG asset — the DNS propagation spoke documents the cycle for the publisher emitting the new BIMI TXT record: TTL- bounded authoritative-resolver cache invalidation governs the first-receiver-visibility window; the major-mailbox-provider BIMI- indexer crawl-cycle (typical 24-72 hours at Gmail, 1-7 days at Apple iCloud Mail) is the second-stage delay independent of the DNS TTL — making explicit that the publisher's BIMI-deployment time-to-display-eligibility is the composition of the DNS TTL window AND the BIMI-indexer crawl-cycle; (ii) publisher rotates VMC certificate (new issuance from DigiCert / Entrust) → new a= URL on the BIMI TXT record → coordinated DNS publish + HTTPS endpoint publication cycle — the DNS propagation spoke documents the cycle for VMC certificate rotation: publisher must coordinate the TTL-bounded DNS TXT record change AND the HTTPS endpoint serving the new VMC + linked SVG asset; the publisher should serve BOTH the OLD and NEW VMC HTTPS endpoints simultaneously for the duration of the TTL window to avoid a BIMI display interruption during the receiver-resolver cache transition; the spoke documents the OPERATOR-DISCIPLINE-RULE for coordinated multi-record-and- HTTPS-asset rotation; (iii) publisher modifies the SVG asset bytes (re-mastered logo, square-viewBox fix, Tiny-PS profile compliance bytes update) → l= URL stays the same but the HTTPS-served asset bytes change → receiver-side BIMI-indexer SVG-asset-cache invalidation window — the DNS propagation spoke documents the OFTEN-OVERLOOKED variant where the publisher updates the SVG asset bytes without rotating the VMC certificate or changing the BIMI TXT record — in this case the DNS TTL does NOT mediate the change (the TXT record is unchanged), but the major- mailbox-provider BIMI-indexer SVG-asset-cache invalidation window (typical 24-72 hours at Gmail, 1-7 days at Apple iCloud Mail) DOES mediate the receiver-side display latency; the spoke documents the operator- discipline rule for forcing BIMI-indexer SVG-asset-cache refresh (HTTPS Cache-Control headers on the SVG asset URL, ETag-based re-validation hint, asset- URL fingerprinting query- string pattern); (iv) publisher retires BIMI deployment entirely → DNS TXT record DELETE → TTL- bounded cache invalidation window before BIMI-display gate at the mailbox provider re-evaluates and removes the brand logo from the recipient inbox listing — the DNS propagation spoke documents the cycle for the publisher retiring a BIMI deployment: TTL-bounded cache invalidation governs how long after the TXT record DELETE the major- mailbox-provider BIMI- indexer recheck-cycle observes the absence of the BIMI TXT record and removes the brand-logo rendering from the recipient inbox display; the spoke is the operator- discipline reference for compute the worst-case time-to-brand-logo-removal in a BIMI-retirement scenario (TTL window + indexer recheck-cycle). Read the DNS propagation spoke WITH this BIMI VMC certificate page when scheduling a BIMI deployment, rotation, or retirement — THIS page is the VMC X.509 PKI protocol reference; the propagation spoke is the TTL-bounded-publish- and-verify-cycle operator- discipline reference for safely coordinating the DNS-TXT + HTTPS-asset multi-record change the BIMI deployment lifecycle depends on.
• MTA-STS vs DANE for SMTP — the BIMI-VMC-X.509-PKI-AS-PRECONDITION- FOR-MTA-STS-TRANSPORT-LAYER-TRUST-MODEL- CHOICE companion documenting the operator- side transport-layer-security trust-model choice between MTA-STS and DANE, viewed through the X.509-PKI familiarity an operator gains from deploying a BIMI VMC. Where THIS page documents the BIMI VMC X.509 PKI mechanics (the CA/Browser-Forum Mark-Certificate profile baseline- requirements, the per-CA Mark Verifying Authority trademark-validation procedure, the RFC 3709 LogotypeExtn extension carrying the SVG-Tiny-PS hash binding, the per-domain CAA-record gating of which CA may issue the VMC at the apex, the operator-side 12-15 month VMC procurement timeline with the 3-6-week MVA validation window, the per-CA renewal cadence, and the per-domain VMC-trademark-validation cost), the MTA-STS-vs-DANE spoke documents the structurally-parallel operator-side transport-layer-security trust-model choice that the operator encounters when extending their X.509-PKI understanding from the BIMI VMC layer into the SMTP transport layer: MTA-STS (RFC 8461) uses the SAME X.509 CA-chain trust model the operator already understands from their BIMI VMC deployment — the per-domain mta-sts.<domain> HTTPS host serves the policy file behind a public-CA-issued X.509 certificate, receivers fetch the policy by validating the X.509 chain through their public-CA trust-store, and policy-fetch failures produce a CA-chain-mismatch error analogous to a BIMI VMC validation failure; whereas DANE (RFC 7672) uses an ENTIRELY DIFFERENT DNSSEC-based trust-model that bypasses the X.509 CA chain — the per-domain TLSA RR at _25._tcp.<mx-host> carries the certificate-or-public-key fingerprint that the connecting receiver validates via a DNSSEC-signed DNS path, and the trust anchor is the root-zone KSK rather than the public-CA trust- store. The MTA-STS-vs-DANE comparison spoke is the OPERATOR-FACING DECISION REFERENCE that surfaces every dimension of the trust-model choice (PKI vs DNSSEC, public-CA-revocation-list latency vs DNSSEC-chain-validity, per-CA-trust- store divergence between receivers vs DNS-resolver universality, certificate- rotation operational discipline vs TLSA-record-rotation operational discipline, per-domain deployment- complexity vs DNSSEC-zone-signing- prerequisite). Read the MTA-STS-vs-DANE comparison spoke alongside this BIMI VMC reference when scoping the transport-layer-security posture complementing the BIMI VMC deployment — the X.509-PKI familiarity the operator gains from VMC deployment is the PRECONDITION that makes the MTA-STS-vs-DANE decision tractable, and the comparison spoke is the operator-facing reference for extending that PKI understanding into the transport-layer-security stack. Closes the BIMI-cluster ↔ MTA-STS-cluster bridge whereby the X.509-PKI mechanics THIS BIMI VMC page documents are the STRUCTURAL PRECONDITION for the operator-facing transport-layer-security trust-model decision the MTA-STS-vs-DANE comparison spoke documents.
• Email security glossary — the AUTHENTICATED-BRAND-INDICATOR-AS- LOAD-BEARING-VISUAL-ANTI-PHISHING- CONTROL companion to this BIMI VMC X.509 Verified Mark Certificate reference. Where THIS page documents the publisher- side CA-issued X.509-VMC trust-chain, the Subject Alternative Name brand- domain binding, the Logotype-extension SVG-asset hash binding, the AIA/CRL/OCSP revocation chain, and the per-cert annual-renewal lifecycle at the BIMI VMC protocol layer, the glossary spoke catalogues the brand-impersonation + look-alike-domain + defense-in-depth vocabulary every downstream receiver- side visual-anti-phishing analyst consumes at four BIMI-display-layer- control-to-security-vocabulary coupling dimensions: (i) BIMI VMC-gated per-publisher authenticated-brand-logo render as the canonical receiver-side VISUAL anti-brand-impersonation control layer, downstream consumer of the glossary's brand-impersonation + look-alike-domain entries (brand-impersonation, lookalike-domain, typosquatting, homograph-attack, cousin-domain, combosquatting, display-name-attack) — the glossary's brand-impersonation entry explicitly names BIMI as the defensive control that "gives authenticated mail a visible logo, helping users distinguish authenticated vs unauthenticated brand mail", framing the per-publisher VMC publication-discipline THIS page documents as the upstream cryptographic precondition for the receiver-side visual brand-attestation the glossary catalogues as the canonical anti- impersonation control; (ii) BIMI VMC procurement workflow as load- bearing input to the glossary's defense-in-depth + secure-email- gateway entries (defense-in-depth, secure-email-gateway, browser-isolation, phishing-resistant-mfa, conditional-access) consumed by the security-architect scoping the cross-layer defensive posture — the glossary's defense- in-depth catalogue documents the per- layer control (perimeter, gateway, endpoint, identity, data, response) and explicitly catalogues BIMI as a visual-control at the inbox-render layer that the per-publisher VMC publication-discipline THIS page documents extends, anchoring the BIMI VMC X.509-PKI lifecycle to the cross-layer defensive posture vocabulary every security-architect applies; (iii) BIMI VMC display- gating as load-bearing input to the glossary's phishing-and-attack- taxonomy entries (phishing, spear-phishing, whaling, clone-phishing, credential-harvesting, quishing, angler-phishing, conversation-hijacking) consumed by the per-recipient anti- phishing-training programme — the glossary's phishing-taxonomy catalogue documents the per-phishing-variant threat-pattern (visual brand-cue spoof, thread-hijacked compromised-account, QR-code-redirect bypass, clone-of- previous-message social-proof replay) that the per-publisher BIMI VMC visual-logo gating THIS page documents structurally complements as a per-message receiver-side visual signal helping the per-recipient distinguish authenticated brand-mail from per-phishing-variant attacks; (iv) BIMI VMC trademark-anchor + Mark Verifying Authority + CA/B Forum Working Group governance as load-bearing input to the glossary's threat-intelligence + SOC + IR entries (threat-intelligence, soc, incident-response, secure-email-gateway, mitre-attack, ttp) consumed by the brand-protection + SOC + threat- intelligence team — the glossary's threat-intelligence + SOC catalogue documents the per-brand monitoring + takedown-service + per-VMC-revocation- emergency-response tradecraft the per- publisher BIMI VMC trademark-anchored cryptographic-brand-attestation THIS page documents is the load-bearing per-publisher cryptographic-brand- binding for, anchoring the VMC X.509 + Mark Verifying Authority governance lifecycle to the per-brand SOC + IR + threat-intelligence vocabulary every per-brand-protection analyst consumes. Read the glossary alongside this BIMI VMC certificate reference when scoping the per- publisher authenticated-brand- indicator publication-discipline whose cross-layer defensive role the receiver-side visual anti-phishing + brand-protection + defense-in- depth vocabulary every downstream analyst structurally consumes.
• DigiCert Verified Mark Certificates — one of the two production-issuing CAs.
• Entrust Verified Mark Certificates — the other production-issuing CA.
• CA/Browser Forum Mark Certificate Working Group — the standards body publishing the Mark Certificate profile.
• DKIM-Signature header explained (RFC 6376 §3.5 byte-by-byte tag anatomy: v= a= c= d= s= h= b= bh= i= q= l= t= x= z=) — the per-message sender-side DKIM-Signature header reference companion to this BIMI VMC certificate-procurement pillar. Where THIS page documents the VMC X.509-PKI trust-chain (DigiCert / Entrust issuing CAs, the PEM-bundle file format the BIMI record's a= URL serves, the 13-month VMC validity window, the BIMI-display contract at consumer inboxes), the DKIM-Signature spoke documents the UPSTREAM per-message cryptographic-primitive — the literal DKIM-Signature: header tag catalogue every BIMI-supporting receiver evaluates BEFORE rendering the VMC-attested brand indicator. The BIMI-VS-DKIM-SIGNATURE cross-reference establishes FOUR coupling dimensions: (i) the d= (signing-domain) tag anatomy is the load-bearing identifier the BIMI receiver aligns against the visible From-header organisational domain — VMC display fires only when DMARC-aligned- DKIM-pass holds, and the alignment check compares the DKIM-Signature d= tag against the From-header domain; the spoke documents the per-tag byte-shape and alignment semantics; (ii) the b= (signature base64) and bh= (body-hash base64) tags carry the per-message cryptographic proofs the receiver verifies BEFORE committing to the VMC chain validation — most BIMI-display no-render outcomes trace to a bh= mismatch (forwarder rewrote body) or a b= mismatch (header modification after signing); the spoke documents the two-hash design and the per-tag diagnostic semantics every BIMI operator needs to interpret no-render reports; (iii) the s= (selector) tag tells the receiver which public key to fetch from <selector>._domainkey.<d> — the SAME DNS publication discipline VMC operators apply to the default._bimi.<d> record; per-publisher selector rotation cadence and BIMI VMC renewal cadence share the per-publisher DNS-propagation-aware overlap-window operational discipline the spoke documents; (iv) the h= (signed-header list) tag determines which message headers the cryptographic signature protects — including the From-header whose organisational domain the BIMI display contract aligns against; the spoke documents the h= tag's canonical inclusion of From: and the receiver-side risk when From: is omitted from the signed-header set. Read the DKIM-Signature-explained spoke when diagnosing no-render BIMI outcomes whose upstream cause is a DKIM-Signature tag misconfiguration rather than a VMC chain defect.
• Business email compromise (BEC) defender catalogue — the BEC variant + defender-side enforcement-primitive reference covering CEO-fraud / vendor-impersonation / payroll-redirection / cousin-domain- lookalike / compromised-account-replay / thread-hijack-after-account-takeover attack-pattern catalogue and the per- publisher per-domain SPF + DKIM + DMARC + ARC + MTA-STS + BIMI defender-side enforcement-primitive stack against per- attack-variant impersonation. THIS page documents the per-publisher per-brand BIMI Verified Mark Certificate (VMC) per- domain X.509 + RSA-2048-minimum + per- brand-trademark-registry-evidence + per- CA-PKIX-chain VMC issuance + per-receiver- side per-VMC-chain validation pipeline at the BIMI inbox-rendering brand-identity- cryptographic-anchor boundary; the BEC- defender-catalogue spoke is the per-attack- variant defender-side enforcement peer documenting how the per-publisher per-brand VMC issuance + per-receiver-side per-VMC- chain validation pipeline this page documents structurally closes per-attack- variant BEC brand-identity-impersonation attack-surfaces — (i) per-attacker per- brand cousin-domain-lookalike attack- variant (the BEC vendor-impersonation attack-class targeting per-publisher per- brand display-recognition exploitation) is structurally limited by per-publisher per- brand BIMI-VMC-cryptographic-anchored brand-logo rendering at the per-receiver- side inbox-display boundary, denying per- attacker cousin-domain spoofed-brand-logo display-recognition exploitation when the per-receiver renders ONLY VMC-cryptographic- anchored brand-logos; (ii) per-attacker compromised-account per-thread-hijack attack-variant (the BEC after-account- takeover persistence-mechanism) is per- receiver-side BIMI-VMC-cryptographic- anchored brand-logo-rendering CONTINUE TO DISPLAY because the per-thread-hijack attack-class operates from the legitimate- publisher per-domain DKIM-signing authority, surfacing per-attack-variant BEC-defender-side per-receiver-side thread-hijack defender-side limitation that per-publisher per-domain BEC-defender-side DEFENDER-CATALOGUE MUST PUBLISH as load- bearing per-attack-variant per-receiver- side BIMI display-recognition limitation; (iii) per-publisher per-brand VMC + DMARC- p=reject + DKIM-aligned-pass UPSTREAM- CRYPTOGRAPHIC-ANCHOR-DISCIPLINE is the canonical BEC-defender-side per-attack- variant per-brand display-recognition attack-surface CLOSURE DISCIPLINE every per-publisher per-brand BEC-defender-side per-attack-variant defender-catalogue MUST publish as load-bearing per-brand-identity- cryptographic-anchor prerequisite. Read the BEC-defender-catalogue spoke alongside this BIMI-VMC reference when authoring the per- publisher per-brand BEC-defender-side per- attack-variant per-brand display- recognition-impersonation publication discipline that structurally closes the per-attack-variant BEC brand-identity- impersonation attack-surface the per- publisher per-brand VMC issuance + per- receiver-side per-VMC-chain validation pipeline this page documents structurally gates.
• RFC 3709 — Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates — the extension specification that defines the LogotypeExtn structure VMCs use to embed the SVG hash binding.
• BIMI Group (Authindicators Working Group) — the industry consortium that maintains the authorised-issuer list and the BIMI Group SVG profile.
• IETF draft-brand-indicators-for-message-identification — the BIMI specification itself. Still an Internet Draft, not yet a published RFC.
• Email spoofing — the DIRECT-DOMAIN-SPOOFING-AND- BRAND-IMPERSONATION-CANONICAL- THREAT-MODEL companion to this BIMI VMC X.509 Verified Mark Certificate reference. Where THIS page documents the publisher-side CA-issued X.509- VMC trust-chain, the Subject Alternative Name brand-domain binding, the Logotype-extension SVG-asset hash binding, the AIA/CRL/OCSP revocation chain, and the per-cert annual-renewal lifecycle at the BIMI VMC protocol layer, the email- spoofing spoke documents the CANONICAL THREAT-MODEL the BIMI VMC authenticated-brand-logo receiver-side display gate is structurally defending against, bridging the per-publisher BIMI VMC publication-discipline this page documents to the per- spoof-variant threat-model the email-spoofing spoke catalogues at four cross-protocol-BIMI-VMC- publication-to-spoof-variant coupling dimensions: (i) BIMI VMC authenticated-brand- logo display-gating as load- bearing receiver-side VISUAL anti-direct-domain-spoofing control downstream consumer of the email-spoofing spoke's direct-domain-spoofing threat- class catalogue — the email- spoofing spoke documents the DIRECT-DOMAIN-SPOOFING threat- variant (attacker forges From: ceo@victim.com without an authentic DKIM signature) whose receiver-side defensive layer at the per- recipient inbox-render boundary is BIMI's authenticated-brand- logo display gating — the spoofed message produces dmarc=fail and therefore is INELIGIBLE for the per-publisher BIMI authenticated- brand-logo render that THIS page's VMC publication-discipline enables, giving the per- recipient a visual signal distinguishing per-publisher authenticated brand-mail from per-domain-spoofing attempts; (ii) BIMI VMC trademark- verified-brand-binding as load- bearing receiver-side anti- LOOK-ALIKE-DOMAIN-spoofing control downstream consumer of the email-spoofing spoke's look-alike-domain spoof-variant catalogue — the email-spoofing spoke documents the LOOK-ALIKE- DOMAIN-SPOOFING threat-variant (attacker registers vict1m.com with its own SPF/DKIM/DMARC and could theoretically pass per-domain DMARC) whose receiver-side defensive layer is BIMI's trademark-verified VMC issuance — the look-alike attacker cannot obtain a CA-issued VMC for the publisher's trademark (the Mark Verifying Authority validation step structurally excludes typosquatters), so even if the look-alike domain publishes DMARC at p=reject and authentic SPF + DKIM signing, it cannot earn the per- publisher authenticated-brand- logo display the per-recipient visually recognises — framing the per-publisher VMC trademark-anchor THIS page documents as the load-bearing anti-look-alike-domain visual- signal complement to the per- publisher DMARC enforcement the email-spoofing spoke documents the look-alike-domain attacker structurally bypasses; (iii) BIMI VMC display-eligibility absence as load-bearing receiver-side anti-DISPLAY-NAME- SPOOFING + anti-COUSIN-DOMAIN per-recipient-visual-cue control downstream consumer of the email- spoofing spoke's display-name and cousin-domain spoof-variant catalogue — the email-spoofing spoke documents the DISPLAY- NAME-SPOOFING and COUSIN-DOMAIN- SPOOFING threat-variants (attacker sets From: "Victim CEO" <attacker@gmail.com> or registers victim-secure.com cousin-domain) where DMARC evaluates against the address- portion d-domain and DOES NOT flag these spoof-variants — the per-recipient defensive layer is the ABSENCE of the per-publisher authenticated- brand-logo at the inbox-render boundary (the spoof message renders without the brand logo even when DMARC technically passes for the attacker's address-portion domain), framing the per- publisher VMC display- eligibility positive-signal THIS page documents as the downstream visual-cue per- recipient anti-display-name and anti-cousin-domain attribution control the email- spoofing spoke documents the receiver-side defense-stack depends on; (iv) BIMI VMC publication-discipline as load-bearing per-publisher anti-brand-impersonation defense-stack member, downstream consumer of the email-spoofing spoke's brand- impersonation + clone-phishing + supply-chain-phishing spoof- variant catalogue — the email-spoofing spoke documents the BRAND- IMPERSONATION + CLONE-PHISHING + SUPPLY-CHAIN-PHISHING spoof- variants (attacker visually copies the publisher's branding regardless of sending-domain authenticity) whose per-publisher defensive stack catalogue includes BIMI VMC publication-discipline as the message-layer cryptographically-anchored visual-attestation companion to per-publisher DMARC enforcement + per-publisher trademark-monitoring + per- publisher takedown-service engagement — anchoring the per-publisher VMC publication- discipline THIS page documents to the per-publisher cross- layer anti-brand-impersonation defense-stack the email- spoofing spoke documents. Read the email-spoofing spoke alongside this BIMI VMC certificate reference when scoping the per-publisher per-domain authenticated- brand-indicator publication- discipline whose receiver-side anti-spoof visual-control role the per-publisher anti- direct-spoof + anti-look- alike + anti-display-name + anti-brand-impersonation defense-stack the email- spoofing spoke catalogues structurally consumes.
• MTA-STS for Microsoft 365 — the LOAD-BEARING per-M365-tenant per- custom-domain PER-M365-TENANT-PER-CUSTOM- DOMAIN-MTA-STS-HTTPS-POLICY-HOST-TRUST- CHAIN-PUBLICATION-AS-PEER-OF-PER-M365- TENANT-PER-CUSTOM-DOMAIN-BIMI-VMC-HTTPS- CERTIFICATE-PUBLICATION-DISCIPLINE companion documenting the per-M365-tenant per-custom-domain MTA-STS publication tutorial (the per-tenant _mta-sts.<d> TXT-RR version + policy ID publication, the per- tenant https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication listing mx: *.mail.protection.outlook.com as the enforced-mode MX cone). Where THIS page documents the per-publisher per-domain BIMI VMC HTTPS-certificate publication discipline (the per-publisher VMC PEM-format certificate fetched over HTTPS from the publisher-controlled certificate-host URL declared via the BIMI a= tag, the certificate-chain validation against the BIMI Group's trust-anchor list, the per-publisher per-mark Mark Verifying Authority logo-binding attestation), the MTA-STS-for-M365 spoke documents the per-M365-tenant per-custom-domain MTA- STS-HTTPS-POLICY-HOST-TRUST-CHAIN publication discipline — the cross- protocol HTTPS-trust-chain peer of THIS page's BIMI-VMC-HTTPS-certificate-trust- chain publication discipline at the cluster-level cross-protocol per-tenant per-custom-domain HTTPS-trust-chain publication-coupling boundary. Read THIS page when PUBLISHING the per-publisher per-domain BIMI VMC HTTPS-certificate trust-chain; read the MTA-STS-for-M365 spoke when PUBLISHING the per-M365- tenant per-custom-domain MTA-STS HTTPS- policy-host trust-chain that PARTNERS with the BIMI VMC HTTPS-certificate publication this page documents at the per-tenant per-custom-domain CROSS- PROTOCOL HTTPS-trust-chain publication- coupling boundary.
• DMARC for SaaS senders — the FOUNDATIONAL-PREREQUISITE-FOR- PER-CUSTOMER-DOMAIN-BIMI-DISPLAY- LAYER-CERTIFICATE-PUBLICATION companion to this per-publisher per- domain BIMI VMC HTTPS-certificate publication reference. Where THIS page documents the per-publisher per- domain BIMI VMC HTTPS-certificate trust-chain publication discipline, the SaaS-sender DMARC spoke documents the per-SaaS-sender per-customer- domain DMARC TXT publication, the per-customer-domain SPF-include cascade (include:<saas>.com) authorising the SaaS-sender outbound- MTA IP cone, and the per-customer- domain DKIM-CNAME delegation (<selector>._domainkey.<customer> → <selector>.<saas>.com) publishing the SaaS-sender-managed DKIM key under the customer's domain. Read the SaaS-sender DMARC spoke as the LOAD-BEARING per-customer-domain APPLICATION-LAYER authentication- publication-discipline FOUNDATIONAL- PREREQUISITE the BIMI VMC HTTPS- certificate publication this page documents STRUCTURALLY DEPENDS ON (BIMI publication is per RFC 9165 §3 gated by per-domain DMARC p=quarantine or p=reject enforcement) — no SaaS-sender-customer can publish a BIMI VMC HTTPS-certificate without first achieving DMARC enforcement on the customer domain via the per- customer-domain SPF + DKIM + DMARC publication discipline this spoke catalogues.
• DMARC troubleshooting — the PER-PUBLISHER-PER-DOMAIN-DMARC- VERDICT-OPERATIONAL-DIAGNOSIS companion to this BIMI VMC HTTPS-certificate- chain-of-trust reference. Where THIS page documents the per-publisher per- domain BIMI VMC HTTPS-certificate chain-of-trust publication discipline (the per-publisher per-domain VMC issuance via a CA Browser Forum Mark-Certificate-CA-eligible certificate authority, the per-VMC chain-of-trust to a recipient-trusted root, the per-VMC mark-policy validation gating), the DMARC troubleshooting spoke is the PER-PUBLISHER-PER-DOMAIN-DMARC- VERDICT-FAIL-REMEDIATION companion documenting the operational- diagnosis surface for DMARC verdict- fail regressions that DEGRADE the per-publisher per-domain BIMI indicator-display surface THIS page documents. The composition operates through the BIMI-spec gating constraint: per RFC 9165 §3, the per-publisher per-domain BIMI indicator-display surface depends on the per-publisher per-domain DMARC verdict reaching p=quarantine / p=reject enforcement AND the per-message DMARC verdict being dmarc=pass — a per-message DMARC-verdict regression cascades immediately into per- recipient BIMI-indicator suppression at the receiver-side mail-client surface. The troubleshooting spoke documents the per-verdict diagnosis decision-tree: (i) per-domain spf=fail on operator- controlled mail — the spoke walks through the per-domain SPF record publication-discipline audit, the per-source-IP authorisation audit, and the per-domain SPF-include- cascade lookup-budget audit; (ii) per-domain dkim=fail / dkim=permerror on operator-controlled mail — the spoke walks through the per-selector key- publication audit, the per-message signature-canonicalisation audit, and the per-message body-hash audit; (iii) per-domain dmarc=fail from alignment-mismatch — the spoke walks through the per-publisher per-domain SPF / DKIM alignment audit against the RFC5322.From-domain. The per- publisher per-domain BIMI indicator- display surface depends on the operational-diagnosis surface the troubleshooting spoke documents because EVERY per-message DMARC- verdict regression cascades into per-recipient BIMI indicator suppression. Read THIS page when AUTHORING the per-publisher per- domain BIMI VMC HTTPS-certificate chain-of-trust publication discipline; read the DMARC- troubleshooting spoke when DIAGNOSING per-recipient BIMI- indicator-suppression regressions whose root cause is per-message DMARC-verdict regression the per-publisher per-domain SPF / DKIM / alignment surface the troubleshooting decision-tree catalogues.
• Email deliverability — the per-publisher per-domain DELIVERABILITY-ENGINEERING-OPERATIONAL companion to this per-publisher per- domain BIMI VMC HTTPS-certificate- chain-of-trust reference. Where THIS page documents the per-publisher per- domain VMC issuance via a CA Browser Forum Mark-Certificate-CA-eligible certificate authority and the per-VMC chain-of-trust to a recipient-trusted root, the email-deliverability spoke documents the per-publisher per-domain deliverability-engineering operational discipline whose recipient-engagement feedback loop the BIMI indicator display surface materially influences. The composition operates through the per-recipient engagement-signal cascade: per-recipient mail clients displaying the per-publisher BIMI indicator produce measurably higher per-recipient open-rates (per multiple per-recipient engagement-uplift studies BIMI Group publishes), per-recipient open-rate contributes to the per-recipient mailbox- provider sender-reputation scoring surface, and per-recipient mailbox- provider sender-reputation drives the per-publisher per-domain deliverability- engineering surface the email- deliverability spoke catalogues across ten operational dimensions (per-publisher per-domain SPF / DKIM / DMARC authentication green-state baseline, per-publisher per-domain reputation warm-up cadence, per-recipient mailbox- provider feedback-loop signup, per- message bounce-handling discipline, per-recipient unsubscribe-friction minimisation, per-publisher per-domain IP-and-domain reputation monitoring, per-recipient mailbox-provider postmaster- tool integration, per-message engagement- signal optimisation, per-publisher per- domain blacklist monitoring, per-recipient mailbox-provider header-and-content compliance). Read THIS page when AUTHORING the per-publisher per-domain BIMI VMC chain-of-trust publication discipline as a per-publisher per-domain engagement-uplift investment; read the email-deliverability spoke when UNDERSTANDING the per-publisher per- domain deliverability-engineering operational baseline the BIMI indicator- display surface feeds engagement-signal uplift into via the per-recipient mailbox-provider sender-reputation cascade.
• DKIM troubleshooting — the LOAD-BEARING DKIM-PASS-AND-ALIGNED-AS- BIMI-INDICATOR-ELIGIBILITY-PRE-CONDITION operator-diagnostic companion to THIS page's per-publisher per-domain BIMI VMC chain-of- trust publication discipline. Where THIS page documents the per-publisher per-domain VMC issuance / S/MIME-extended-validation / SVG Tiny PS asset-binding chain-of-trust publication discipline whose per-publisher per-domain indicator-display eligibility requires DMARC enforcement (p=quarantine or p=reject with pct=100) at the per-receiver per-message indicator-rendering boundary, the DKIM-troubleshooting spoke documents the per-symptom decision-tree the operator descends when the per-receiver per-message DKIM-pass-AND-aligned verdict — the load- bearing DKIM-side authentication pre- condition that lets the DMARC verdict pass and unlocks the BIMI indicator-rendering eligibility — regresses. The BIMI-VS-DKIM- TROUBLESHOOTING cross-reference establishes the per-publisher per-domain causal chain: BIMI indicator-display eligibility requires DMARC pass (RFC 7489 §6.6.3 per-receiver per-message verdict) which requires AT LEAST ONE of SPF-aligned-pass OR DKIM-aligned- pass (RFC 7489 §4 alignment evaluation); because forwarder-induced Return-Path-rewriting breaks SPF alignment at every forwarder hop, the DKIM-aligned- pass path is the load-bearing per-message authentication pre-condition for BIMI indicator eligibility at every forwarder- traversing send. When the BIMI indicator stops rendering at a target mailbox- provider, the operator inspects the per- receiver per-message DKIM result class via the troubleshooting decision tree — because a DKIM-side regression cascades DIRECTLY into a DMARC-fail verdict that cascades into BIMI indicator-rendering ineligibility at the per-receiver per- message boundary. Read THIS page when AUTHORING the per-publisher per-domain BIMI VMC chain-of-trust publication discipline; read the DKIM-troubleshooting spoke when DIAGNOSING per-receiver per- message BIMI indicator-rendering regressions whose root cause is the upstream DKIM-aligned-pass per-message authentication pre-condition regression rather than the per-publisher per-domain VMC chain-of-trust publication discipline itself.
• SPF 10-DNS-lookup limit — the SPF-10-DNS-LOOKUP-CEILING-AS-PUBLISHER-SIDE- PRECONDITION-FOR-BIMI-INDICATOR-RENDERING-ELIGIBILITY companion to this BIMI VMC X.509 Verified Mark Certificate reference. Where THIS page documents the publisher-side CA-issued X.509-VMC trust-chain, the Subject Alternative Name brand-domain binding, the Logotype-extension SVG-asset hash binding, the AIA/CRL/OCSP revocation chain, and the per-cert annual-renewal lifecycle at the BIMI VMC protocol layer, the SPF-lookup-limit spoke is the UPSTREAM- SPF-LEG-CORRECTNESS-PRECONDITION companion documenting the RFC 7208 §4.6.4 10-DNS-lookup ceiling whose violation produces the canonical spf=permerror verdict that propagates upward into the DMARC composite-fail outcome that structurally disqualifies the per-publisher per-domain message from BIMI indicator-rendering eligibility at the per-receiver per-message inbox-rendering boundary. The BIMI-vs-SPF- lookup-limit relationship is downstream-rendering- eligibility-vs-upstream-authentication-correctness: BIMI VMC indicator rendering requires DMARC pass at the per-receiver per-message authentication-results boundary (RFC 7489 §6.6.3 BIMI policy lookup gate); DMARC pass requires AT LEAST ONE of SPF-aligned-pass OR DKIM-aligned-pass (RFC 7489 §4 alignment evaluation); SPF-aligned-pass requires the publisher's v=spf1 TXT-record include-cascade to resolve under the RFC 7208 §4.6.4 10-DNS-lookup ceiling. Four BIMI-VMC- vs-SPF-lookup-limit coupling dimensions matter at the publisher-side authentication-publication-discipline layer: (i) per-publisher cumulative SPF include-cascade lookup cost — if the publisher's v=spf1 include:<esp1> include:<esp2> include:<esp3> -all cascade exceeds the 10-lookup ceiling, spf=permerror propagates to DMARC composite-fail which STRUCTURALLY DISQUALIFIES the message from BIMI indicator-rendering eligibility regardless of how perfectly the per-publisher per-domain VMC chain-of-trust is published; (ii) per-publisher per-domain SPF-aligned-pass-rate floor as BIMI-eligibility precondition — BIMI requires sustained DMARC-pass-rate at the per-receiver per-message inbox-rendering boundary, so the per-publisher SPF-aligned-pass-rate floor must be defended against include-cascade growth that pushes lookup cost toward the 10-budget ceiling; (iii) per-publisher SPF flattening discipline as load-bearing BIMI-rendering-eligibility protection — RFC 7208 §11.1.1 permerror treatment, SPF flattening to ip4: / ip6: literals, per-ESP include: consolidation, and per-zone v=spf1 TXT-record splitting across _spf.<domain> sub-zones all preserve the per-publisher SPF-aligned- pass-rate floor that defends BIMI VMC indicator- rendering eligibility; (iv) per-publisher BIMI VMC annual-renewal cadence vs SPF include-cascade drift coordination — VMC renewal annually re-attests the per-publisher per-domain brand identity, but between renewals an unmonitored SPF include-cascade drift from supplier-ESP changes can cross the 10-lookup ceiling and cascade into a per-receiver per-message BIMI indicator-rendering eligibility regression that no amount of VMC chain-of-trust publication discipline can rescue. Read THIS page when AUTHORING the per-publisher per-domain BIMI VMC chain-of-trust publication discipline; read the SPF-lookup-limit spoke when AUDITING the publisher-side SPF include-cascade against the RFC 7208 §4.6.4 10-DNS-lookup budget so the per-publisher per-domain SPF-aligned-pass-rate floor that defends BIMI indicator-rendering eligibility is preserved.
• How attackers bypass weak DMARC — the WEAK-DMARC-ATTACK-SURFACE-CATALOGUE companion to this BIMI VMC certificate- procurement reference. Where THIS page documents the VMC-vs-CMC certificate-type distinction, the two issuing CAs (DigiCert and Entrust), the PEM-bundle file format the BIMI record's a= URL serves, the 13-month VMC validity window, and the BIMI-logo-display contract at the receiving consumer inboxes (Gmail, Outlook, Apple Mail, Yahoo, Fastmail), the DMARC- attacker-bypass spoke catalogues the eleven attack-class taxonomy of how attackers bypass weak DMARC postures (direct From: identity spoofing, sp= subdomain-policy- gap exploitation, p=quarantine pct=N policy-mode partial-coverage exploitation, SPF +all/~all permissive-qualifier abuse, DKIM weak-key cryptanalysis + selector- rotation-window exposure, ARC-chain falsification, display-name impersonation cousin-domain attacks, infrastructure-level BGP-hijack DNS-takeover variants) that erode the per-publisher per-domain DMARC- pass-rate floor BIMI receivers consult AS LOAD-BEARING PRECONDITION before honouring the VMC logo render gate at the receiver- inbox indicator-rendering boundary. The per-publisher per-VMC investment ROI is structurally defensible only when the per- publisher per-domain DMARC posture defends against the attack-class catalogue at four BIMI-VMC-investment-vs-DMARC-attacker- bypass-surface coupling dimensions: (i) BIMI receiver-side DMARC-pass-rate gate as load-bearing render precondition — Gmail / Outlook / Apple Mail / Yahoo / Fastmail BIMI receivers require sustained DMARC- aligned-pass at p=quarantine or p=reject before the VMC a= URL is fetched and the indicator rendered, so any attack-class that erodes the per-publisher per-domain DMARC-pass-rate floor directly suppresses the per-publisher per-VMC indicator- rendering ROI; (ii) sp= subdomain-policy hardening discipline as VMC-eligibility hygiene — explicit sp=reject publication closes the subdomain-policy- gap attack-class that delivers attacker traffic on uncatalogued subdomains while suppressing the parent-domain DMARC posture receivers consult for VMC eligibility; (iii) DKIM selector-rotation cadence as per-publisher per-domain cryptographic- anchor freshness floor — the per-publisher per-domain DKIM key-rotation cadence defends against the DKIM-replay + DKIM- key-cryptanalysis attack-variants in the bypass catalogue, preserving the DKIM- aligned-pass-rate floor BIMI receivers measure across the per-publisher per-VMC renewal window; and (iv) per-publisher per-domain p=reject ramp- completion discipline as VMC-rendering- eligibility precondition — the BIMI consortium guidance recommends p=reject for maximum BIMI receiver participation, and the attacker-bypass catalogue is the per-publisher per-domain reference for which weak-policy-mode states the per- publisher per-domain MUST harden against before committing to p=reject. Read THIS page when AUTHORING the per-publisher per- domain VMC procurement + chain-of-trust publication discipline; read the DMARC- attacker-bypass catalogue spoke when AUDITING the per-publisher per-domain DMARC posture against the eleven attack- class catalogue the per-publisher per- domain MUST defend against to preserve the BIMI-eligibility DMARC-pass-rate floor THIS page's VMC investment depends on at the per-receiver per-message indicator- rendering boundary.
• DMARC reporting pipeline — the PER-PUBLISHER-PER-DOMAIN-DMARC- AGGREGATE-AND-FORENSIC-REPORT-INGESTION- PIPELINE-AS-LOAD-BEARING-OBSERVABILITY- SURFACE-FOR-VMC-BIMI-ELIGIBILITY-DMARC- ALIGNED-PASS-RATE-FLOOR-PRESERVATION companion to THIS BIMI VMC certificate- procurement reference. Where THIS page documents the per-publisher per-VMC X.509- certificate chain-of-trust procurement discipline (the per-publisher per-VMC Mark-Verifying-Authority MVA-issued certificate per the BIMI-VMC specification, the per-publisher per-VMC trademark- registered Mark verification, the per- publisher per-VMC a=-tag publication coordinating the per-publisher per-domain BIMI TXT-RR with the per-VMC HTTPS-served certificate URL, and the per- publisher per-VMC renewal-discipline floor coordinating per-VMC expiry with per- publisher per-domain BIMI-eligibility continuity), the DMARC-reporting-pipeline spoke documents the per-publisher per-domain RFC 7489 §7 aggregate-report consumption pipeline (per-receiver per-day per-publisher per-domain RUA aggregate-XML report parsing, per-source-IP per-record row dedup, per- receiver-organisation per-day per-publisher per-domain attribution storage) whose per- publisher per-domain DMARC-aligned-pass-rate observability surface the per-publisher per- VMC indicator-rendering eligibility floor materially depends on at FOUR per-publisher per-VMC-vs-DMARC-reporting-pipeline coupling dimensions: (i) per-publisher per- domain DMARC RUA aggregate-XML per-source-IP per-disposition row distribution as load- bearing per-publisher per-VMC indicator- rendering eligibility floor evidence — every per-receiver-organisation BIMI- supporting receiver (Gmail / Yahoo / Apple Mail / Fastmail) gates per-publisher per- VMC indicator-rendering on per-publisher per- domain DMARC-aligned-pass-rate floor (typical thresholds: p=quarantine+ or p=reject enforcement-posture plus high per-publisher per-domain DMARC- aligned-pass-rate sustained over rolling per-day windows), and the per-publisher per- domain RUA aggregate-XML ingestion pipeline THE DMARC-reporting-pipeline spoke documents is the per-publisher per-domain canonical observability surface producing the per-day per-receiver per-publisher per-domain DMARC- aligned-pass-rate evidence the per-publisher per-VMC indicator-rendering eligibility floor materially depends on; (ii) per-publisher per-domain DMARC RUF forensic-report per-message per-source-IP per-failure-reason attribution as per- publisher per-VMC indicator-rendering eligibility regression root-cause-attribution evidence — when per-publisher per- VMC indicator-rendering eligibility regresses (per-receiver-organisation BIMI-supporting receiver stops rendering the per-publisher per-VMC Mark indicator at the inbox-list boundary), the per-publisher per-domain RUF forensic-report stream THE DMARC-reporting- pipeline spoke ingests provides the per- message per-source-IP per-failure-reason attribution evidence the per-publisher per- domain operator needs to attribute the per- VMC indicator-rendering eligibility regression to specific per-source-IP per- message DMARC-misalignment root causes (per-publisher per-domain DKIM-selector key- rotation gap, per-publisher per-domain SPF- record include-cascade explosion, per-third- party-sender DKIM-signing-gap), unrecoverable without the per-publisher per-domain DMARC RUF forensic-report consumption discipline the DMARC-reporting-pipeline spoke documents; (iii) per-receiver per-day per- publisher per-domain DMARC RUA aggregate-XML per-source-IP per-disposition row trend analysis as per-publisher per-VMC indicator- rendering eligibility forecast observability surface — the per-publisher per- domain operator reads the per-receiver per- day per-publisher per-domain RUA aggregate- XML report-stream's per-source-IP per- disposition row rolling-window trend analysis to FORECAST per-publisher per-VMC indicator- rendering eligibility floor continuity ahead of per-publisher per-VMC renewal commitment, attributing forecast eligibility floor erosion to specific per-publisher per-domain DMARC-aligned-pass-rate regression root causes (per-publisher per-domain DKIM- aligned-pass-rate dip, per-publisher per- domain SPF-aligned-pass-rate erosion, per- publisher per-domain receiver-side disposition-classification drift) the per- publisher per-VMC operator MUST resolve BEFORE per-publisher per-VMC renewal commit; (iv) per-publisher per-domain DMARC reporting-pipeline ingestion-discipline-floor coordinating per-publisher per-VMC renewal- discipline-floor at the per-publisher per- domain operator's BIMI-eligibility-continuity governance boundary — the per- publisher per-domain operator coordinates per- publisher per-domain DMARC reporting-pipeline ingestion-discipline-floor (per-receiver per- day per-publisher per-domain RUA aggregate- XML ingestion continuity, per-publisher per- domain RUF forensic-report receipt-and-parse continuity, per-receiver-organisation per- day per-publisher per-domain attribution storage continuity) with per-publisher per- VMC renewal-discipline-floor at the per- publisher per-domain BIMI-eligibility- continuity governance boundary the per- publisher per-domain operator's BIMI VMC investment depends on. Read THIS BIMI VMC certificate-procurement reference when DEPLOYING the per-publisher per-VMC X.509- certificate chain-of-trust discipline AND when COORDINATING the per-publisher per-VMC renewal-discipline against per-publisher per- domain DMARC reporting-pipeline observability- surface evidence; read the DMARC-reporting- pipeline spoke when OPERATING the per- publisher per-domain RUA-and-RUF aggregate- and-forensic-report ingestion-and-parsing discipline against per-publisher per-VMC indicator-rendering eligibility-floor continuity preservation THIS page documents.
• SPF mechanisms explained — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-AUTHORING-DISCIPLINE-AS-LOAD- BEARING-ENVELOPE-MAIL-FROM-LAYER- AUTHENTICATION-INPUT-FEEDING-DMARC- ALIGNED-PASS-WHICH-IS-BIMI-RENDERING- ELIGIBILITY-PRECONDITION companion to THIS per-publisher per-VMC certificate- procurement reference. Where THIS page documents the per-publisher per-VMC X.509- certificate chain-of-trust binding discipline (per-publisher per-VMC issuer catalogue at DigiCert / Entrust / GlobalSign / Sectigo, per-publisher per-VMC SVG Tiny PS SHA-256-hash binding into the VMC certificate, per-publisher per-VMC 1-year validity period rotation cadence, per- publisher per-VMC trademark-validation organizational identity-proofing discipline, per-publisher per-VMC a=https://< d-domain>/vmc.pem publication binding cascade), the SPF-mechanisms- explained spoke is the PER-PUBLISHER-PER- DOMAIN-ENVELOPE-MAIL-FROM-LAYER- AUTHENTICATION-PUBLICATION companion at FOUR per-SPF-mechanism-authoring-vs-BIMI- VMC-indicator-rendering coupling dimensions: (i) per-publisher per-domain SPF- aligned-pass-rate floor AS load-bearing per-publisher per-domain envelope-MAIL- FROM-layer DMARC-aligned-pass evidence- stream input feeding per-publisher per- VMC BIMI indicator-rendering eligibility cascade precondition — the per-publisher per-domain SPF mechanism- choice the SPF-mechanisms-explained spoke documents IS the per-publisher per-domain envelope-MAIL-FROM-layer authentication- publication input feeding per-publisher per-domain DMARC-aligned-pass verdict the per-publisher per-VMC BIMI indicator- rendering eligibility cascade THIS page documents requires; per-publisher per- domain DMARC p=quarantine OR p=reject commitment IS the per-publisher per-VMC BIMI indicator- rendering eligibility cascade precondition, and per-publisher per-domain DMARC composite-verdict-pass requires per- publisher per-domain SPF-aligned-pass OR per-publisher per-selector DKIM-aligned- pass; (ii) per-publisher per- domain SPF include: cascade-depth audit discipline AS load-bearing per-publisher per-domain SPF-permerror-floor publication- discipline compressing per-publisher per- VMC BIMI-rendering-eligibility-cascade catastrophic-disruption risk — the per-publisher per-domain SPF include: cascade-depth audit discipline the SPF-mechanisms-explained spoke documents (per-publisher per-domain include: cascade-depth monitoring against the RFC 7208 §4.6.4 10-DNS-lookup cap, per-publisher per-domain include: cascade- membership audit cadence, per-publisher per-domain per-third-party-SaaS-sender ESP-include consolidation discipline) compresses per-publisher per-domain SPF- permerror catastrophic-disposition cascade which would otherwise per-publisher per- domain DMARC composite-verdict-fail cascade and per-publisher per-VMC BIMI indicator- rendering eligibility cascade disruption cascade against the per-publisher per-VMC cryptographic chain-of-trust binding discipline THIS page documents the per- publisher per-VMC operational discipline of; (iii) per-publisher per-domain SPF mechanism-publication operational- hygiene rhythm AS load-bearing per- publisher per-domain operational-discipline- coordinate with per-publisher per-VMC certificate-rotation operational-hygiene- rhythm — the per-publisher per-domain SPF mechanism-publication operational-hygiene rhythm the SPF- mechanisms-explained spoke documents (per- publisher per-domain quarterly SPF record- audit cadence + per-publisher per-domain monthly include: cascade-depth audit + per-publisher per-domain weekly per-source- IP egress-pool reconciliation) IS the per-publisher per-domain envelope-MAIL- FROM-layer operational-discipline-coordinate with the per-publisher per-VMC 1-year- validity-period certificate-rotation operational-hygiene-rhythm THIS page documents; per-publisher per-domain operators schedule BOTH per-publisher per- domain envelope-MAIL-FROM-layer + per- publisher per-VMC cryptographic-binding operational-discipline rhythms coordinated at the per-publisher per-domain unified- publication-and-cryptographic-binding- operational-hygiene-discipline boundary; (iv) per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT + BIMI + VMC publication-floor coordination AS load-bearing per-publisher per-domain operator-side unified-trust- signal-publication-discipline-floor — the per-publisher per-domain SPF mechanism-authoring publication discipline the SPF-mechanisms-explained spoke documents IS the load-bearing per-publisher per-domain envelope-MAIL-FROM-layer authentication-publication discipline leg of the per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT + BIMI + VMC publication-floor coordination posture the per-publisher per-VMC certificate-procurement discipline THIS page documents the per-publisher per-VMC cryptographic-binding leg of; per-publisher per-domain operators publish ALL SEVEN per-publisher per-domain protocol-layer publications coordinated at the per- publisher per-domain unified-trust-signal- floor publication-readiness boundary. Read THIS page when PROCURING the per-publisher per-VMC X.509-certificate chain-of-trust binding for per-publisher per-VMC BIMI indicator-rendering eligibility; read the SPF-mechanisms-explained spoke when AUTHORING the per-publisher per-domain envelope-MAIL-FROM-layer SPF mechanism- choice publication discipline whose per- publisher per-domain SPF-aligned-pass-rate floor IS the load-bearing per-publisher per-domain envelope-MAIL-FROM-layer authentication-publication input feeding per-publisher per-domain DMARC composite- verdict which IS the per-publisher per-VMC BIMI indicator-rendering eligibility cascade precondition THIS page documents the per-publisher per-VMC cryptographic- binding discipline of.
• DKIM DNS-TXT-RR byte-grammar
• SPF permerror vs temperror
• DMARC deployment checklist
• ARC (Authenticated Received Chain, RFC 8617) explained
• Reverse DNS PTR records
• DMARC for Office 365 hybrid — the per-publisher per-domain hybrid M365 DMARC-aligned-pass-rate floor THIS hybrid-deployment spoke documents IS the load-bearing upstream pre-condition for the per-publisher per-VMC BIMI indicator-rendering eligibility-cascade THIS page documents the per-publisher per- VMC cryptographic-binding discipline of — hybrid M365 deployments with on-prem Exchange dual-egress topology must baseline both egress legs' DKIM-aligned- pass-rate floor before per-publisher per-VMC BIMI VMC-issuance ACME-DNS-01- validation cascading per-publisher per- domain Brand-Indicator-eligibility ramp at the per-publisher per-domain composite hybrid-M365-deployment-and-BIMI-VMC- publication coordination boundary.
• DMARC for Microsoft 365 — the PER-M365-TENANT-PER-ACCEPTED-DOMAIN-DMARC-ENFORCEMENT-MODE-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-PRECONDITION-FOR-PER-PUBLISHER-PER-VMC-BIMI-INDICATOR-RENDERING-ELIGIBILITY companion at four per-M365-tenant per-accepted-domain DMARC-vs-BIMI-VMC-eligibility coupling dimensions: (i) per-M365-tenant per-accepted-domain DMARC p=quarantine/p=reject enforcement-mode publication-decision per RFC 7489 §6.3 IS the load-bearing per-tenant per-accepted-domain composite-verdict enforcement-floor whose terminal-stage publication directly gates per-publisher per-VMC BIMI Indicator-record brand-indicator-rendering eligibility per BIMI RFC 9716 §4.1 enforcement-mode prerequisite the per-publisher per-VMC PKI primer THIS page documents the cryptographic-binding discipline of; (ii) per-M365-tenant per-accepted-domain DMARC RUA aggregate-report-pipeline attribution-stream IS the load-bearing per-tenant per-day per-source-IP per-row attribution-evidence stream the per-publisher per-VMC BIMI Indicator-rendering cascade depends on as the per-tenant per-accepted-domain DMARC-aligned-pass-rate floor preservation evidence-stream; (iii) per-M365-tenant per-accepted-domain DMARC adkim=s/adkim=r alignment-mode publication-decision per RFC 7489 §3.1.1 IS structurally parallel per-tenant per-accepted-domain application-layer identifier-alignment publication-discipline to per-publisher per-VMC Verified Mark Certificate per-publisher per-domain alignment-binding cryptographic-trust-chain publication-discipline THIS page documents; (iv) per-M365-tenant per-accepted-domain DMARC publication-discipline drift (premature ramp surfacing as DMARC RUA aggregate-report-row attribution-distortion or stalled p=none publication-discipline drift surfacing as BIMI-eligibility regression) directly opens per-tenant per-accepted-domain BIMI Indicator-record brand-indicator-rendering eligibility cascade regression the per-publisher per-VMC PKI primer THIS page documents the per-receiver per-message cryptographic-binding-and-rendering integrity floor of.
• MTA-STS explained
• DKIM canonicalization — the PER-PUBLISHER-PER-SELECTOR-DKIM-APPLICATION-LAYER-CANONICALIZATION-ALGORITHM-CHOICE-PUBLICATION-DECISION-AS-LOAD-BEARING-PRECONDITION-FOR-PER-PUBLISHER-PER-VMC-BIMI-INDICATOR-RENDERING-ELIGIBILITY companion at four per-publisher per-selector DKIM-canonicalization-vs-BIMI-VMC-eligibility coupling dimensions: (i) per-publisher per-selector DKIM c=relaxed/relaxed vs c=simple/simple per RFC 6376 §3.4 canonicalization-algorithm publication-decision IS the load-bearing application-layer per-message body-hash byte-stream production-discipline whose receiver-side per-message DKIM-aligned-pass verdict directly gates per-publisher per-VMC BIMI Indicator-record brand-indicator-rendering eligibility per BIMI RFC 9716 §4.1 application-layer DKIM-aligned-pass prerequisite the per-publisher per-VMC PKI primer THIS page documents the cryptographic-binding discipline of; (ii) per-publisher per-selector DKIM canonicalization-drift between SMTP transit (forwarder header-whitespace-folding, mailing-list footer-injection, content-transform middleware) and per-receiver-side DKIM-verifier surfaces as dkim=fail body hash did not verify per RFC 6376 §3.9 + RFC 8601 §2.7.1 collapsing per-message DKIM-leg of DMARC composite-aligned-pass disjunction directly cascading into per-publisher per-VMC BIMI Indicator-rendering eligibility regression at the per-receiver per-message rendering boundary; (iii) per-publisher per-selector DKIM canonicalization-algorithm publication-decision IS structurally parallel application-layer cryptographic-byte-stream production-discipline to per-publisher per-VMC Verified Mark Certificate canonicalised-SVG SHA-256 hash-binding per RFC 3709 LogotypeExtn — both per-publisher per-domain cryptographic-byte-stream-production primitives produce per-message-and-per-asset canonical byte-streams the per-receiver per-message cryptographic-verification consumes for per-publisher per-domain composite application-layer authentication-and-rendering integrity floor; (iv) per-publisher per-selector DKIM canonicalization-mode publication-discipline drift (premature c=simple/simple publication-decision exposing per-message DKIM-leg fragility to forwarder whitespace-mangling, or stalled c=relaxed/relaxed publication-discipline drift surfacing as per-message body-hash mismatch under mailing-list footer-injection) directly opens per-publisher per-VMC BIMI Indicator-record brand-indicator-rendering eligibility regression the per-publisher per-VMC PKI primer THIS page documents the per-receiver per-message cryptographic-binding-and-rendering integrity floor of.
• DMARC aggregate (RUA) reports
• DMARC myths and misconceptions
• SPF DNS record syntax
• SPF for Google Workspace
• Email authentication glossary — the plain-language reference for every acronym this BIMI/VMC certificate page leans on. BIMI, VMC, CMC, DMARC enforcement, SPF/DKIM alignment and the Authentication-Results verdicts that gate Indicator eligibility are each defined there in one place — read the glossary when a term in this certificate reference needs grounding before you act on it.
• Phishing protection — the threat-context companion to this VMC reference. A verified BIMI logo only renders on DMARC-enforced mail whose alignment a phishing campaign spoofing the brand cannot reproduce, so the VMC investment documented here is ultimately an anti-phishing display payoff — read the phishing-protection guide for the full threat model the brand indicator defends against.
• TLS-RPT explained — the VMC and SVG assets behind a BIMI logo are fetched over HTTPS, and the authenticated mail that earns the logo travels SMTP hops that should be TLS-protected. SMTP TLS Reporting (RFC 8460) is the per-domain feedback channel that tells you when those transport-layer TLS handshakes fail — STARTTLS stripping, expired or mismatched certificates — before they erode the deliverability the BIMI investment depends on. Read the TLS-RPT primer to add transport-layer observability to the brand-indicator stack this page documents.
• SPF for Microsoft 365 — the aligned-pass-floor companion to this VMC reference for brands sending from Microsoft 365. A BIMI logo (and the VMC investment THIS page documents) only renders once the message earns a DMARC pass, and on an M365 tenant the SPF leg of that aligned pass is published as v=spf1 include:spf.protection.outlook.com -all. If the tenant's SPF include-cascade overruns the RFC 7208 §4.6.4 10-lookup cap into permerror, or the envelope-MAIL-FROM domain mis-aligns, the DMARC pass collapses and the brand indicator stops rendering — the VMC certificate is wasted on mail that cannot display it. Read the SPF-for-M365 spoke to keep the SPF half of the DMARC aligned-pass floor that gates BIMI eligibility healthy on a Microsoft 365 tenant.
• DKIM replay attacks — the VMC investment THIS page documents only pays off while the signing domain keeps a clean reputation, and a DKIM replay attacks that directly: an attacker re-mails a captured, validly-signed message of yours in bulk, so spam carrying YOUR brand indicator earns a DKIM pass and reaches inboxes. That erodes the sustained DMARC-pass reputation BIMI rewards and risks the logo rendering beside abuse. Bounding the replay window with a DKIM x= expiry and short selector rotation protects the authenticated-identity integrity the brand indicator is meant to advertise. Read the replay-attacks spoke to defend the reputation your VMC capitalises on.
• MTA-STS policy syntax — the VMC that authorises your BIMI logo is served over the WebPKI, and so is the https://mta-sts.<domain>/.well-known/mta-sts.txt policy file whose version / mode / mx / max_age fields this reference dissects — the same HTTPS-PKI-anchored transport discipline that keeps the SMTP hop carrying your branded mail from being STARTTLS-stripped. Read the policy-syntax spoke to harden the transport leg under your brand indicator.
• 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 + VMC setup now

DMARC Analyzer's free Domain Security Checker performs live BIMI record lookups, confirms the l= SVG URL is reachable over HTTPS, and surfaces missing or expired VMC certificates at the a= URL. 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 paying for a VMC.

Audit my BIMI record Sign up — Free plan