MTA-STS, TLS-RPT & BIMI Checker

An MTA-STS checker confirms that a domain tells other mail servers to deliver its email only over encrypted, certificate-checked connections. Enter a domain and this tool looks up the _mta-sts TXT record, fetches the policy file from https://mta-sts.yourdomain/.well-known/mta-sts.txt, validates every line, and compares the policy's mx entries with the domain's real MX records, because an enforce policy that leaves out a mail server makes senders refuse to deliver to it. It also checks TLS-RPT, the record that asks senders to report TLS problems to you, and BIMI, the record that can show your logo in supporting inboxes once DMARC is at enforcement.

How to use the MTA-STS checker

1. 1 Enter the domainType the domain that receives the email, such as example.com, or paste an email address and we will use its domain.
2. 2 Run the checkWe look up the _mta-sts, _smtp._tls and default._bimi TXT records and the MX records, and fetch the MTA-STS policy over HTTPS without following redirects.
3. 3 Review the policySee the policy file as published, whether its version, mode, max_age and mx lines are valid, and a table of your MX hosts showing which ones the policy covers.
4. 4 Check reporting and BIMIConfirm TLS-RPT has a valid report address, and see whether BIMI is published, whether its logo is SVG Tiny PS, and whether DMARC allows it.
5. 5 Fix and re-testApply the fixes shown, bump the id in the TXT record whenever the policy changes, and run the check again.

Why email needs MTA-STS

When one mail server sends to another, it usually upgrades the connection to TLS with a command called STARTTLS. The problem is that this upgrade is opportunistic. If the receiving server does not offer TLS, or if something on the network strips the offer out, the sending server simply delivers in plain text. It also does not normally check that the certificate is valid for the server it is talking to. An attacker who can sit on the network path can therefore read or redirect mail without either side noticing.

MTA-STS, defined in RFC 8461, closes that gap. The receiving domain publishes a policy that says, in effect: only deliver to these mail servers, only over TLS, and only if their certificates are valid. Sending servers that support MTA-STS, which include Gmail and Microsoft 365, fetch the policy, cache it, and refuse to deliver in a way that breaks it. Because the policy is fetched over HTTPS from a host on your domain, an attacker cannot easily fake it.

How MTA-STS is set up: record plus policy file

MTA-STS has two parts. The first is a TXT record at _mta-sts.yourdomain with the value v=STSv1; id= followed by an identifier of up to 32 letters and digits. The id tells senders when the policy has changed, so you change it every time you edit the policy file, often to a date such as 20261101. There must be only one such record.

The second part is the policy file itself, a short plain-text file served at https://mta-sts.yourdomain/.well-known/mta-sts.txt. That means you need a subdomain called mta-sts, a valid HTTPS certificate for it, and a web server or static host to serve the file. Senders must not follow redirects when fetching it, so it has to be served directly at that address with a 200 status, ideally as text/plain.

The file has four kinds of lines. version must be STSv1. mode is testing, enforce or none. max_age is how many seconds senders may cache the policy, up to 31557600 (one year). Then one mx line for each mail server that may receive your mail; a wildcard such as *.mail.protection.outlook.com matches exactly one label in front of it.

• version: STSv1, always.
• mode: testing (report only), enforce (refuse insecure delivery) or none (switch off).
• max_age: cache lifetime in seconds; a week (604800) or more is common for enforce.
• mx: one line per allowed MX host or wildcard pattern.

The most dangerous mistake: MX hosts missing from the policy

In enforce mode, a sending server will only deliver to MX hosts that match an mx line in your policy. If you add a new mail provider, a backup MX or a filtering gateway and forget to update the policy, senders that enforce MTA-STS will treat that host as untrusted and refuse to deliver to it. If it is your only MX, mail stops arriving from those senders until their cached policy expires.

This checker compares every MX record on the domain with the mx lines in the policy and marks each one as covered or not. A missing host is shown as a failure in enforce mode and a warning in testing mode. Whenever you change MX records, update the policy file first, change the id in the TXT record, and only then switch the MX records over.

Wildcards follow a strict rule: *.example.net matches mx1.example.net but not a.b.example.net and not example.net itself. Microsoft 365 users usually list *.mail.protection.outlook.com, and Google Workspace users list the specific aspmx hosts or *.google.com patterns that match their MX records.

Rolling out safely with testing mode and TLS-RPT

Start with mode: testing. Senders then evaluate your policy and report any failures, but still deliver mail as before. To receive those reports, publish a TLS-RPT record (RFC 8460) at _smtp._tls.yourdomain, for example v=TLSRPTv1; rua=mailto:tls-reports@yourdomain. Participating senders send a daily JSON report listing successful and failed TLS sessions and the reason for each failure, such as a certificate that does not match or an MX host not in the policy.

Leave testing mode on for a few weeks and read the reports. When they show no policy failures from your real mail servers, change the mode to enforce, raise max_age to at least a week, and update the id in the TXT record. Keep TLS-RPT in place afterwards, because it is the early warning if a certificate expires or a new MX host is added without updating the policy.

Reports can be noisy, so many teams send them to a dedicated mailbox or a reporting service. The important thing is that someone looks at failures before switching to enforce.

BIMI: brand logos in the inbox

BIMI (Brand Indicators for Message Identification) lets a domain publish a logo that supporting mailbox providers can show next to its messages. It is a TXT record at default._bimi.yourdomain with v=BIMI1, an l= tag pointing to the logo and, usually, an a= tag pointing to a mark certificate.

BIMI has prerequisites. DMARC must be at enforcement, meaning p=quarantine or p=reject with pct=100, because the logo is only meaningful when spoofing is blocked. The logo must be a square SVG in the SVG Tiny Portable/Secure profile (baseProfile="tiny-ps"), served over HTTPS; ordinary SVG exports from design tools usually need converting. Gmail and Apple Mail also require a Verified Mark Certificate (VMC), which generally needs a registered trademark, or a Common Mark Certificate (CMC). These certificates are issued by a small number of certificate authorities and are paid products.

This checker reports whether BIMI is published, whether DMARC allows it, whether the logo URL returns an SVG Tiny PS file and whether a certificate is linked. It does not validate the certificate itself.

Where this fits with SPF, DKIM and DMARC

SPF, DKIM and DMARC prove who sent a message and tell receivers what to do with mail that fails those checks. MTA-STS and TLS-RPT protect mail in transit to your domain. BIMI is a visible reward for getting DMARC to enforcement. They solve different problems, so a well-configured domain has all of them.

Use our SPF Checker, DKIM Checker and DMARC Checker for the authentication records, the MX Lookup to confirm which servers receive your mail, and the Email Deliverability Checker for a combined overview. Then use this tool to make sure the transport side and BIMI are set up correctly.

Examples you can copy

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

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

_smtp._tls.example.com.     TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

Common mistakes to avoid

Frequently asked questions