Skip to content

BIMI & TLS-RPT Toolkit

Look up, analyze, and generate BIMI and SMTP TLS reporting records.

Declared service, requires network

Explicit network action

Look up the public BIMI record

TXT query

<selector>._bimi.<domain>
Provider
Cloudflare 1.1.1.1
Destination
https://cloudflare-dns.com/dns-query
Request
One credentialless HTTPS GET · 5 seconds · no retry

This leaves the browser. Cloudflare receives the queried name, TXT type, connection IP, and normal HTTPS metadata. The query is in the GET URL; StackCache does not proxy or persist it.

No request made

Lookup waits for your click

Typing never sends a request. The analyzer and generator below remain local.

Local checks only · 0 / 16,384 characters

Paste a record or select a DNS result to see local diagnostics.

Local generator

Build a reviewable BIMI record

This creates TXT content only. It does not publish DNS, fetch referenced resources, test DMARC, or confirm that reports can be delivered.

Working notes

Use BIMI & TLS-RPT Toolkit with the boundary visible.

BIMI & TLS-RPT Toolkit constructs the correct DNS owner name, optionally retrieves the public TXT record through disclosed Cloudflare DNS over HTTPS, and analyzes or generates bounded record text locally.

What is BIMI & TLS-RPT Toolkit?

BIMI and TLS-RPT are newer email standards that build on the foundation of SPF, DKIM, and DMARC to improve email trust and security reporting. BIMI (Brand Indicators for Message Identification) lets domain owners display their brand logo next to authenticated emails in supporting mail clients like Gmail, Apple Mail, and Yahoo Mail. It requires a DMARC enforcement policy (quarantine or reject), an SVG Tiny PS logo, and optionally a Verified Mark Certificate (VMC) from a certificate authority. TLS-RPT (SMTP TLS Reporting) is a DNS TXT record that tells other mail servers where to send reports about TLS connection failures when delivering email to your domain — similar to how DMARC reporting works for authentication, TLS-RPT reporting works for encryption. Both standards use DNS TXT records: BIMI at default._bimi.domain (or a custom selector) and TLS-RPT at _smtp._tls.domain. This toolkit helps you look up, analyze, and generate these records.

When to use it

  • Setting up BIMI — generate the DNS TXT record pointing to your SVG logo and optional VMC certificate, and verify the syntax before publishing.
  • Verifying BIMI readiness — check that a domain has a valid BIMI record, DMARC enforcement policy, and the required prerequisites for logo display.
  • Configuring TLS-RPT — generate a TLS-RPT DNS record specifying where to receive TLS failure reports (mailto: or https: endpoint).
  • Monitoring email encryption — use TLS-RPT to receive reports when other servers fail to establish TLS connections to your mail servers, indicating potential downgrade attacks or misconfiguration.
  • Auditing existing records — look up and analyze current BIMI and TLS-RPT records for syntax errors, missing fields, or duplicate records that invalidate the policy.

How to use it

  1. 01Choose BIMI or TLS-RPT, enter the policy domain and BIMI selector when applicable, then review the exact TXT query and provider disclosure.
  2. 02Run the explicit lookup or paste an existing record to inspect version, locations, destinations, duplicates, and extension fields.
  3. 03Generate reviewable TXT content locally, then validate referenced resources and operational requirements before publishing it in DNS.

Common mistakes

  • BIMI without DMARC enforcement — BIMI requires a DMARC policy of p=quarantine or p=reject. A p=none policy means no logo display, regardless of the BIMI record.
  • Wrong SVG format for BIMI — BIMI requires SVG Tiny Portable/Secure (SVG Tiny PS), not standard SVG. Regular SVG files with scripting, external references, or unsupported elements are rejected.
  • Multiple TLS-RPT records — publishing more than one TLS-RPT TXT record at _smtp._tls.domain invalidates the policy. Ensure only one record exists.
  • Report destination unreachable — TLS-RPT report destinations (mailto: or https:) must be reachable and authorized. An unmonitored mailbox or 404 endpoint means reports are lost.
  • BIMI selector mismatch — the default BIMI selector is "default" (default._bimi.domain). If your mail system uses a custom selector, the DNS record must match.

Synthetic example

TLS-RPT reporting policy

Input

v=TLSRPTv1; rua=mailto:tls-reports@example.com

Result

Version and one mailto report destination pass local syntax checks

Related standards

Limits and data boundary

  • A lookup sends the queried name and TXT type in an HTTPS GET URL; Cloudflare also receives normal connection metadata.
  • BIMI analysis does not download or validate SVG or certificate files, check DMARC enforcement, or predict whether a mailbox provider will display a logo.
  • TLS-RPT analysis does not test report-destination ownership, availability, authorization, or delivery. Multiple matching records may invalidate the published policy.

Frequently asked questions

What is BIMI?
BIMI (Brand Indicators for Message Identification) lets domain owners display their logo next to authenticated emails in supporting mail clients. It requires a DMARC enforcement policy and a published DNS TXT record pointing to an SVG logo.
What is TLS-RPT?
TLS-RPT (SMTP TLS Reporting) is a DNS TXT record that tells other mail servers where to send reports about TLS connection failures when delivering email to your domain.
Does this tool validate my BIMI logo?
No. The tool checks the DNS record syntax and field values but does not download, render, or validate the SVG image or Verified Mark Certificate.