BIMI Validation Report

BIMI connects email authentication with brand-logo display. A sending domain publishes a TXT record below _bimi, points to an HTTPS SVG logo, and may point to certificate evidence such as a Verified Mark Certificate. Mailbox providers then decide whether the evidence is good enough to display the mark.

The record does not stand alone. BIMI depends on domain alignment and an enforcing DMARC policy, and receivers can require certificate evidence even when the BIMI TXT record and logo URL are present. That is why a useful validation report needs to follow the DNS record, DMARC policy, logo asset, and certificate chain together.

The report checks the selected BIMI owner name, organizational-domain DMARC, optional exact-domain DMARC, logo fetch details, SVG properties, certificate evidence, subject names, extended key usage, logotype extension, and readiness notes. It can compare Cloudflare DNS and Google Public DNS answers.

That evidence chain helps separate a missing DNS record from a logo hosting problem or certificate mismatch. For a brand rollout, those are different work queues: DNS owners fix TXT placement, mail administrators fix DMARC alignment, web teams fix logo hosting, and certificate contacts handle mark evidence.

Technical Details:

A BIMI record is a DNS TXT record at selector._bimi.domain. The default selector is common unless mail uses a BIMI-Selector header. The record can publish v=BIMI1, l= for the logo URL, and a= for certificate or authority evidence. Some domains can also publish an explicit decline.

The browser sends DNS TXT lookups to the selected public DNS-over-HTTPS resolver. Logo and certificate URLs are fetched through proxy candidates so the report can inspect public assets from the page. The domain, selector, and public asset URLs are therefore transmitted to those network services during validation.

Evidence posture changes how missing certificate evidence is interpreted. Auto mode treats missing a= as a review item. Require PEM evidence makes it blocking. Allow self-asserted treats logo-only publication more leniently.

Everyday Use & Decision Guide:

Use the visible From domain or BIMI author domain, then keep the selector as default unless the sending system intentionally uses another selector. Start with Auto evidence posture for discovery, then switch to Require PEM evidence when preparing for mailbox providers that demand certificate-backed display.

• Check DMARC first. A BIMI logo is unlikely to be useful when DMARC is missing or not enforcing.
• Confirm the BIMI TXT owner name before changing DNS, especially on subdomains.
• Use the asset ledger to catch logo fetch, content-type, SVG, or size issues before certificate review.
• Use the tag ledger to spot malformed l= or a= values.
• Repeat with another resolver when a newly published record may still be cached differently.

A deployable report is still not a guarantee of logo display. Receivers apply their own requirements, reputation checks, certificate rules, and rollout behavior.

Step-by-Step Guide:

1. Enter the domain and selector, then choose the resolver if cache comparison matters.
2. Pick evidence posture based on whether certificate evidence is required for the review.
3. Run validation and read the evidence chain summary.
4. Open the tag, asset, and notes tabs to identify the first blocking item.
5. Export rows or JSON only after rerunning against the final DNS state.

Interpreting Results:

Deployable means the checked items did not produce blocking notes under the selected evidence posture. Review recommended means the record may be usable but has issues worth resolving. Needs attention means at least one core check failed.

DMARC badges should be read carefully. BIMI generally expects an enforcing DMARC policy such as quarantine or reject with suitable alignment. A p=none policy is normally not enough for production display expectations.

Certificate checks look for evidence signals, not legal ownership advice. Trademark, certificate issuance, and receiver acceptance must be handled through the relevant certificate authority and mailbox-provider guidance.

Worked Examples:

Logo-only discovery. A domain has v=BIMI1 with an HTTPS SVG in l= and no a= value. Auto posture may show review recommended, while Require PEM evidence marks missing certificate evidence as blocking.

DMARC blocker. A clean BIMI TXT record and fetchable logo still produce needs-attention output when organizational DMARC is absent or set to p=none.

Selector mismatch. The default selector is missing, but holiday._bimi.example.com exists. Re-running with the holiday selector shows the record and prevents a false missing-record conclusion.

FAQ:

Does BIMI make mail authenticated? No. BIMI depends on email authentication and DMARC. It is a brand indicator mechanism, not a replacement for SPF, DKIM, or DMARC.

Is a VMC always required? Receiver requirements differ. Many production display paths expect certificate-backed evidence, so the report lets you treat missing PEM evidence as a blocking issue when needed.

Why fetch the logo and certificate? DNS can point to URLs that are missing, unreachable, malformed, expired, or mismatched. Fetching public assets exposes those problems before receiver testing.

Glossary:

BIMI

Brand Indicators for Message Identification, a DNS-based method for publishing a brand mark for authenticated mail.

VMC

Verified Mark Certificate, certificate evidence used by some receivers for brand-logo display.

DMARC

Email authentication policy that BIMI relies on for domain enforcement context.

Selector

The label before _bimi that chooses which BIMI record to check.

References:

• BIMI Group sender and ESP FAQ