DMARC Analyzer

TL;DR

• SVG Tiny PS (Portable/Secure) is the strict SVG sub-profile that BIMI logos MUST conform to. It is profiled by the BIMI Group SVG profile specification on top of SVG Tiny 1.2.
• Root <svg> MUST declare version="1.2", baseProfile="tiny-ps", xmlns="http://www.w3.org/2000/svg", and a square viewBox (1:1 aspect).
• A <title> element is REQUIRED as the FIRST child of <svg>, containing the company name (accessibility + validator check).
• Forbidden categorically: <script>, event handlers (onload, onclick), <a> hyperlinks, <animate> / <animateMotion> / SMIL, external references (<image href="...">, xlink:href to remote URLs, @font-face), <foreignObject>, embedded raster images (PNG/JPEG via <image>).
• File size cap: 32KB. Realistic optimization target with SVGO configured for Tiny PS is 4-8KB.
• Solid (non-transparent) background: the logo must render correctly against both light- and dark-mode inbox themes.
• SVG Tiny PS is what makes inline mailbox-UI logo rendering safe — it is the security and performance floor of the BIMI standard, not optional styling preferences.

1. What is SVG Tiny PS?

SVG Tiny PS (Portable/Secure) is a strict sub-profile of SVG Tiny 1.2 defined by the BIMI Group SVG profile specification. The profile strips everything from SVG that could be a security, privacy, rendering, or performance risk inside a mailbox UI: no scripts, no animation, no interactivity, no external references, no raster embedding, no foreign objects, and a narrow allow-list of filters and gradients.

The profile exists because a mailbox UI renders inbox logos inline alongside attacker-controlled content (mail messages). A full-featured SVG would be a category-A attack surface: scripts could exfiltrate inbox content, external references could leak the recipient's IP and email open status, animation could perform CPU-burn or denial-of-service attacks, foreign objects could escape the SVG sandbox. Tiny PS removes every one of those vectors so the logo is provably safe to render without further sanitization.

SVG Tiny PS is a logo file format, not a protocol primitive. It does not authenticate anything; it does not affect mail delivery. Its sole purpose is to be the rendered artefact at the end of a successful BIMI pipeline: DNS lookup returns the BIMI record, receiver fetches the SVG from l=, validates against the VMC at a=, and renders the SVG inline next to the message.

This page is the byte-by-byte file-format reference for SVG Tiny PS. For the protocol-level BIMI surface (DNS record syntax, VMC, mailbox-provider compatibility), see the BIMI pillar page.

2. Required root <svg> attributes

The root <svg> element MUST carry the following attributes. Validators reject the file if any are missing or carry a different value.

Optional but recommended attributes:

• preserveAspectRatio="xMidYMid meet" — explicitly center-aligns the rendered logo within the avatar slot. The default xMidYMid meet is what receivers apply anyway, but declaring it explicitly removes ambiguity.
• width / height — the BIMI Group profile does not require these on the root element (the receiver sizes the logo to the avatar slot regardless), but declaring them matching the viewBox dimensions does no harm and helps non-BIMI consumers of the file (file-manager thumbnails, editor previews).

3. Required structural elements

A compliant SVG Tiny PS file contains the following structural elements in document order:

1. XML declaration as the first line of the file: <?xml version="1.0" encoding="UTF-8"?>. Required for explicit encoding signalling. UTF-8 is the only accepted encoding.
2. Root <svg> element with the four required attributes listed in section 2.
3. First child: <title> containing the company name as plain text. The title element MUST come before any rendering element. (See section 7 for the accessibility rationale.)
4. Optional second child: <desc> for a longer description of the logo (extended alt-text). If present, MUST appear after <title> and before any rendering element.
5. Rendering elements in document order: <rect>, <circle>, <ellipse>, <line>, <polyline>, <polygon>, <path>, <text>, and grouping via <g>. Solid fills only — no external references.

No other top-level elements are permitted. The profile is deliberately minimal: every element that is in the file is one a malicious actor cannot abuse, because the abuse vectors have been excluded by the profile definition.

4. Forbidden elements

The following SVG elements are categorically forbidden in SVG Tiny PS. Validators reject the file if any are present.

5. Forbidden attributes

Even on otherwise-allowed elements, the following attributes are forbidden:

