BIMI Validation Report

A brand logo beside an email depends on more than publishing an image. Brand Indicators for Message Identification (BIMI) links an authenticated author domain to a DNS assertion, a constrained logo file, and optional mark-certificate evidence. The receiving mailbox provider still decides whether to display the indicator.

BIMI builds on aligned email authentication rather than replacing it. The author domain needs a strong Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy, and the message must pass the receiver's authentication checks. A BIMI record then tells the receiver where to retrieve the logo and, when used, the evidence document.

Selector

A DNS label that chooses a BIMI assertion, commonly default but sometimes a campaign or business-unit name.

Indicator location

The HTTPS logo location carried by the l= tag.

Evidence location

The optional HTTPS certificate location carried by the a= tag.

The logo has security and presentation constraints beyond looking correct in a browser. Current BIMI guidance uses the SVG Tiny P/S profile, excludes scripts and external resources, and expects a square, self-contained mark. Certificate-backed deployments add expiry, domain coverage, extended-key-usage, and logotype-extension checks.

Several different failures can look like “BIMI is not working.” A DNS cache may still hold the prior record, the selector may be wrong, DMARC may be at monitoring policy, the asset host may be unreachable, the SVG may violate the profile, or a provider may require certificate evidence that was not published.

A successful public check is evidence of readiness at one moment. It does not prove trademark rights, sender reputation, provider eligibility, or future logo display.

How to Use This Tool:

Check the author domain and selector that the mail stream actually uses, then fix the first weak gate.

1. Enter one public Domain. Use the domain from the visible From identity rather than a sending host or tracking domain.
2. Leave Selector as default unless the sender publishes another DNS-safe selector such as holiday-logo.
3. Choose an Evidence posture. Auto review flags missing PEM evidence, Require PEM makes it blocking, and Allow self-asserted accepts a logo-only publication for this report.
4. Choose a public Resolver only when cache or propagation differences are part of the investigation.
5. Run the validation and open Validation brief. Use the first Needs attention or Review row to decide whether DNS, DMARC, the logo host, the SVG, or certificate evidence needs work.

Interpreting Results:

Deployable means the observed checks produced no blocking or review rows under the selected posture. Review recommended means no blocking row remains but at least one policy or evidence question is unresolved. Needs attention means one or more required checks failed.

• The readiness score summarizes this report's rules; it is not a BIMI protocol score or a mailbox-provider score.
• Declined publication is a deliberate record with empty logo and evidence locations, not a successful logo deployment.
• Resolver answers include time-to-live evidence. After a DNS or asset change, rerun after relevant caches can expire and compare another resolver if propagation matters.
• Even a deployable result cannot guarantee display because providers apply their own authentication, certificate, reputation, abuse, and interface policies.

Technical Details:

The validation combines live public lookups with deterministic rules. It inspects the BIMI TXT assertion, the organizational-domain DMARC record, the retrieved logo, and certificate evidence when published. Each observation becomes a status row and one of four gate scores.

Lookup Core

Rule Core

A logo SVG passes the profile check when the root declares baseProfile=tiny-ps and version 1.2. The safety check rejects script or animation elements, external references, and root x or y attributes. The presentation check expects a title, square geometry, explicit pixel width and height, and a file no larger than 32 KB.

A certificate domain match accepts a leaf Subject Alternative Name that covers the selector owner, author domain, or organizational domain. A wildcard covers exactly one additional label. The certificate profile is healthy only when the leaf is current and exposes both the BIMI extended-key-usage and logotype-extension signals.

Formula Core

Overall readiness starts at 100, loses 14 points for each blocking row and 6 points for each review row, and cannot fall below 0. Explicit decline is assigned 35 instead of using that calculation.

B is the blocking-row count and V is the review-row count. Four separate gate scores describe BIMI publication, DMARC enforcement, the logo asset, and certificate evidence. A gate score of at least 85 is Healthy, 50 to below 85 is Review, and below 50 is Needs attention.

The four gate scores are diagnostic. They do not average into the overall readiness score; the status-row counts drive that result.

Privacy and Limits:

The selected public resolver receives the BIMI and DMARC owner names. Public logo and certificate hosts receive requests for their published assets, and network intermediaries involved in retrieving those assets can observe the URLs.

• Only public domains and assets are supported.
• DNS, HTTP, and certificate evidence is a transient observation and can become stale.
• The certificate inspection does not replace certificate-authority validation, trademark review, or provider-specific approval.
• The BIMI specification is still an active Internet-Draft and can change.

Worked Examples:

References:

• Brand Indicators for Message Identification, draft 14, IETF Datatracker, May 1, 2026.
• Fetch and Validation of Verified Mark Certificates, draft 11, IETF Datatracker, May 2026.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor.
• BIMI Implementation Guide, BIMI Group.