BIMI Requirements: Every Prerequisite Explained in Full Detail

Why a Precise Requirements List Matters More for BIMI Than Most Standards

Most email authentication standards fail loudly, in a way you can observe directly — an SPF record with bad syntax produces a visible permerror, a broken DKIM signature causes a clear verification failure you can see in message headers. BIMI fails silently. There's no bounce, no error report, no header flag telling you a requirement wasn't met. The logo simply doesn't appear, and nothing in your sending pipeline tells you why. This makes an exact, complete requirements list disproportionately valuable for BIMI compared to other standards, because the only way to diagnose a non-displaying logo is to work back through every individual requirement one at a time, confirming each independently, since nothing surfaces the failure for you automatically.

Requirement 1: DMARC Enforcement

This is the foundational, non-negotiable requirement, and it's worth stating with full precision rather than approximately. Your domain's DMARC record must publish a policy of p=quarantine or p=reject — not p=none — and the pct tag, if present, must equal 100, or be absent entirely (which defaults to 100). A domain at p=reject; pct=50; does not meet this bar, because only half of failing mail is actually being enforced against, which undermines the trust guarantee providers rely on before agreeing to display anything. Beneath DMARC itself, this also implicitly requires SPF and/or DKIM to be correctly configured and passing in alignment for your legitimate mail streams, since DMARC enforcement without properly aligned underlying authentication would simply start rejecting your own real mail rather than protecting it.

Confirm this specific requirement with DMARC Lookup, checking both the policy tag and the pct value explicitly rather than assuming a record's mere existence is sufficient.

Requirement 2: A Correctly Published BIMI TXT Record

The record must live at default._bimi.yourdomain.com (or a custom selector, referenced accordingly), must be a TXT record type, and must begin with exactly v=BIMI1. Case matters in some implementations for the version string, and stray whitespace or unexpected characters before the version tag can cause an otherwise well-intentioned record to be silently disregarded. A minimal compliant record:

v=BIMI1; l=https://example.com/logo.svg;

Requirement 3: The l= Logo Tag

Every sub-requirement above is independently checkable and independently a common point of failure. A file that's a valid SVG but served from a URL requiring login will fail the reachability requirement even though the file itself is perfect. A file at a stable, public HTTPS URL that happens to contain a disallowed script element will fail the format requirement even though everything else about the setup is correct. See SVG Logo for BIMI for the complete technical breakdown of exactly what SVG Tiny PS permits and disallows.

Requirement 4: The a= Authority Tag (Practically Required, Technically Optional)

The BIMI specification itself does not mandate the a= tag — a record without one is still a valid BIMI record. In practice, this requirement has been effectively promoted to mandatory by the largest mailbox providers. Gmail, Google Workspace, and Apple Mail currently will not display any logo without a valid, reachable Verified Mark Certificate referenced here. Treating a= as optional based on a literal reading of the specification, while targeting providers that require it, is one of the most common and most avoidable gaps in an otherwise complete BIMI setup. See Verified Mark Certificate (VMC) for the full certificate process and provider requirements.

Requirement 5: An Active, Registered Trademark (for VMC)

This requirement is the single largest practical barrier for smaller organizations and personal domains, since it requires an actual, already-completed legal process rather than anything achievable purely through technical configuration. Organizations without a qualifying trademark should evaluate whether a Common Mark Certificate fits their situation, understanding its considerably narrower provider acceptance compared to a full VMC.

Requirement 6: Certificate Validity and Currency

A VMC or CMC isn't a one-time credential — it has an expiration date and must be renewed to remain valid. An expired certificate referenced in an otherwise unchanged a= tag will cause providers requiring certificate validation to stop displaying the logo, with no other symptom anywhere in the setup. This requirement is easy to overlook precisely because nothing about the DNS record or logo file changes when a certificate lapses — only the certificate's own internal validity window does.

Provider-Specific Additional Requirements

