MTA-STS, TLS-RPT and BIMI checker
Check the DNS records that make mail to your domain use TLS, report when it doesn't, and show your logo in supporting inboxes.
A domain, an email address or a URL. Lookups go from your browser to Cloudflare's public DNS (1.1.1.1); nothing is sent to simmail.
What these records are
MTA-STS (RFC 8461) lets a domain say "only deliver mail to me over TLS, with a valid certificate, to these servers". It has two parts: a TXT record at _mta-sts.example.com (v=STSv1; id=…) that announces a policy exists, and the policy file itself, served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt.
TLS-RPT (RFC 8460) is a TXT record at _smtp._tls.example.com (v=TLSRPTv1; rua=…) that asks senders to report failed TLS connections to you, daily.
BIMI (Brand Indicators for Message Identification, an IETF draft) is a TXT record at default._bimi.example.com pointing at your logo (l=, an SVG) and, optionally, a mark certificate (a=).
Why they matter
SMTP between servers uses opportunistic TLS: if encryption fails or is stripped by an attacker in the middle, mail is sent in clear text and nobody notices. MTA-STS turns that into a hard requirement, the way HSTS does for websites. TLS-RPT tells you when senders have trouble, which is how you find out about an expired certificate before mail starts bouncing. BIMI does nothing for security on its own, but needs DMARC enforcement, which does.
Common mistakes
- A TXT record with no policy behind it. The
mta-stshost must exist and serve the file over HTTPS with a valid certificate formta-sts.example.com. - MX names missing from the policy. In enforce mode, senders refuse to deliver to any MX not matched by an
mx:line. Update the policy (and the id) before changing mail providers. - Forgetting to change the id. Senders keep using the cached policy until
max_ageruns out. - Going straight to enforce without TLS-RPT reports to warn you about problems.
- BIMI with DMARC at p=none. The logo will not show.
This page reads DNS only. A browser can't fetch the MTA-STS policy file from another site (CORS), so checking the file is coming with our server-side tools.
Questions
Why isn't the policy file checked?
It lives at https://mta-sts.yourdomain/.well-known/mta-sts.txt, and browsers block a page on one site from reading files on another unless that site allows it (CORS). Policy files almost never do. Checking the file, its certificate and its mx lines is coming with our server-side tools; until then this page checks everything that lives in DNS.
What should the policy file contain?
Plain text lines: version: STSv1, mode: (testing, enforce or none), one mx: line per mail server name (wildcards like *.example.com allowed), and max_age: in seconds. See RFC 8461 section 3.2.
Should I start in testing mode?
Yes. In mode: testing, senders report TLS problems (if you have TLS-RPT) but still deliver. Move to enforce once the reports are clean.
What is the id in the TXT record for?
Senders cache your policy for up to max_age. Changing the id tells them to fetch the policy again, so change it every time you edit the file.
Do I need BIMI?
No. BIMI is optional and only shows a logo in mailboxes that support it. It requires DMARC at quarantine or reject, and Gmail also requires a mark certificate.
Your DNS is right. Now see how real people react to your email
simmail sends your app's mail to simulated people who open, ignore, junk, click and reply, so you can test what happens after delivery. Start free, no card.