Free MTA-STS Checker

What is MTA-STS?

MTA-STS (RFC 8461) is a mechanism that allows mail domains to declare that they support TLS for incoming SMTP connections and to specify whether sending mail servers should refuse to deliver to MX hosts that do not offer TLS with a valid certificate. Without MTA-STS, opportunistic TLS can be downgraded by an active attacker, leaving email vulnerable to interception.

Why should you enable MTA-STS?

• Prevent Downgrade Attacks: MTA-STS tells sending servers to require TLS, preventing attackers from stripping encryption during mail delivery.
• Complement STARTTLS: STARTTLS alone is opportunistic and can be bypassed. MTA-STS makes TLS mandatory for senders that support it.
• Visibility with TLS-RPT: Pair MTA-STS with TLS-RPT to receive reports when sending servers encounter TLS failures delivering to your domain.
• Industry Best Practice: Major providers like Google and Microsoft support MTA-STS. Enabling it signals your domain takes email security seriously.

How MTA-STS works: a DNS record and a policy file

MTA-STS has two parts, and senders need both. A TXT record at _mta-sts.example.com says a policy exists, and the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt holds the rules. A sending server that supports MTA-STS reads the record, fetches the file over HTTPS and caches it for as long as the file says.

v=STSv1; id=20261009

The record must start with v=STSv1, written exactly like that. The id is up to 32 letters and digits, and a date works well. Change it every time you edit the policy file: senders compare it with the copy they cached and fetch the file again when it differs.

A policy file looks like this:

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mail.example.net
max_age: 604800

• version: must be STSv1.
• mode: enforce tells senders not to deliver to a mail server that does not match an mx: line, does not offer STARTTLS or presents an invalid certificate. testing asks them to report those failures but deliver anyway, and none switches the policy off, for use when you retire one.
• mx: one line per mail server or pattern. A wildcard covers exactly one label: *.example.com matches mail.example.com but not mx.eu.example.com or example.com itself. If your MX record ends in mail.protection.outlook.com, as a standard Microsoft 365 setup does, mx: *.mail.protection.outlook.com covers it.
• max_age: how long senders cache the policy, in seconds. 604800 is one week, and the maximum is 31557600, about a year.

How to set up MTA-STS

1. Check your mail servers first. Each MX host needs STARTTLS and a valid, publicly trusted certificate for its name. In enforce mode, senders that apply MTA-STS will not deliver to a host that fails. Our article on how to fix a STARTTLS failure covers the usual causes.
2. Publish the policy in testing mode with a short max_age, so a mistake does not stay cached for long:

   version: STSv1
   mode: testing
   mx: mail.example.com
   max_age: 86400

3. Serve it over HTTPS at the path above, with a valid certificate for the mta-sts host name, as text/plain and without a redirect. Senders do not follow redirects, and RFC 8461 asks them to check the media type.
4. Add the TXT record at _mta-sts.example.com.
5. Publish TLS-RPT at the same time (see below), so senders tell you about failures while you test.
6. Move to enforce after one to two weeks of clean TLS-RPT reports: change the mode to enforce, raise max_age to at least 604800 (one week) and change the id so senders fetch the new file.

Mistakes that stop MTA-STS working

• An MX host the policy does not cover. In enforce mode, senders that apply MTA-STS will not deliver to it, and if no host is covered they cannot deliver to you at all. The checker above lists each live MX host next to the mx: line that covers it.
• A policy file senders cannot fetch. A missing file, an invalid certificate, a redirect or a browser check in front of the file all leave a sender with no cached copy treating your domain as if it had no MTA-STS. The checker shows why the fetch failed.
• More than one v=STSv1 record at _mta-sts. RFC 8461 tells senders to ignore other TXT records there, and to treat two or more v=STSv1 records as no policy at all.
• A policy file with no TXT record. Senders look for the file only after they see the record, so nothing uses it.
• An id that did not change. Edit the file without changing the id and senders that cached the old policy can keep using it until its max_age runs out.

MTA-STS or DANE?

DANE (RFC 7672) does the same job with TLSA records in DNS, and it requires DNSSEC. MTA-STS needs no DNSSEC, which makes it easier to deploy. One gap: MTA-STS cannot protect a delivery from a sender that has not yet fetched your policy, and DANE can. The two can run side by side. DANE needs TLSA records for each mail server in a DNSSEC-signed zone, and the DNSSEC Checker shows whether your own domain is signed.

Pair it with TLS-RPT

MTA-STS has no reporting of its own. TLS-RPT (RFC 8460) adds it: a TXT record at _smtp._tls.example.com tells senders where to send a report when they cannot connect to you securely, so you find problems while you are still in testing mode.

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

Reports arrive as JSON, usually once a day, and name each failure with a result type such as certificate-expired, certificate-host-mismatch or starttls-not-supported. The TLS-RPT Checker validates the record, warns when a reporting address points at a domain that takes no mail, and explains what the reports contain.

Need automated monitoring?

This free tool is great for one-off checks. If you need continuous monitoring of MTA-STS, TLS-RPT, DMARC, SPF, DKIM, SSL, and more across all your domains, start a 30-day free trial with no card needed.