BIMI, MTA-STS and TLS-RPT explained

Three different jobs, all published in DNS

BIMI, MTA-STS, and TLS-RPT each solve a different problem on top of the SPF/DKIM/DMARC foundation, and each is published as its own DNS record rather than bolted onto an existing one:

• BIMI — shows a verified brand logo next to your mail in supporting inboxes.
• MTA-STS — tells other mail servers to require encrypted (TLS) delivery to yours, instead of silently allowing a downgrade to plaintext.
• TLS-RPT — reports back to you when that encrypted delivery fails somewhere, so a silent TLS problem doesn’t stay silent.

None of these three replace SPF, DKIM, or DMARC — they’re each optional layers that assume those three are already working.

BIMI: a verified logo in the inbox

Per the BIMI Group’s specification and implementation guide, BIMI (Brand Indicators for Message Identification) lets a domain publish a DNS record pointing to a logo (as an SVG) that supporting mailbox providers display next to authenticated mail from that domain. The prerequisite that trips people up: BIMI requires DMARC to already be enforcing (p=quarantine or p=reject), not just present at p=none — a mailbox provider showing a brand logo next to a message is implicitly vouching that the message’s authenticity has actually been checked and acted on, not merely monitored.

default._bimi.example.com.  TXT  "v=BIMI1; l=https://example.com/logo.svg;"

Beyond DMARC enforcement, some mailbox providers additionally require a Verified Mark Certificate (VMC) — a paid certificate from a small number of authorized certificate authorities that cryptographically ties the logo to a registered trademark — before they’ll display the logo at all. Others display BIMI logos from the DNS record alone. Which applies depends on the specific mailbox providers your recipients use, so check their current requirements before budgeting for a VMC.

MTA-STS: stop silent downgrades to plaintext

Ordinary SMTP delivery between mail servers uses opportunistic TLS: a sending server offers to encrypt, but if the receiving server doesn’t support it, or an attacker on the network path interferes with the negotiation, delivery quietly falls back to plaintext rather than failing. RFC 8461 defines MTA-STS so a domain can publish a policy — fetched over HTTPS from a well-known URL, with a supporting DNS TXT record pointing to the policy’s existence — stating that mail to it must use TLS with a valid certificate, and that a sending server honoring the policy should refuse delivery rather than downgrade.

_mta-sts.example.com.  TXT  "v=STSv1; id=20261022000000Z"

The actual policy document (which hosts, which mode: enforce, testing, or none) is served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt, not in the DNS record itself — the DNS record only signals that a policy exists and its version, so senders know to check for an update.

TLS-RPT: find out when delivery isn’t encrypted

RFC 8460 defines TLS-RPT, a reporting mechanism that’s useful with or without MTA-STS: sending servers that support it will email you a daily report describing any TLS negotiation failures they encountered trying to deliver to your domain — misconfigured certificates, failed STARTTLS negotiation, or an MTA-STS policy that unexpectedly blocked delivery.

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Without TLS-RPT, an MTA-STS policy that’s misconfigured (wrong hostname, expired certificate) can silently block legitimate mail from any sender that respects the policy, with no notification reaching you at all. TLS-RPT is what closes that visibility gap.

Putting it in order

1. Get SPF, DKIM, and DMARC working first — see SPF, DKIM and DMARC explained if you haven’t yet, and check your current DMARC policy with DMARC check.
2. Move DMARC to an enforcing policy (p=quarantine or p=reject) before attempting BIMI — mailbox providers won’t show the logo otherwise.
3. Publish the BIMI record and logo once DMARC enforcement is stable, checking VMC requirements for your recipients’ mailbox providers if you need logo display everywhere.
4. Publish MTA-STS and TLS-RPT independently of BIMI — they protect transport security rather than brand display, and are worth enabling even if you never pursue BIMI.