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.

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.

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.

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.