Requirements That Are Sometimes Mistaken as Mandatory (But Aren't)

A Complete Pre-Launch Checklist

Requirements Gap Analysis: Common Real-World Scenarios

Why These Requirements Exist in the First Place

It's worth understanding the reasoning behind each requirement rather than treating them as arbitrary bureaucratic hurdles, because that reasoning is exactly what tells you which requirements are safe to eventually relax and which ones never will be. The DMARC enforcement requirement exists because BIMI has no authentication mechanism of its own — without a guarantee that unaligned mail is actually being blocked or quarantined, displaying a trusted logo next to a message would simply hand attackers a more convincing forgery, and this requirement is unlikely to ever be relaxed by any responsible implementation. The SVG Tiny PS restriction exists because a general-purpose SVG file rendered directly inside a trusted email client interface is a genuine security surface — scripts, external references, and dynamic content inside a logo could otherwise be weaponized in ways users would never expect from what looks like a static brand image. The certificate requirement exists to prevent exactly the abuse case of one domain publishing another's trademarked logo, which would otherwise be trivially possible for anyone who cleared the DMARC bar alone. Every requirement traces back to a specific, deliberate threat model consideration, not an arbitrary checklist item, which is also why providers have been reluctant to relax any of them even as BIMI adoption has grown.

Requirements From the Certificate Authority's Perspective

It helps to understand what a Certificate Authority is actually verifying when it issues a VMC, since this shapes what documentation and process to expect. The CA is confirming three distinct things: that the requesting organization is the legitimate, verifiable owner or authorized licensee of a specific registered trademark; that the logo image submitted for certification is a faithful representation of that exact registered mark, not a stylized variant, seasonal reskin, or simplified version; and that the domain requesting the certificate is genuinely controlled by that same organization, typically verified through a domain-control validation step similar to what's used for standard SSL/TLS certificate issuance. This three-part verification is why the process takes real time rather than being instantaneous — trademark registries have to be checked, documentation reviewed, and in many cases a human verification step is involved rather than a fully automated pipeline. Organizations that have gone through EV (Extended Validation) SSL certificate issuance in the past will recognize a similar rigor and pace, since VMC issuance follows a comparable identity-verification philosophy applied specifically to trademark ownership rather than general corporate identity.

Requirements Interdependency Map

None of these requirements exist in true isolation — several depend on others being satisfied first, and understanding the dependency order avoids wasted effort. DMARC enforcement depends on SPF and/or DKIM already passing reliably in alignment, which itself depends on every legitimate sending source for the domain being correctly configured and identified — meaning the DMARC requirement alone can represent weeks or months of underlying work for an organization with several sending platforms. The VMC requirement depends on an already-completed, independent legal process (trademark registration) that BIMI implementation work has zero influence over and cannot accelerate. The SVG requirement depends on design resources being available to either create a compliant logo from scratch or simplify an existing one, which is a design and content workflow rather than a DNS or engineering task. Recognizing that these requirements sit across three genuinely different domains — email infrastructure, legal/trademark, and design — is useful for correctly staffing and sequencing a BIMI project rather than treating it as a single engineering ticket that one person can complete end to end.

A Note on Requirements Documentation Drift

Because BIMI is maintained through an industry working group rather than a single standards body with a rigid, infrequent release cycle, and because individual mailbox providers layer their own additional requirements on top of the base specification independently, published guidance — including this article — can drift out of sync with current provider behavior faster than more mature standards like SPF or DMARC tend to. The safest practice for any organization maintaining BIMI long-term is to treat written requirements lists, including comprehensive ones, as a strong starting reference rather than a permanently authoritative source, and to periodically re-verify against both current official provider documentation and a live, functional checking tool rather than assuming a requirements list written even a year prior is still fully current in every provider-specific detail.

Requirements Comparison: BIMI vs Similar Brand-Trust Programs

This comparison is useful context for stakeholders familiar with EV SSL certificates specifically, since VMC issuance follows a philosophically similar approach — verify a real-world legal identity thoroughly rather than just a technical control signal — applied to a completely different channel.

Expert Tips for Meeting Every Requirement Without Wasted Cycles

Common Requirement-Related Mistakes and Their Fixes

Requirements From a Budget-Planning Perspective

Teams responsible for budgeting a BIMI rollout benefit from separating the requirements into cost categories rather than treating the whole project as a single line item. Engineering and DNS work — publishing records, configuring hosting, running validation — is typically a small, fixed amount of internal time with no external cost. Design work — creating or converting a logo to SVG Tiny PS — is a one-time cost unless the brand identity changes, at which point it recurs. The recurring, ongoing cost center is exclusively the certificate: VMC purchase and renewal through an authorized CA, which unlike the other requirements doesn't disappear once satisfied but instead becomes a recurring line item similar to a domain registration or SSL certificate renewal. Organizations that model BIMI as a one-time project cost rather than including the certificate as an ongoing operational expense frequently get surprised by an unbudgeted renewal a year later — building the recurring cost into the same budget cycle as other domain and certificate renewals avoids this.

Requirements Verification Order: A Recommended Sequence

Rather than checking every requirement simultaneously, a sequential verification order tends to be more efficient and easier to debug when something fails. First, verify DMARC enforcement status alone, in isolation, before touching anything else — if this fails, nothing downstream matters yet. Second, once DMARC is confirmed enforced, verify the SVG logo file independently by fetching it directly and checking it against SVG Tiny PS structural rules, entirely separate from whether a BIMI record exists yet. Third, if pursuing a VMC, verify the certificate is issued, currently valid, and hosted at a stable URL, again independently of the DNS record. Only after each of these three checks passes independently should you publish the actual BIMI TXT record tying them together, and then run one final, combined end-to-end check to confirm the full chain works together as expected. This staged approach isolates failures to a single layer at a time, rather than producing a combined failure that's harder to diagnose because multiple independent requirements might be unmet simultaneously.

What Happens When Requirements Are Met But Providers Simply Don't Support BIMI

It's worth stating plainly: meeting every requirement covered in this article guarantees eligibility, not universal display. A recipient using a mail client or provider that hasn't implemented BIMI support at all — many enterprise and self-hosted mail systems, along with numerous smaller webmail providers — will never show your logo regardless of how perfectly every requirement is satisfied, simply because that specific software was never built to look for or render a BIMI record in the first place. This isn't a requirements failure on your part; it's a coverage gap outside your control, and it's worth communicating clearly to stakeholders that BIMI display, even when everything is done correctly, will realistically show up for some portion of recipients rather than all of them, with that portion determined by which mail systems your specific audience happens to use.

Real-World Use Cases for a Requirements Audit

Requirements for Multi-Brand and Franchise Organizations

Organizations operating multiple distinct brands under one corporate umbrella — a holding company with several retail banners, a franchise network with a shared parent but locally branded storefronts, or a SaaS company running multiple product lines under different names — face a specific wrinkle in the requirements above worth addressing directly. Each brand that sends mail under its own visual identity generally needs its own trademark registration matching that specific brand's logo, its own VMC issued against that mark, and its own sending domain (or clearly delineated subdomain) with independently enforced DMARC. A single parent company trademark does not automatically extend certificate eligibility to every sub-brand's distinct visual identity, since the CA is verifying a specific mark-to-domain-to-logo relationship, not a general corporate affiliation. Franchise networks in particular should plan for this early, since it means the requirements checklist above needs to be run independently for every distinct brand identity in the portfolio, not once for the parent organization as a whole, and budget and timeline estimates should scale accordingly with the number of distinct brands rather than assuming a single rollout covers the entire portfolio.

Requirements Testing Environments and Staging

Because BIMI evaluation happens entirely on the receiving mailbox provider's side with no sender-facing test harness or sandbox provided by the specification itself, testing requires a somewhat improvised but effective approach: use a non-default selector to publish a candidate record without touching your live default configuration, send test messages to accounts on the specific providers you care about (a Gmail test account, an iCloud test account, and so on), and manually inspect how the message renders in each. This is more manual than testing most DNS-based standards, since there's no automated conformance test suite that guarantees a specific provider's rendering behavior — the only reliable confirmation is observing actual behavior in a real inbox on that specific provider, in addition to running structural validation with a dedicated checking tool against the record and files themselves. Keep a simple log of which provider accounts were tested and when, since provider behavior can change and a test from a year ago is not a permanent guarantee of current behavior — treat each verification as a snapshot in time rather than a permanent certification of ongoing compliance.

Documentation and Audit Trail Requirements for Compliance-Conscious Organizations

Regulated industries and larger enterprises that treat email authentication as part of a broader security compliance posture often need to maintain documentation beyond the pure technical requirements covered above — records of when DMARC enforcement was verified and by whom, when the VMC was issued and its expiry date, who owns renewal responsibility, and a change log of any modifications to the BIMI record itself. This isn't a requirement of the BIMI specification, but it's a practical requirement many organizations layer on top once BIMI becomes part of an audited security or brand governance program, particularly given how silently individual pieces of the setup can fail without any automated alerting. Building this kind of lightweight internal documentation alongside the technical rollout, rather than after a problem is discovered, tends to save considerable time during later audits or incident investigations, and also makes staff transitions far less risky, since a new owner inheriting the setup has a clear record of what was verified, when, and by what method, rather than having to reverse-engineer the current state from scratch.

Requirements Checklist for Ongoing Maintenance, Not Just Initial Launch

How These Requirements Are Likely to Evolve

Provider-specific requirements — particularly around certificate mandates — have shifted before and are reasonably likely to shift again, since BIMI as a broader ecosystem is still younger and less settled than SPF, DKIM, or DMARC. Domains maintaining BIMI long-term should treat the requirements list as a living reference rather than a fixed, one-time checklist, and periodically re-verify against current provider documentation and a live checking tool rather than relying purely on a setup guide's snapshot from months or years earlier.

Final Word: Treat This as a Baseline, Not a Ceiling

Everything covered above represents the minimum bar for BIMI to function at all — it is deliberately not a guide to doing BIMI exceptionally well, just correctly. Organizations that want their BIMI implementation to hold up over years rather than months should go beyond minimum compliance: choose a logo design that remains legible and recognizable even at very small inbox-list sizes, build the certificate renewal process into existing domain and SSL renewal workflows rather than treating it as a separate one-off task, and assign clear internal ownership for the whole chain — DNS, DMARC, logo hosting, and certificate — rather than letting responsibility scatter across teams with no single owner. The requirements themselves are a checklist; a durable, low-maintenance BIMI setup is an operational habit built on top of that checklist, and the difference between the two is usually what separates an implementation that quietly breaks within a year from one that keeps working reliably without anyone having to think about it.

Related Reading

For the foundational overview, start with What Is BIMI?. For the full SVG format breakdown, see SVG Logo for BIMI. For the certificate process specifically, read Verified Mark Certificate (VMC). For exactly how the DMARC prerequisite works, see BIMI vs DMARC. To check your own domain against every requirement above at once, use the BIMI Checker.