• Event handlers: onload, onclick, onmouseover, onmouseout, onkeydown, and every other on* attribute. Forbidden categorically — these are scripting attack surfaces.
• External xlink:href / href — any href attribute pointing to a remote URL (anything not starting with #) is forbidden because it leaks the recipient's IP when the receiver dereferences it.
• JavaScript URIs: href="javascript:..." in any form, including data URLs encoding JavaScript. Forbidden because they re-introduce scripting.
• data-* attributes carrying arbitrary application data. The Tiny PS profile prohibits author-defined metadata in the rendering tree.
• External fill / stroke references: fill="url(https://example.com/...)" is forbidden; only fragment references (fill="url(#id)") to a definition within the same file are allowed.

6. File constraints

Beyond the element / attribute allow-list, the BIMI Group profile imposes whole-file constraints:

7. Title and accessibility

Every BIMI-compliant SVG MUST contain a <title> element as the first child of the root <svg>. The title MUST contain the company name (or the brand name being rendered).

The title requirement serves two purposes:

• Accessibility: screen readers announce the title when the logo is rendered. Without a title, the logo is an unannotated image and assistive technology cannot describe it. WCAG 2.2 Success Criterion 1.1.1 (Non-text Content) requires text alternatives for meaningful images; the SVG <title> IS that text alternative for inline SVG.
• Validator compliance: the BIMI Group's reference validator checks for the presence of <title> as the first child of <svg> and rejects the file if it is missing.

Optionally, a <desc> element MAY follow <title> with a longer description of the logo (extended alt-text). The <desc> is exposed to assistive technology as a supplementary description.

Example title + desc:

<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 64 64">
  <title>Example Company</title>
  <desc>Stylised diamond mark representing Example Company's brand identity, used in customer communications since 2019.</desc>
  <rect width="64" height="64" fill="#0a3160"/>
  <path d="M8 32 L32 8 L56 32 L32 56 Z" fill="#ffffff"/>
</svg>

8. Color and background rules

SVG Tiny PS imposes color and background rules to ensure the logo renders correctly across mailbox UI themes (light, dark, high-contrast).

• Solid background REQUIRED: the logo MUST have a solid (non-transparent) background. The standard pattern is a full-bleed <rect> as the first rendering element after <title>, filling the entire viewBox with a solid brand color, then layering the logo paths on top. Transparent backgrounds risk an invisible-logo failure when the inbox theme matches the logo color.
• Solid fills preferred: single fill="#RRGGBB" or fill="rgb(R,G,B)" values are the safe choice. Solid fills render identically across all SVG implementations.
• Limited gradient support: <linearGradient> and <radialGradient> are technically allowed by SVG Tiny 1.2, but the Tiny PS profile narrows the allow-list. Complex gradients with many stops, gradient transforms, or spread methods often trip validators. Test every gradient against the BIMI Group validator before shipping.
• No CSS color names from extended palettes: stick to #RRGGBB hex notation. Some validators reject named colors (fill="rebeccapurple") outside the 16 HTML 4.01 base colors.
• No currentColor: the keyword inherits from the rendering context (the mailbox UI's CSS) and is not stable across receivers. Always declare an explicit color.
• No CSS opacity-based hiding: opacity="0" on rendering elements is treated as suspicious by some validators (potentially hidden malicious content). Remove any element rather than zero-opacity it.

9. Examples

9.1 Minimal compliant SVG Tiny PS

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

The minimum-shape Tiny PS file: explicit XML declaration, four required root attributes, <title> as first child, solid background fill, single vector path overlay, no forbidden elements or attributes. This file is well under 32KB (~250 bytes).

9.2 Compliant SVG with desc and grouping

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 128 128">
  <title>Acme Corp</title>
  <desc>Stylised A-mark in red on white square, in use since 2021.</desc>
  <rect width="128" height="128" fill="#ffffff"/>
  <g fill="#c0202c">
    <path d="M24 100 L64 24 L104 100 L88 100 L64 60 L40 100 Z"/>
    <rect x="52" y="78" width="24" height="8"/>
  </g>
</svg>

A slightly richer compliant file: optional <desc> for accessibility, <g> grouping for shared fill, multiple path / rect elements. Still well under 32KB (~400 bytes).

9.3 Common rejection — script element

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 64 64">
  <title>Example Company</title>
  <script type="application/ecmascript">
    // Even an empty script is rejected.
  </script>
  <rect width="64" height="64" fill="#0a3160"/>
</svg>

Validators reject this file with "scripts not allowed" or similar. Even an empty <script> element is forbidden; there is no exception for inert content. Remove the element entirely.

9.4 Common rejection — event handler

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 64 64"
     onload="void(0)">
  <title>Example Company</title>
  <rect width="64" height="64" fill="#0a3160"/>
</svg>

Validators reject this file because the root <svg> carries an onload attribute. All on* event handlers are forbidden categorically. Strip the attribute.

9.5 Common rejection — embedded raster

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 64 64">
  <title>Example Company</title>
  <image href="logo.png" width="64" height="64"/>
</svg>

Validators reject this file because <image> embeds raster content. The Tiny PS profile forbids raster embedding outright; the logo must be redrawn as vector paths. (Some SVG editors offer auto-trace from PNG; the output usually needs hand cleanup before it conforms to Tiny PS.)

9.6 Common rejection — non-square viewBox

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 200 80">
  <title>Example Company</title>
  <rect width="200" height="80" fill="#0a3160"/>
  <text x="100" y="50" font-family="sans-serif" font-size="32"
        fill="#ffffff" text-anchor="middle">EXAMPLE</text>
</svg>

Validators reject this file because the viewBox is rectangular (200x80, 2.5:1 aspect). Receivers render in a square avatar slot; rectangular logos crop badly. Redesign the logo as a square mark (favicon-style abbreviation, single glyph, or stylised symbol).

9.7 Common rejection — missing title

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

Validators reject this file because there is no <title> as the first child of <svg>. The title is required for accessibility (screen readers) and validator compliance. Add <title>Company Name</title> immediately after the opening <svg> tag.

10. Validation toolchain

A repeatable validation workflow before shipping a Tiny PS SVG to production:

1. Author or convert the SVG: either hand-author against the rules above, or run an existing SVG through the BIMI Group converter. The converter strips unsupported elements and rewrites the file in the canonical Tiny PS shape.
2. Optimize with SVGO: install SVGO and run with a Tiny-PS-aware config. Disable plugins that introduce forbidden elements (e.g. convertShapeToPath is fine, but removeXMLNS is NOT — Tiny PS requires the xmlns).
3. Verify the file with a Tiny PS validator: paste the optimized SVG into the BIMI Group validator. The validator reports the exact failure mode (element name, attribute name, line number) if anything is forbidden.
4. Confirm file size: check wc -c logo.svg shows under 32,768 bytes. If still over, re-examine the design for excessive path complexity, extraneous metadata, or whitespace bloat.
5. Serve from HTTPS with image/svg+xml: verify curl -I https://bimi.example.com/logo.svg returns Content-Type: image/svg+xml and a long-lived Cache-Control header.
6. Validate end-to-end via DMARC Analyzer's Domain Security Checker: the live DNS lookup confirms the BIMI record points to the correct SVG URL and that the URL responds correctly. Pair with a fresh test send to a Gmail / Apple Mail inbox to see the rendered result.

11. Common SVG Tiny PS mistakes

• Shipping an SVG exported from Illustrator / Figma / Sketch as-is. Design-tool SVG exports almost never conform to Tiny PS — they emit metadata blocks, gradients with extra attributes, masks, embedded fonts, editor-specific extensions. Always run through the BIMI Group converter or a Tiny-PS-aware SVGO config.
• Forgetting baseProfile="tiny-ps" on the root. Without this attribute the file is plain SVG Tiny, not Tiny PS; validators reject it. The attribute is the sole marker that opts the file into the profile.
• Forgetting the <title> element. Validators reject the file. Screen readers cannot describe the logo. Always make the title the FIRST child of <svg>.
• Non-square viewBox. Rectangular logos crop badly in the avatar slot or are rejected. Redesign as a square mark before shipping.
• Transparent background. The logo must render correctly against dark inbox themes. Add a full-bleed <rect> with a solid brand color as the first rendering element.
• Embedded raster (PNG / JPEG via <image>). Tiny PS forbids raster outright. Recreate the logo as vector paths.
• External @font-face for text rendering. Forbidden because of the IP-leak / tracking vector. Convert text to outlined paths at authoring time.
• JavaScript event handlers (onload, onclick). Forbidden categorically. Strip all on* attributes.
• File size over 32KB. The profile cap. Run SVGO; consider simplifying the design if it persists above the cap after optimization.
• Serving over plain HTTP. The l= URL in the BIMI record MUST be HTTPS. Some receivers ignore HTTP-to-HTTPS redirects; declare HTTPS in the record itself.
• Updating the SVG without re-issuing the VMC. The VMC cryptographically binds to the exact SVG bytes; any change invalidates the binding and breaks logo display until the VMC is re-issued. Plan SVG updates as joint SVG + VMC re-issuance — see the BIMI pillar page for the VMC re-issuance workflow.

12. Frequently Asked Questions

What is SVG Tiny PS?

SVG Tiny PS (Portable/Secure) is a strict subset of SVG Tiny 1.2 defined by the BIMI Group for inbox-rendered brand logos. It forbids scripts, animation, external references, raster image embedding, interactivity, hyperlinks, foreign objects, and most filters. The root svg element must declare baseProfile="tiny-ps" and version="1.2". Tiny PS is designed so the logo can be rendered inline in a mailbox UI without any security, privacy, or performance risk.

What attributes are required on the root svg element?

A BIMI-compliant SVG must declare version="1.2", baseProfile="tiny-ps", xmlns="http://www.w3.org/2000/svg", and a viewBox with a 1:1 (square) aspect ratio on the root svg element. Validators reject the file if any of these are missing or carry a different value. The baseProfile="tiny-ps" attribute is the marker that opts the file into the BIMI strict profile.

What is the maximum file size for a BIMI SVG logo?

The BIMI Group profile caps the SVG file size at 32KB. The cap exists so the mailbox UI can render the logo inline without delaying inbox paint. A realistic optimization target for a brand mark is 4-8KB after running SVGO with a Tiny-PS-aware configuration; if your logo is still over 32KB after optimization, the design is too complex for the Tiny PS profile and needs simplification.

Does the SVG need a title element?

Yes. The Tiny PS profile REQUIRES a <title> element as a direct child of the root svg element, containing the company name. This serves two purposes: accessibility (screen readers announce the title when the logo is rendered) and validator compliance (BIMI Group validators check for its presence). The title element must be the FIRST child of svg, before any rendering element.

Why must the SVG have a square viewBox?

Mailbox UIs render the BIMI logo in a square avatar slot (the same UI affordance Gmail, Apple Mail, and Yahoo use for the contact avatar). A non-square viewBox is either cropped to square or rejected outright by validators. The canonical viewBox is "0 0 64 64" or any other equal-width/equal-height pair. Width and height attributes on the root svg are optional; the viewBox is what defines the rendering surface.

Can a BIMI SVG embed a PNG or JPEG?

No. The Tiny PS profile categorically forbids raster image embedding via the SVG <image> element. The logo must be expressed as pure vector paths (path, rect, circle, polygon, etc.) with solid fills. This rule exists because embedded raster content defeats the purpose of SVG (resolution independence, small file size, security) and historically was an attack vector for malicious payload delivery via SVG.

Can I use gradients in a BIMI SVG?

Linear and radial gradients are technically allowed by SVG Tiny 1.2 but the BIMI Group profile narrows the allow-list substantially. Solid fills (single fill="#RRGGBB" values) are the safe choice and what every major brand uses in production. Complex gradients with multiple stops or gradient transforms often trip validators; if you need a gradient effect, test the file against the BIMI Group validator before committing to the design.

Does the SVG need a solid background?

Yes. The BIMI Group profile requires the logo to render correctly against both light-mode and dark-mode inbox themes. A transparent background risks an invisible-logo failure when the inbox theme matches the logo color. The standard pattern is a full-bleed <rect> element as the first rendering element after <title>, filling the entire viewBox with a solid brand color, then layering the logo path on top.

Why is my SVG rejected for "scripts not allowed"?

The SVG contains a <script> element or an event-handler attribute (onload, onclick, onmouseover, and similar). The Tiny PS profile forbids these categorically; there is no exception, even for empty handlers. Common causes are: (1) the SVG was exported from Illustrator or Figma with default settings (they emit metadata that sometimes includes script-like content), (2) the SVG was hand-edited from a template that included interactivity, (3) the SVG was minified by a non-BIMI-aware tool that left event-handler attributes intact. Run the file through the BIMI Group converter or strip the offending elements manually.

Why is my SVG rejected for "external references"?

The SVG contains a reference to an external resource — most commonly an <image> element with an href pointing to a CDN, an xlink:href referencing a remote SVG fragment, or a @font-face declaration pulling a custom font from a remote URL. The Tiny PS profile forbids external references because they would defeat the inline-render security model (every fetch is a potential tracking pixel or malicious payload). All resources must be inlined or expressed as vector paths.

13. 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), mailbox-provider compatibility, and the DMARC prerequisite. Start there if you have not yet published a BIMI record.
• BIMI Verified Mark Certificates (VMC and CMC) — the certificate-half companion to this SVG-half page. The BIMI record's l= tag points to the SVG file this page documents; the a= tag points to the Verified Mark Certificate the certificates page documents. Both URLs must serve their respective resources over HTTPS with a public-PKI chain before Gmail / Apple Mail / Yahoo / Fastmail will display the logo. Where this page documents the SVG Tiny PS profile constraints (the <baseProfile> attribute, the <title> element, the forbidden element list, the 1:1 viewBox, the file-size ceiling, the colour-space and scripting prohibitions), the certificates page documents the trademark-evidence pack, the two issuing CAs (DigiCert and Entrust), the VMC vs CMC distinction, the PEM bundle format, the 12-month renewal cadence, and the pricing landscape. Read alongside this page when assembling the complete BIMI deployment — the SVG file alone will not unlock the logo at any major VMC-requiring inbox without the matching certificate.
• MTA-STS for Google Workspace — the PARALLEL-HTTPS-PUBLISHED-RESOURCE- WITH-PUBLIC-PKI-CHAIN-REFERENCED-BY-DNS- RECORD companion to this BIMI SVG-Tiny-PS requirements reference. Where THIS page documents the BIMI SVG-Tiny-PS resource publication discipline (the l=-tag URL the operator publishes in the BIMI DNS record pointing to an HTTPS-served SVG file, the baseProfile / viewBox / element-allow-list constraints, the public-PKI HTTPS chain requirement, the CDN-cache and inbox- provider-cache considerations governing WHEN a freshly-published SVG renders at Gmail / Apple Mail / Yahoo / Fastmail), the MTA-STS-for-Workspace spoke documents the STRUCTURALLY-PARALLEL HTTPS-published Workspace-tenant transport-policy resource at FOUR structurally-analogous cross- protocol publication-coordination dimensions: (i) HTTPS-served resource with public-PKI chain requirement at parallel publication boundaries — BIMI publishes the SVG at the operator-controlled l=<url> with a public- PKI HTTPS certificate the inbox provider validates before logo render; Workspace MTA-STS publishes the policy file at the operator-controlled https://mta-sts.<workspace- tenant>/.well-known/mta-sts.txt with a public-PKI HTTPS certificate the sending MTA validates before policy-trust (RFC 8461 §3.3 mandates the policy file be served over HTTPS with a publicly- trusted CA chain); BOTH require the same public-PKI hosting discipline — Workspace operators completing the BIMI deployment this page describes have already operationalised the HTTPS-with-public- PKI-cert hosting pattern THIS page documents for the SVG, and the MTA-STS spoke documents the parallel pattern for the policy file at a different sub-domain; (ii) DNS-record- referenced indirection model at parallel TXT-record publication boundaries — BIMI's DNS publication at default._bimi.<domain> IN TXT "v=BIMI1; l=<svg-url>; a=<vmc- url>" publishes URL-pointers to the HTTPS-hosted SVG + VMC at the BIMI publication boundary; Workspace MTA-STS publishes the parallel _mta-sts.<workspace-tenant> IN TXT "v=STSv1; id=<timestamp>" publication where the id= identifier serves as the structural equivalent of BIMI's l= pointer — bumping the BIMI l= URL triggers a fresh SVG fetch at the inbox provider, bumping the MTA-STS id= identifier triggers a fresh policy-file fetch at the sending MTA; (iii) CDN / cache-coordination at parallel cache- layer boundaries — BIMI SVG rendering at Gmail / Apple Mail / Yahoo / Fastmail involves inbox- provider-side image-CDN caches with independent invalidation cadences; MTA- STS policy retrieval at sending MTAs (Microsoft EOP, Postfix, Gmail-Send-MTA) involves per-MTA HTTPS-fetch caches with max_age-controlled invalidation cadences; BOTH systems present the structural challenge of updating an HTTPS-hosted resource AND invalidating the per-consumer cache layer atomically — the BIMI SVG operator's cache-coordination playbook the inbox-provider-side surfaces directly mirrors the MTA-STS policy operator's cache-coordination playbook the sending-MTA-side surfaces; (iv) per-Workspace-tenant joint publication-quality KPI pair: BIMI publish-quality vs MTA-STS publish- quality — a Workspace tenant publishing BOTH BIMI (for logo display at Gmail inbox) AND MTA-STS (for transport-security at Workspace inbound) surfaces a joint per-Workspace- tenant DNS-record-AND-HTTPS-host publication-quality KPI pair (BIMI SVG-render-success-rate at inbox- provider-side AND MTA-STS policy- fetch-success-rate at sending-MTA-side) — the joint KPI surfaces the Workspace operator's overall HTTPS-published- resource hosting discipline at the customer-controlled-DNS-zone-and-HTTPS- host publication-pipeline-health boundary. Read the MTA-STS-for- Workspace spoke as the parallel transport-security-cluster sibling to this BIMI-SVG-requirements reference — Workspace operators completing the BIMI deployment described on this page have already mastered the HTTPS-resource- publication-with-public-PKI-chain discipline the Workspace MTA-STS spoke also requires for the transport-layer policy publication.
• DMARC explained — the policy + reporting standard BIMI builds on top of. BIMI 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.
• 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 BIMI deployment.
• CAA records explained - the BIMI-VMC-X.509-CERT-ISSUANCE-CA- AUTHORITY-PERMISSION-GATING companion to this BIMI SVG-requirements reference. Where THIS page documents the SVG-Tiny-PS asset- publication requirements (the <svg> root-element profile constraints, the BIMI-Group-published SVG-Tiny-PS subsetting rules forbidding scripts / external resources / animation, the baseProfile attribute, the viewBox + width + height attribute requirements, the X.509 logotype-extension binding to the SVG asset hash), the dedicated CAA-records spoke documents the STRUCTURALLY-DISTINCT cert-issuance-authority publication discipline that the BIMI VMC cert + the SVG-host HTTPS cert BOTH structurally depend on at FOUR BIMI-SVG- specific CAA coordination dimensions: (i) BIMI VMC issuance is restricted to a small set of BIMI-Group-approved issuing CAs (currently DigiCert and Entrust) - the publisher's CAA record at the domain apex MUST permit one of these BIMI-VMC-issuing CAs (e.g. 0 issue "digicert.com") for the VMC issuance to succeed at the certificate-application step; the CAA-records spoke documents the BIMI-Group- approved-issuing-CA catalogue and the CAA- record-publication discipline the publisher must satisfy BEFORE applying for the VMC cert; (ii) parallel SVG-host HTTPS cert issuance at the https://<svg-host>/<path>.svg URL referenced by the publisher's BIMI l= tag requires CAA permission at the SVG-host's effective DNS owner-name for the SVG-host-cert-issuing CA (typically Let's Encrypt via ACME-DNS-01 or HTTP-01) - the publisher must coordinate TWO cert-issuance-authority publications: the BIMI-VMC issuer at the domain apex AND the SVG-host HTTPS cert issuer at the SVG-host's effective owner-name; the CAA-records spoke documents the dual- cert-issuance-authority CAA-coordination discipline BIMI deployment requires; (iii) BIMI publication conventions use the default._bimi.<domain> or per-selector <selector>._bimi.<domain> sub-owner-name for the BIMI TXT record and the SVG-host's CAA records may be published at the SVG-host's own effective domain rather than at the publisher's domain - the per-subdomain-vs-apex-of-zone CAA-inheritance rule (RFC 8659 §3 climb- up-the-zone algorithm) determines which zone's CAA records gate the SVG-host cert issuance for a BIMI deployment using a third-party SVG-host CDN; the CAA- records spoke documents the per-subdomain CAA-inheritance algorithm and the BIMI- specific publication-host-vs-publisher- domain CAA scoping discipline; and (iv) RFC 8659 §4 CAA-record extensions for accounturi + validationmethods tags enable per-CA account-bound automated cert renewal that the BIMI publisher uses for the SVG-host HTTPS cert (ACME-DNS-01-validated automated renewal at scale) - the per-account-binding CAA-extension publication discipline limits cert issuance to the publisher's specific CA account, providing an additional anti- attacker-cert-issuance defense beyond the baseline issue= permission tag that BIMI publishers running automated SVG-host cert renewal commonly adopt; the CAA-records spoke documents the accounturi-vs-validationmethods extension publication discipline as the per-CA account-bound automation contract BIMI deployment routinely consumes. Read the dedicated CAA-records spoke alongside this BIMI SVG-requirements page when scoping the cert-issuance-authority publication discipline for a BIMI deployment that requires both the BIMI-VMC at the publisher domain AND the SVG-host HTTPS cert at the SVG-host effective domain - the spoke is the authoritative RFC 8659 CAA-record reference whose four BIMI-VMC-and-SVG-host CAA-coordination boundaries this BIMI SVG requirements page is the cert-binding- asset companion for.
• DMARC for Microsoft 365 — the M365-TENANT-DMARC-POSTURE-AS- BIMI-DISPLAY-PRECONDITION companion to this BIMI SVG asset-format reference. Where THIS page documents the SVG Tiny PS asset-format byte-level specification (1:1 aspect-ratio viewBox, Tiny PS profile constraints, no scripts / animation / external resources, RGB-only color, 32KB ceiling, base64 inline embedding, VMC chain validation), the M365- deployment spoke is the PER-M365- TENANT DMARC-POSTURE-PUBLICATION REFERENCE documenting how the M365 cloud-only tenant DMARC deployment is the PUBLISHER-SIDE PRECONDITION the BIMI-display evaluator at receiver- side consumes BEFORE fetching the published SVG asset. Concretely the spoke documents FOUR per-M365-tenant- configuration-vs-BIMI-display- eligibility dimensions: (i) per-M365-tenant DMARC enforcement-tier publication discipline is the BIMI-display- prerequisite publisher-side gate — the M365-deployment spoke documents the per-tenant _dmarc.<org-domain> TXT-RR p=-tag publication discipline every Exchange Online operator must advance to BEFORE the BIMI-display evaluator at receiver- side fetches the published SVG asset — Apple iCloud Mail iOS 16+ requires p=reject, Gmail / Yahoo require p=quarantine at minimum, and pct=100 is a hard precondition; (ii) per- M365-tenant CNAME-delegation DKIM- publication-discipline is the BIMI- display 90-day-rolling-pass-rate precondition driver — the BIMI-display evaluator at receiver- side maintains a per-Friendly-From- org-domain 90-day rolling DMARC-pass- rate KPI it consults BEFORE fetching the published SVG asset, and the per- M365-tenant selector1-<tenant>._domainkey.<org-domain> + selector2-<tenant>._domainkey.<org-domain> CNAME-delegation publication discipline the M365-deployment spoke documents is the per-tenant DKIM- signing-coverage operational invariant that drives the 90-day rolling pass- rate above the BIMI-display eligibility threshold; (iii) per-M365-tenant tenant.onmicrosoft.com default-domain unconfigured-CNAME- delegation gotcha is the BIMI-display DMARC-non-alignment failure-mode — the M365-deployment spoke documents how per-tenant unconfigured default-domain CNAME-delegation produces dkim=pass with policy_evaluated.dkim=fail DMARC-non-aligned verdicts that STRUCTURALLY BLOCK the per-domain BIMI-display 90-day rolling pass-rate from reaching the BIMI-eligibility threshold every Exchange Online operator must close BEFORE the BIMI SVG asset publication this page documents delivers display value; and (iv) per-M365-tenant Exchange Online Protection cloud- egress IP-pool DKIM-signing- infrastructure-stability dependency is the BIMI-display steady-state operational invariant — the M365-deployment spoke documents how the per-tenant EOP-cloud-egress IP- pool DKIM-signing availability is the per-tenant BIMI-display-coverage steady-state operational invariant every Exchange Online operator must monitor via aggregate-report stream because per-tenant transient EOP- side signing-infrastructure outage produces a transient 90-day rolling pass-rate drop that the BIMI-display evaluator at receiver-side consumes as a structural display-eligibility downgrade against the SVG asset this page documents. Read the M365- deployment spoke ALONGSIDE this BIMI SVG asset-format reference when authoring the M365 BIMI-display deployment runbook — the spoke documents the M365-tenant DMARC- posture PUBLISHER-SIDE PRECONDITION every Exchange Online operator must satisfy BEFORE the BIMI-display evaluator at receiver-side fetches the published SVG asset.
• TLS-RPT JSON report format — the BIMI-SVG-ASSET-HTTPS-DELIVERY- AS-TRANSPORT-LAYER-TLS-DOWNGRADE- OBSERVABILITY-CONSUMER-OF-PER-DOMAIN- TLS-RPT-JSON-REPORT-FORMAT companion to this BIMI-SVG asset-format-publication reference. Where THIS page documents the per-domain SVG Tiny Portable/Secure 1.2 asset-byte-grammar (no scripting, no external references, embedded only per <use> / <defs>, the baseProfile="tiny-ps" declaration, the indicator-mark byte- size budget, the x="0" y="0" width="0 0 W H" viewBox publication, the preserveAspectRatio="xMidYMid meet" binding) every BIMI publisher must publish at the https://<l-uri-host>/<path>.svg endpoint for per-receiver display- evaluator fetch, the TLS-RPT JSON report-format spoke is the TRANSPORT-LAYER-TLS-DELIVERY-FAILURE- OBSERVABILITY companion documenting the RFC 8460 §4 JSON report grammar whose per-failure-class catalogue is the load-bearing observability surface for per-receiver BIMI-SVG-asset HTTPS- fetch TLS-handshake-failure attribution. The four-axis BIMI-SVG- ASSET-DELIVERY-VS-TLS-RPT-FAILURE-CLASS comparison exposes the structurally- distinct per-receiver BIMI-SVG-HTTPS- delivery vs per-domain TLS-RPT-JSON- report coupling: (i) the BIMI- SVG-asset endpoint at https://<l-uri-host> requires receiver-side HTTPS handshake success with a publicly-trusted CA- anchored cert for the asset-fetch leg; TLS-RPT's JSON certificate-host-mismatch / certificate-expired / certificate-not-trusted failure-class entries are the per-receiver-attribution observability primitive surfacing every BIMI-SVG- asset HTTPS-fetch cert-validation failure operators must triage; (ii) BIMI-SVG-asset delivery depends on receiver-side STARTTLS availability at the originating SMTP exchange for the parent message to reach the BIMI-display evaluator AT ALL; TLS-RPT's starttls-not-supported / sts-policy-fetch-error failure-class entries are the load-bearing per-receiver observability surface for upstream TLS-handshake-collapse events the BIMI-display evaluator never sees because the parent message never arrives; (iii) BIMI's per-publisher cross-layer per-receiver observability stack — TLS-RPT at transport-layer asset-delivery + DMARC rua at message-layer authentication- result + DMARC ruf at per-message forensic-evidence + BIMI's own evidence=... per-receiver-display telemetry — produces a coherent per- receiver BIMI-display-eligibility evaluation trace at every per-receiver-tenant boundary; (iv) the per-publisher _smtp._tls.<d> TXT-RR publication binding the per-domain TLS-RPT report-collector to the publisher's domain mirrors the per-publisher default._bimi.<d> TXT-RR publication binding the per-domain BIMI-SVG-asset endpoint to the publisher's domain — both are per-publisher per-domain TXT-RR publication-disciplines whose per-receiver telemetry-attribution is consumed by every per-receiver BIMI-display evaluator and per- domain TLS-RPT-report-aggregator respectively. Read the TLS-RPT JSON-report-format spoke alongside this BIMI-SVG asset reference when scoping the per-publisher BIMI- delivery observability stack — the spoke documents the per-failure-class JSON-report grammar that surfaces every BIMI-SVG-asset HTTPS-fetch TLS-handshake collapse and every upstream STARTTLS-availability failure the BIMI-display evaluation pipeline structurally depends on.
• DKIM cryptography basics — the per-publisher per-selector DKIM cryptographic-key-strength as load-bearing upstream cryptographic-authentication prerequisite for BIMI VMC issuance AND per-receiver logo-display-gate companion to this BIMI SVG Tiny PS asset-format requirements reference. Where THIS page documents the per-publisher per-domain BIMI SVG asset-format byte-level specification (SVG Tiny PS profile, 1:1 aspect-ratio viewBox, baseProfile="tiny-ps", scriptless, animation-free, RGB-only color, 32KB ceiling, base64-encoded for inline embedding, VMC X.509 trust-chain binding), the DKIM cryptography-basics spoke documents the per-publisher per- selector cryptographic-authentication primitive whose sustained per-publisher per-domain key-strength baseline, per- publication correctness, and per-rotation overlap-window discipline together produce the per-publisher per-domain DKIM-aligned-pass DMARC verdict whose sustained per-publisher per-domain coverage rate is the LOAD-BEARING upstream cryptographic-authentication precondition every per-publisher per- domain BIMI VMC issuance-readiness and per-receiver per-message BIMI-logo- display-gate evaluation consumes. Four DKIM-CRYPTOGRAPHY-VS-BIMI-VMC-AND- DISPLAY-GATE cross-correlation axes the cryptography-basics spoke documents: (i) per-publisher per-selector RSA- 2048 cryptographic-key-strength baseline STRUCTURALLY DETERMINES VMC-issuance- readiness X.509 trust-chain binding — Mark Verifying Authorities (DigiCert, Entrust, IdenTrust) require per-publisher per-domain demonstrated DMARC-enforcement (p=quarantine or p=reject) with sustained DKIM-aligned-pass coverage BEFORE issuing a Verified Mark Certificate binding the publisher's SVG Tiny PS logo to the per-publisher per-domain identity; a per- publisher per-selector sub-1024-bit RSA key degrades the per-domain DKIM-aligned- pass coverage rate below the VMC- issuance-readiness floor; (ii) per- publisher per-selector DKIM-aligned-pass coverage rate STRUCTURALLY DETERMINES the per-receiver BIMI-logo-display rate the SVG asset is rendered at — the per-receiver per-message BIMI display evaluator consumes the per-message DKIM- aligned-pass DMARC verdict as the LOAD- BEARING upstream cryptographic- authentication precondition for SVG-asset fetch + render; a per-publisher per- selector public-key DNS-publication regression (truncated p= tag, missing trailing zero-byte, retired- selector not republished) produces per- receiver dkim=permerror verdicts that collapse the per-domain DKIM-aligned-pass coverage rate AND the per-receiver BIMI-logo-display rate at Yahoo / Gmail / Apple Mail / Fastmail; (iii) per-publisher per-selector DKIM key-rotation cadence INTERACTS with per-VMC certificate-renewal cadence + per- receiver BIMI-SVG-display gate — a per-publisher per-selector DKIM key- rotation without adequate overlap-window produces a per-day per-selector dkim-pass coverage cliff that degrades the per- publisher per-domain DMARC-enforcement baseline AND degrades the per-receiver BIMI-logo-display rate over the rotation- overlap window; per-publisher per-domain per-VMC certificate-renewal cycles MUST be coordinated with per-selector DKIM rotation cycles to preserve the per- receiver BIMI-display continuity contract; (iv) per-publisher per-selector DKIM cryptographic-algorithm choice (rsa-sha256 vs ed25519-sha256) INTERACTS with per-VMC X.509 cryptographic-algorithm binding AND per-receiver BIMI-SVG-display gate verifier-coverage — the per-publisher per-selector DKIM signature algorithm choice per RFC 8463 has uneven per-receiver verifier-coverage; per- publisher per-domain dual-algorithm DKIM publication (RSA-2048 + Ed25519 per selector pair) is the per-publisher per- domain cryptographic-algorithm posture every per-publisher per-domain BIMI-VMC- ready deployment requires to preserve the per-receiver BIMI-display rate at Apple Mail / Fastmail / Yahoo / Gmail simultaneously. Read THIS page when AUTHORING the per-publisher per-domain BIMI SVG Tiny PS asset for per-receiver logo display; read the DKIM cryptography- basics spoke when AUDITING the per- publisher per-selector cryptographic- authentication baseline whose RSA-2048 key-strength, per-publication correctness, per-algorithm choice, and per-rotation overlap-window discipline together produce the per-publisher per-domain DKIM-aligned- pass DMARC verdict whose sustained per- publisher per-domain coverage rate is the LOAD-BEARING upstream cryptographic- authentication precondition the BIMI VMC issuance-readiness evaluation AND the per-receiver per-message BIMI-logo- display gate consume.
• Business Email Compromise (BEC) — the per-attacker per-target-domain IMPERSONATION-ATTACK-THREAT-MODEL companion to this per-publisher per- domain BIMI SVG Tiny PS asset- requirements reference. Where THIS page documents the per-publisher per- domain BIMI SVG Tiny PS asset publication discipline (the SVG 1.2 Tiny PS profile constraints, the per-image byte-size cap, the per-receiver HTTPS-served SVG-asset cache discipline), the BEC spoke documents the per-attacker per- target-domain BEC attack-vector catalogue (CEO-impersonation wire- transfer-fraud attacks, vendor- impersonation invoice-redirect attacks, payroll-redirect attacks targeting HR mailboxes) whose per- receiver detection-pathway the per- publisher per-domain BIMI SVG-logo display gate this page documents SUPPORTS as the per-receiver per- message VISUAL-ANTI-IMPERSONATION- SIGNAL that elevates the per-recipient in-inbox heuristic discrimination between authentic per-publisher per- domain messages and BEC-attacker spoofed impersonation messages. Read the BEC spoke when MOTIVATING the per- publisher per-domain BIMI VMC-and- SVG-asset publication-discipline investment as a per-receiver per- recipient anti-impersonation visualization signal that STRUCTURALLY-COMPLEMENTS the per- publisher per-domain DMARC enforcement gating BIMI eligibility per RFC 9165 §3.
• DNS Record Generator — interactive wizard for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records with syntax validation.
• 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.
• 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 PER-SELECTOR-DKIM-KEY-PUBLICATION- LIFECYCLE-DISCIPLINE companion to this per-publisher per-domain BIMI SVG Tiny PS asset-publication reference. Where THIS page documents the per-publisher per- domain BIMI SVG Tiny PS publication discipline (the per-publisher SVG-asset production-and-validation cadence, the per-publisher per-domain default._bimi.<domain> TXT-RR l=-tag pointing to the SVG asset, the per-publisher per- domain VMC indicator chain-of-trust), the DKIM key rotation spoke is the PER-SELECTOR-DKIM-KEY-PUBLICATION- LIFECYCLE companion documenting the STRUCTURALLY-PEER per-publisher per- domain authentication-and-display publication-asset lifecycle discipline: both surfaces are per-publisher per- domain published assets the operator rotates on a cadence to manage key-or-asset compromise risk and operational drift. (i) Per- publisher per-domain BIMI SVG-asset rotation discipline (the SVG asset, the VMC certificate, the BIMI TXT-RR l= / a= tag pair) is rotated when the brand mark updates, when the VMC expires (typically annually), or when a per-publisher rebrand changes the displayed indicator — the publication-asset shape and lifecycle is DOCUMENTED at THIS page; (ii) Per-selector DKIM key rotation discipline (the public-key p= tag, the per-selector <selector>._domainkey.< domain> TXT-RR) is rotated on an annual cadence per RFC 6376 operator best-practice and per compromise-recovery emergency-rotation protocol — the publication-asset shape and lifecycle is documented at the DKIM key rotation spoke. The two publication-asset lifecycles compose: both rely on the per-publisher per- domain DNS-publication-and-fetch discipline THIS page's BIMI byte- grammar reference and the DKIM key rotation spoke's selector byte- grammar reference establish; (iii) the per-publisher per-domain BIMI indicator-display discipline requires the per-publisher per-domain DMARC verdict to PASS — which in turn requires the per-selector DKIM key rotation discipline THIS page's DKIM key rotation spoke documents to keep the per-selector signing key valid and the per-message DKIM-Signature header cryptographically verifiable; a per-selector key rotation failure cascades into per-message DKIM-verdict regression, which cascades into per-message DMARC-verdict regression, which cascades into per-recipient BIMI-indicator suppression (the receiver-side mail client does NOT display the per-publisher BIMI indicator on mail that fails the DMARC verdict). Read THIS page when AUTHORING the per-publisher per- domain BIMI SVG Tiny PS asset- publication discipline; read the DKIM key rotation spoke when AUTHORING the per-selector DKIM key-publication lifecycle discipline whose validity is the FOUNDATIONAL DMARC-verdict-pass prerequisite the per-publisher per- domain BIMI indicator-display per-recipient surface THIS page documents depends on.
• DKIM failures explained — the per-recipient per-message DKIM-VERDICT-CATALOGUE companion documenting the seven canonical receiver-side Authentication-Results verdicts (dkim=none / neutral / pass / fail / policy / temperror / permerror) per RFC 6376 §3.9 + RFC 8601 §2.7.1 to this per-publisher per-domain BIMI SVG Tiny PS asset-publication reference. Where THIS page documents the per-publisher per-domain BIMI SVG Tiny PS asset production-and-publication discipline (the per-asset baseProfile="tiny-ps" + version="1.2" root attribute pair, the per-asset 32 KB size ceiling, the <title> brand-name accessibility requirement, the per-publisher per-domain default._bimi.<domain> TXT-RR l=-tag publication pointing to the SVG asset), the DKIM-failures-explained spoke is the PER-RECIPIENT-PER-MESSAGE-DKIM-VERDICT- FAIL-CASCADES-INTO-PER-RECIPIENT-BIMI- INDICATOR-SUPPRESSION companion documenting the per-verdict diagnostic decision matrix for the per-message DKIM-verdict regressions that cascade directly into per-recipient BIMI- indicator suppression at the receiver-side mail-client surface. The composition operates through the BIMI-spec gating constraint per the BIMI Internet Draft: the per-publisher per-domain BIMI indicator-display surface depends on the per-message DMARC verdict reaching dmarc=pass, which depends on per-message DKIM-verdict-pass with identifier alignment (or SPF-verdict- pass with alignment). A per-message dkim=fail from forwarder/ list body rewrite, a dkim=permerror from missing or malformed <selector>._domainkey.<d-tag> public-key TXT, or a dkim=policy from 1024-bit RSA or rsa-sha1 receiver-side local-policy rejection cascades through DMARC into per-recipient suppression of the per-publisher BIMI indicator THIS page's SVG-asset publication discipline delivers. Read THIS page when AUTHORING the per-publisher per-domain BIMI SVG Tiny PS asset-publication discipline; read the DKIM-failures-explained spoke when DIAGNOSING per-recipient BIMI- indicator-suppression regressions whose root cause is per-message DKIM-verdict regression cascading through DMARC.
• DMARC for shared hosting — the per-shared-hosting-tenant per-custom- domain DMARC-DEPLOYMENT-TUTORIAL companion to this per-publisher per-domain BIMI SVG Tiny PS asset-publication discipline. Where THIS page documents the per-publisher per- domain BIMI SVG Tiny PS asset-publication byte-grammar (the per-asset SVG Tiny 1.2 Portable / Secure profile, the baseProfile="tiny-ps" attribute, the forbidden element catalogue, the per-asset square viewBox requirement, the per-asset title-and-desc accessibility metadata, the per-asset l= HTTPS URL publication discipline against the per- publisher per-domain BIMI record), the DMARC-for-shared-hosting spoke documents the structurally-paired per-shared- hosting-tenant per-custom-domain DMARC deployment tutorial (Plesk Mail Settings DKIM toggle, DirectAdmin Email Manager DKIM single-character x selector, ISPConfig default._domainkey selector, Webmin / Virtualmin DKIM configuration, CentOS Web Panel deployment, and the generic-no-control-panel SaaS-relay CNAME-delegated DKIM escape-hatch pattern) — DMARC alignment at p=quarantine or p=reject is the BIMI prerequisite per the BIMI specification, so the per-shared-hosting-tenant per- custom-domain DMARC deployment surface the spoke documents is the per-publisher per-domain authentication PRE-CONDITION upon which the per-publisher per-domain BIMI SVG Tiny PS asset-publication discipline THIS page documents is eligible for per-recipient indicator display at all. The composition operates through the per-shared-hosting-tenant per-custom-domain DMARC-authentication- ramp-as-BIMI-eligibility-prerequisite cascade: per-shared-hosting-tenant per- custom-domain DMARC p=none Phase 1 → p=quarantine Phase 2 → p=reject Phase 3 ramp- promotion gates per-recipient BIMI- indicator-display eligibility, which gates whether the per-publisher per- domain BIMI SVG Tiny PS asset THIS page's publication discipline produces is ever actually displayed at the per-recipient mail-client surface. Read THIS page when AUTHORING the per-publisher per-domain BIMI SVG Tiny PS asset-publication byte-grammar discipline; read the DMARC- for-shared-hosting spoke when COMPLETING the per-shared-hosting-tenant per-custom- domain DMARC-authentication-ramp prerequisite whose p=quarantine- or-p=reject deployment completion gates per-recipient eligibility for the per-publisher per-domain BIMI indicator-display surface THIS page's asset-publication discipline produces.
• BIMI Group SVG Tiny PS specification — the source-of-truth profile document. This page is a developer-friendly synthesis; the specification itself is the authoritative reference.
• W3C SVG Tiny 1.2 specification — the W3C base specification that Tiny PS narrows. Useful for understanding which elements / attributes Tiny PS inherits vs forbids.
• DKIM for Google Workspace — the PER-WORKSPACE-TENANT-DKIM- SIGNING-DISCIPLINE-AS-UPSTREAM-BIMI- ELIGIBILITY-PRIMITIVE companion to this BIMI Tiny PS profile reference. Where THIS page documents the W3C SVG Tiny 1.2 PS-profile byte-grammar (the seven canonical SVG-PS document requirements — baseProfile="tiny-ps", viewBox- square-ratio, no embedded raster, no scripting, no external references, no animation, no gradient definitions outside the <defs> block) the per- publisher per-domain brand-indicator SVG file must satisfy before BIMI- supporting receivers will render it, the DKIM-for-Workspace spoke documents the UPSTREAM per-Workspace-tenant per- custom-domain DKIM-signing deployment workflow (Workspace Admin Console > Apps > Google Workspace > Gmail > Authenticate email; per-tenant per- custom-domain DKIM key generation at 2048-bit RSA modulus; per-selector TXT-record publication under google._domainkey.<domain> in the per-tenant authoritative DNS zone; per-tenant Authenticate-email Start toggle) whose per-Workspace- tenant DKIM-pass-then-DMARC-aligned- DKIM-pass verdict is the LOAD-BEARING upstream cryptographic-authentication primitive every Workspace-hosted brand's BIMI Tiny PS SVG inbox-list rendering at Gmail / Yahoo / Apple Mail / Fastmail depends on. The BIMI- SVG-VS-WORKSPACE-DKIM cross-reference establishes FOUR structurally-distinct per-Workspace-tenant per-domain BIMI-rendering coupling dimensions: (i) BIMI-display eligibility at every BIMI-supporting receiver is GATED on a per-message DMARC-aligned- DKIM-pass verdict for the per- Workspace-tenant per-custom-domain From-header identity — the BIMI Tiny PS SVG file at default._bimi.<d> renders ONLY when the per-Workspace-tenant per-custom-domain DKIM verification produces a per-message DKIM-pass aligned with the From-header organisational domain; the DKIM-for- Workspace spoke documents the per- tenant Workspace-Admin-Console Authenticate-email deployment workflow whose per-tenant per-custom- domain DKIM-pass output is the load- bearing upstream BIMI-eligibility prerequisite; (ii) Workspace- hosted brands targeting BIMI display eligibility on Gmail must complete the per-Workspace-tenant per-custom- domain DKIM-signing deployment BEFORE publishing the BIMI Tiny PS SVG + VMC certificate references — publishing the per-publisher default._bimi.<d> record without an active per-Workspace- tenant DKIM-signing posture produces a 100% BIMI-ineligible per-message render decision at Gmail; the DKIM-for-Workspace spoke documents the canonical per-tenant deployment ordering (Authenticate-email Start → per-selector TXT publication → DNS- propagation wait → per-tenant DMARC ramp to p=quarantine; pct=100 or p=reject; pct=100 → BIMI SVG + VMC publication); (iii) per-Workspace-tenant per- custom-domain DKIM-key-rotation cadence and per-publisher BIMI VMC renewal cadence share the per- Workspace-tenant per-domain operational discipline of DNS- propagation-aware overlap windows during rotation events — both require per-Workspace-tenant per-custom-domain scheduled rotation with the per-tenant Workspace-Admin- Console + per-tenant authoritative- DNS-zone-editor commit cadence; the DKIM-for-Workspace spoke documents the per-Workspace-tenant per-custom- domain DKIM-key-rotation operational discipline that transfers directly to per-tenant per-domain BIMI VMC renewal cadence; (iv) per- Workspace-tenant per-custom-domain DKIM-signing-toggle activation in the Workspace Admin Console is the canonical per-tenant cryptographic- publication prerequisite without which the per-Workspace-tenant per- custom-domain BIMI Tiny PS SVG rendering at Gmail returns FALSE — the per-tenant Authenticate-email Start toggle is the load-bearing per-Workspace-tenant cryptographic-authentication- publication primitive every per- tenant BIMI Tiny PS SVG file the Workspace-hosted brand publishes depends on for receiver-side render eligibility. Read this BIMI Tiny PS profile reference when AUTHORING the per-publisher per-domain brand- indicator SVG file the per-receiver BIMI evaluator renders; read the DKIM-for-Workspace spoke when DEPLOYING the upstream per-Workspace- tenant per-custom-domain DKIM-signing posture whose per-message DKIM-pass verdict is the load-bearing cryptographic-authentication primitive gating the per-receiver BIMI Tiny PS SVG rendering this page documents.
• MTA-STS for Microsoft 365 at four per-M365-tenant cross-resource publication-coupling dimensions: (i) shared per-tenant per-custom-domain HTTPS endpoint cert-chain discipline — both resources require non-expired CN/SAN-matched public-CA-rooted X.509 cert chains, and the per-M365-tenant operator publishing a BIMI SVG asset under the same custom-domain as the MTA-STS policy host typically reuses the same wildcard or SAN-coverage cert, so cert-renewal cadence drift breaks both resources simultaneously; (ii) shared per-tenant CAA-record CA-authority-permission gating — both HTTPS endpoints draw their issuance permission from the per-publisher per-domain CAA-record-published issue "<ca>" permission graph, so a per-tenant CAA-record misconfiguration that blocks one HTTPS-resource cert issuance blocks the other; (iii) shared per-tenant per-receiver TLS-handshake fetch-failure observability via TLS-RPT — the per-tenant TLS-RPT publication discipline produces forensic JSON reports against the MTA-STS policy-host fetch failures, but per-receiver BIMI-evaluator HTTPS-fetch failures against the SVG asset are observed via per-publisher per-receiver out-of-band telemetry (Google Postmaster Tools BIMI eligibility status, Yahoo Sender Hub feedback, per-receiver BIMI-display-suppression patterns) that the operator must coordinate observability for; (iv) shared per-tenant per-custom-domain DNS-publication-as-load-bearing-locator-discipline — the MTA-STS HTTPS-resource is located via the _mta-sts.<tenant-domain> TXT-record indirection, the BIMI SVG asset is located via the default._bimi.<tenant-domain> TXT-record l= tag indirection, and per-tenant DNS-publication-cadence drift breaks both resources simultaneously. Read the M365-MTA-STS spoke alongside this BIMI SVG Tiny PS requirements reference when the M365 tenant is co-deploying inbound transport-layer hardening (MTA-STS enforce-mode) and outbound visual-anti-impersonation publication (BIMI SVG + VMC) under the same custom-domain HTTPS endpoint, when planning per-tenant cert-renewal cadence to cover BOTH HTTPS-served resources without per-resource asymmetric outages, or when investigating per-receiver per-tenant BIMI-display-suppression patterns that correlate with per-receiver MTA-STS policy-fetch failures (both rooted in the same per-tenant per-custom-domain HTTPS endpoint cert-chain discipline degradation).
• IETF draft-brand-indicators-for-message-identification — the BIMI specification itself. Still an Internet Draft, not yet a published RFC.
• RFC 7489 — DMARC — the DMARC specification BIMI depends on.
• BIMI Group (Authindicators Working Group) — the industry consortium publishing the SVG Tiny PS profile and operational interoperability rules.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN SPF-RECORD- BYTE-GRAMMAR-AS-LOAD-BEARING-PRECONDITION- FOR-BIMI-INDICATOR-ELIGIBILITY-CASCADE companion to THIS page's per-publisher per- domain SVG Tiny PS asset-publication discipline. Where THIS page documents the per-publisher per-domain SVG Tiny PS asset byte-grammar (the W3C SVG Tiny 1.2 base specification narrowed by the BIMI Group's per-publisher per-domain Tiny PS profile — baseProfile="tiny-ps", no scripting, no animation, no external references, single root <svg> element with x / y / width / height / viewBox attributes, embedded title and desc metadata) the per-publisher per-domain BIMI indicator-rendering asset must comply with, the SPF-DNS-syntax spoke is the PER-PUBLISHER-PER-DOMAIN per-message upstream-authentication-precondition- publication-discipline reference whose per-publisher per-domain syntactic- correctness floor sustains the per-message spf=pass-AND-aligned cascade into the DMARC verdict which is the per- message authentication PRECONDITION the per-receiver per-message BIMI indicator- rendering eligibility cascades from. The SVG-VS-SPF-DNS-SYNTAX cross-reference establishes the per-publisher per-domain BIMI-INDICATOR-RENDERING-ELIGIBILITY- CASCADE chain: BIMI indicator eligibility requires DMARC enforcement (p=quarantine or p=reject with pct=100) at the per-receiver per-message indicator-rendering boundary, which requires AT LEAST ONE of SPF- aligned-pass OR DKIM-aligned-pass at the per-receiver per-message alignment evaluation boundary; because forwarder- induced Return-Path-rewriting breaks SPF alignment at every forwarder hop, the per-publisher per-domain SPF-DNS-syntax publication discipline determines whether the per-message spf=pass verdict can be produced at non-forwarder per-receiver per-message paths — sustaining a fraction of the per-message BIMI-eligible traffic that does not depend on the DKIM- aligned-pass path. Read THIS page when AUTHORING the per-publisher per-domain SVG Tiny PS asset-publication discipline; read the SPF-DNS-syntax spoke when AUTHORING the per-publisher per-domain SPF-record byte-grammar publication discipline whose syntactic-correctness floor is the load- bearing upstream-authentication-precondition cascading into BIMI-indicator-rendering eligibility at the per-receiver per-message indicator-display boundary.
• Multi-domain DMARC strategy — the PER-PUBLISHER-PER-BRAND-PORTFOLIO- MULTI-DOMAIN-DMARC-PUBLICATION-COORDINATION- AS-LOAD-BEARING-CROSS-DOMAIN-BIMI-INDICATOR- ELIGIBILITY-PRESERVATION-WORKFLOW companion to this BIMI SVG Tiny PS asset-publication reference. Where THIS page documents the per-publisher per-domain SVG Tiny PS asset- format byte-level specification (1:1 aspect- ratio viewBox, baseProfile="tiny-ps", no scripts / animation / external resources, RGB-only color, 32KB ceiling, base64-encoded for inline embedding, VMC chain validation prerequisite, per-publisher per-domain BIMI DNS-record TXT publication at default._bimi.<domain>), the multi-domain-DMARC-strategy spoke is the PER-PUBLISHER-PER-BRAND-PORTFOLIO-DMARC- UNIFORM-ENFORCEMENT-PRESERVATION companion documenting the per-publisher per-portfolio per-primary + per-secondary + per-brand- extension + per-parked-domain DMARC-record publication coordination discipline whose per-publisher per-portfolio uniformly- enforced DMARC posture across EVERY active sending subdomain of the per-publisher organisational domain is the load-bearing receiver-side eligibility precondition the per-receiver per-message BIMI indicator- rendering evaluator consumes. Four BIMI-vs- multi-domain-DMARC coupling dimensions matter at the per-recipient per-message indicator-display boundary: (i) per- publisher per-portfolio uniform-DMARC- enforcement floor — Apple iCloud Mail iOS 16+ requires p=reject at the per-publisher organisational-domain DMARC record, and Gmail / Yahoo require p=quarantine at minimum, with the per-publisher 90-day rolling DMARC-pass- rate threshold above receiver-internal eligibility floors; if ANY per-publisher per-portfolio secondary or brand-extension domain publishes a weaker DMARC posture, the per-receiver per-message BIMI indicator evaluator suppresses display at the per- publisher per-portfolio cross-domain- consistency boundary; (ii) per-publisher per-portfolio per-subdomain sp= subdomain-policy hardening — the per- primary-domain p=quarantine sp=reject hardening posture the multi-domain-strategy spoke documents prevents per-attacker per- message subdomain-spoofing-bypass that would otherwise erode the per-publisher per-portfolio DMARC-pass-rate floor below the per-receiver BIMI-eligibility threshold; (iii) per-publisher per-portfolio per- parked-domain locked-down defensive- publication discipline — the per-parked- domain v=spf1 -all + DKIM-empty-p= + _dmarc.<parked> at p=reject + null-MX publication the multi-domain-strategy spoke documents prevents per-attacker per-parked-domain spoofing campaigns from polluting the per-publisher per-portfolio aggregate DMARC-pass-rate stream the per-receiver BIMI-eligibility evaluator consumes; (iv) per-publisher per-portfolio per-brand- extension BIMI-record-publication coordination — when the per-publisher operates multiple branded sub-domains (e.g., marketing.<publisher>, support.<publisher>, newsletter.<publisher>), each per-brand-extension's default._bimi.<brand-domain> SVG asset publication discipline THIS page documents must coordinate with the per- publisher per-portfolio uniform-DMARC- enforcement workflow the multi-domain- strategy spoke documents to preserve per-brand-extension BIMI-eligibility at the per-receiver per-message indicator- rendering boundary. Read THIS page when AUTHORING the per-publisher per-domain SVG Tiny PS asset-publication discipline; read the multi-domain-DMARC-strategy spoke when COORDINATING the per-publisher per- portfolio per-primary + per-secondary + per-brand-extension + per-parked-domain DMARC-record publication discipline whose per-publisher per-portfolio uniformly- enforced DMARC posture is the load-bearing receiver-side eligibility precondition every per-publisher per-domain BIMI indicator-rendering pipeline this page documents depends on as the cross-domain- consistency floor.
• Phishing protection — the PER-PUBLISHER-PER-DOMAIN-BIMI-SVG- TINY-PS-BRAND-INDICATOR-AS-PER-RECIPIENT- ANTI-PHISHING-VISUAL-BRAND-AUTHENTICITY- SIGNAL companion to THIS per-publisher per- domain BIMI SVG Tiny PS asset publication reference. Where THIS page documents the per-publisher per-domain BIMI SVG Tiny PS asset publication discipline (the baseProfile="tiny-ps" profile binding, the SVG 1.2 Tiny + Portrait/Square subset, the per-publisher per-VMC X.509- certificate chain-of-trust binding to the per-publisher per-domain BIMI selector TXT- RR, the per-publisher per-domain BIMI l= + a= tag publication discipline, the per-publisher per-domain BIMI selector- scoped indicator-rendering eligibility cascade), the phishing-protection spoke documents the per-receiver per-message anti- phishing defence-stack at FOUR per-BIMI-SVG- indicator-rendering-vs-phishing-attack- surface coupling dimensions: (i) per-publisher per-domain BIMI SVG Tiny PS brand-indicator rendering AS load- bearing per-recipient inbox-list-display layer brand-authenticity visual-signal — the per-recipient per-message inbox-list- display layer at Yahoo / Gmail / Apple iCloud Mail / Fastmail consumes the per-publisher per-domain BIMI SVG Tiny PS asset rendered next to the per-message sender-identity-display as the per-recipient visual brand-authenticity signal verifying per-message per-publisher per-domain From- domain identity authenticity to the per- recipient at the per-recipient per-message anti-phishing visual-evaluation boundary; the per-publisher per-domain BIMI SVG Tiny PS asset publication discipline THIS page documents directly produces the per-recipient anti-phishing visual brand-authenticity signal; (ii) per-publisher per-VMC X.509-certificate chain-of-trust binding AS per-recipient per-message anti-brand- impersonation cryptographic identity- assurance primitive — the per- publisher per-VMC X.509-certificate chain- of-trust binding to the per-publisher per- domain BIMI selector TXT-RR's a= tag (Mark Verifying Authority signature cryptographically binds the per-publisher BIMI SVG Tiny PS asset to the per-publisher per-domain registered-trademark identity) IS the per-recipient per-message anti-brand- impersonation cryptographic identity- assurance primitive the per-recipient per- message anti-phishing evaluator consumes to verify per-publisher brand-authenticity against per-attacker brand-impersonation phishing campaigns (per-attacker per-message spoofed-brand SVG-asset-injection attempts are filtered at the per-VMC chain-of-trust cryptographic-binding validation boundary); (iii) per-publisher per-domain BIMI selector-scoped indicator-rendering eligibility cascade AS per-recipient per- message lookalike-domain phishing-attack- surface compression discipline — the per-publisher per-domain BIMI indicator- rendering eligibility cascade (p=quarantine or p=reject DMARC enforcement floor + per-publisher per-VMC chain-of-trust binding + per-publisher per-domain BIMI selector TXT-RR publication) deterministically scopes per-recipient per-message indicator- rendering to per-publisher per-domain authentic-from-domain mail only; per-attacker per-message lookalike-domain (visually- confusable domain registrations, IDN homographs per Unicode TR #36 + UTS #39 confusables) phishing campaigns CANNOT forge per-recipient per-message inbox-list- display layer brand-indicator-rendering against the legitimate per-publisher per- domain BIMI SVG Tiny PS asset, which trains per-recipient anti-phishing visual brand- authenticity-expectation patterns that compress per-recipient per-message lookalike-domain phishing-attack-surface; (iv) per-publisher per-domain BIMI SVG Tiny PS asset publication AS per- recipient per-message brand-impersonation attack-surface compression discipline — per-attacker per-message brand- impersonation campaigns (display-name spoofing of trusted-brand identity, near- miss From-domain spoofing claiming brand affiliation) targeting per-recipient per- message brand-trust-exploitation are compressed by the per-publisher per-domain BIMI SVG Tiny PS brand-indicator-rendering eligibility cascade because per-recipient per-message anti-phishing visual-evaluation consumes the per-publisher brand-indicator rendering presence-or-absence as the per- recipient brand-authenticity confirmation signal at the per-recipient per-message inbox-list display layer. Read THIS page when PUBLISHING per-publisher per-domain BIMI SVG Tiny PS asset; read the phishing- protection spoke when UNDERSTANDING how the per-publisher per-domain BIMI SVG Tiny PS brand-indicator-rendering eligibility floor THIS page documents IS the load-bearing per-recipient per-message anti-phishing visual brand-authenticity signal compressing per-attacker per-message brand-impersonation and lookalike-domain phishing-attack-surface at the per-recipient per-message inbox-list- display layer anti-phishing visual- evaluation boundary.
• Email authentication glossary
• DKIM-Signature header explained
• DMARC for SaaS senders
• Email authentication overview
• DMARC aggregate (RUA) reports
• DKIM selectors explained
• SPF for Microsoft 365 — per-M365-tenant per-accepted- domain SPF authorisation publication- discipline IS the load-bearing per-tenant envelope-MAIL-FROM-layer authentication- leg publication-discipline whose per- tenant per-accepted-domain SPF-aligned- pass leg feeds per-tenant per-accepted- domain DMARC composite-verdict per RFC 7489 §6.6 whose per-tenant per-accepted- domain DMARC-aligned-pass-rate floor IS the load-bearing per-tenant per-VMC BIMI indicator-rendering eligibility-cascade precondition per BIMI RFC 9716 §4.1 the per-tenant per-VMC BIMI SVG Tiny PS asset-publication eligibility cascade THIS page documents the SVG Tiny PS asset-byte-grammar publication-discipline of structurally depends on at the per- M365-tenant per-accepted-domain composite envelope-MAIL-FROM-layer-authorisation- and-BIMI-SVG-asset-publication coordination boundary.
• Email spoofing seven-technique attack catalogue
• DKIM for Microsoft 365
• DKIM DNS TXT-record byte syntax
• DMARC deployment checklist — the PER-PUBLISHER-PER-DOMAIN-DMARC-FOUR-PHASE-OPERATOR-ACTIONABLE-DEPLOYMENT-PROGRESSION-AS-LOAD-BEARING-OPERATIONAL-RAMP-READINESS-PREREQUISITE-FOR-PER-PUBLISHER-PER-VMC-BIMI-INDICATOR-RENDERING-ELIGIBILITY-CASCADE companion at four per-publisher per-domain DMARC-deployment-checklist-vs-BIMI-SVG-asset-publication coupling dimensions: (i) per-publisher per-domain DMARC deployment-checklist four-phase progression THIS DMARC-deployment-checklist spoke documents the operator-actionable per-phase action-items-and-exit-criteria of IS the load-bearing per-publisher per-domain operational ramp-readiness publication-discipline whose Phase 3 Quarantine + Phase 4 Reject terminal-stage enforcement-mode publication-decision 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-domain BIMI SVG Tiny PS asset publication-discipline THIS page documents the per-recipient per-message brand-indicator-rendering eligibility floor of; (ii) per-publisher per-domain DMARC deployment-checklist Phase 1 Discovery prerequisites (SPF publication baseline, per-publisher per-selector DKIM-Signature publication baseline, per-publisher per-domain authorised-sender-inventory enumeration) per RFC 7489 §3.1 IS the load-bearing per-publisher per-domain operator-actionable evidence-gathering ramp-readiness reference whose composite SPF + DKIM publication-discipline floor cascades into per-publisher per-domain DMARC-aligned-pass-rate floor preservation the per-publisher per-VMC BIMI Indicator-rendering eligibility cascade THIS BIMI SVG requirements page documents the per-recipient per-message brand-indicator-rendering eligibility floor of structurally depends on; (iii) per-publisher per-domain DMARC deployment-checklist Phase 2 Triage RUA aggregate-report attribution-baselining + per-phase-exit-criteria evidence-driven readiness-decision-discipline IS the load-bearing per-publisher per-domain operator-actionable per-day per-source-IP per-row attribution-evidence stream whose per-day per-receiver per-leg DKIM-aligned-pass-rate-and-SPF-aligned-pass-rate floor monitoring drives per-publisher per-domain DMARC composite-verdict enforcement-mode publication-decision readiness the per-publisher per-VMC BIMI Indicator-rendering eligibility cascade THIS BIMI SVG requirements page documents the per-publisher per-domain BIMI eligibility baseline of materially depends on; (iv) per-publisher per-domain DMARC deployment-checklist Phase 3 Quarantine + Phase 4 Reject terminal-stage enforcement-ramp publication-discipline drift (premature p=reject cutover before per-phase-exit-criteria satisfaction surfacing as legitimate-mail-stream-rejection per-publisher per-domain reputational-floor regression, or stalled p=none publication-discipline drift surfacing as per-publisher per-domain DMARC-aligned-pass-rate floor regression below the per-publisher per-VMC BIMI Indicator-rendering eligibility threshold) directly opens per-publisher per-VMC BIMI Indicator-record brand-indicator-rendering eligibility cascade regression the per-publisher per-domain BIMI SVG Tiny PS asset publication-discipline THIS page documents the per-publisher per-domain BIMI SVG-asset publication-discipline floor of materially depends on at the per-publisher per-domain composite cross-protocol DMARC-deployment-progression-and-BIMI-eligibility coordination boundary.
• DMARC records explained
• DMARC policy rollout — the enforcement-deployment precondition companion to this BIMI SVG-requirements page. Where this page documents the BIMI SVG Tiny PS asset-authoring discipline (the static-cut SVG profile constraints, the <title> accessibility element, the square-aspect-ratio and single-path-fill rules, the VMC-asset chain the default._bimi.<domain> record references), the policy-rollout spoke documents the upstream precondition that gates whether any of it ever renders: BIMI requires the domain to be at an enforcement DMARC policy (p=quarantine or p=reject, never p=none) before mailbox providers display the indicator at all. A correctly-authored SVG and a valid VMC produce zero rendered brand indicators while the domain sits at p=none — so the operator must first complete the phased p=none → p=quarantine → p=reject ramp the rollout spoke documents, gating each step on the per-source aligned-pass evidence in the RUA aggregate stream, before the SVG-asset discipline on this page yields any visible result. Read the policy-rollout spoke first when planning a BIMI deployment whose domain has not yet reached an enforcement policy.
• Why SPF alone is insufficient — the protocol-layer rebuttal explaining why an SPF-only domain cannot reach the DMARC p=quarantine/p=reject enforcement BIMI requires before a logo will ever render. SPF breaks under forwarding and authorises only the envelope, so DKIM alignment is the load-bearing second leg the enforcement ramp depends on.
• DKIM alignment with DMARC — how the DKIM signature this SVG-eligibility ramp depends on actually counts toward a DMARC pass. The d= domain in the DKIM-Signature must align (relaxed or strict) with the From-header domain for the DKIM leg to satisfy DMARC; a valid signature on the wrong domain does not. Read the alignment spoke to confirm the DKIM leg gating BIMI Indicator display is aligned, not just present.
• SPF mechanisms explained — BIMI Indicator display only unlocks once the domain holds DMARC enforcement with a sustained aligned-pass, and SPF is the path-based leg of that composite. Read the SPF mechanism catalogue (a/mx/ip4/include/all + the RFC 7208 §4.6.4 10-DNS-lookup cap) to build the authorized-sender set whose aligned spf=pass helps hold the enforcement floor this SVG-eligibility ramp presupposes.
• DKIM best practices (the deployment-rules catalogue) — BIMI Indicator display is gated on sustained DMARC enforcement, and an aligned DKIM pass is the most forwarding-resilient leg of that composite. The best-practices catalogue (2048-bit RSA keys, scheduled selector rotation, retirement of stale public-key records) is the publisher-side hygiene that keeps the signing key dependable, so the DKIM-aligned pass holding your SVG-eligibility floor does not silently lapse the day a stale or under-sized key starts failing verification. Read it to keep the cryptographic leg behind BIMI durably correct.
• SPF 10-DNS-lookup limit — the SPF-LEG-BUDGET-PRESERVATION-AS-BIMI-ELIGIBILITY-PRECONDITION companion to this SVG-requirements reference: BIMI Indicator display only unlocks once the domain holds DMARC enforcement with a sustained aligned-pass, and an include:-cascade that overruns the §4.6.4 10-DNS-lookup cap collapses the SPF leg to spf=permerror, eroding the aligned-pass rate that gates the SVG-eligibility floor this page presupposes. Keeping the SPF lookup budget under the cap (via flattening or include hygiene) is the envelope-layer publication discipline that protects the enforcement floor behind a conformant logo. Read the SPF-10-DNS-lookup-limit spoke to keep the path-based DMARC leg from silently failing the day an include cascade crosses the budget.
• DANE explained (transport-layer security for the channel behind your logo) — BIMI Indicator display is gated on sustained message-layer DMARC enforcement; DANE (RFC 7672 + RFC 6698) secures the transport channel that carries those authenticated, logo-bearing messages, publishing a DNSSEC-signed TLSA record that pins the receiving MX's TLS certificate so the delivery path cannot be silently downgraded. It is the same-zone DNS-publication discipline that produced your BIMI and DMARC records, extended to the transport layer. Read it to round out the per-domain DNS controls beyond the message-authentication floor this SVG-eligibility ramp presupposes.
• 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.

14. Audit your BIMI 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. It also cross-checks the DMARC policy (p=quarantine or p=reject is required for BIMI eligibility) so you can spot the most common deployment-blocker before going live.

Audit my BIMI record Sign up — Free plan