MTA-STS Checker

MTA-STS (RFC 8461) tells sending mail servers that your domain only accepts mail over TLS with a valid certificate, which blocks downgrade and man-in-the-middle attacks on SMTP. Enter a domain to check the DNS record, download the policy file from https://mta-sts.yourdomain/.well-known/mta-sts.txt and confirm every MX host is listed.

How MTA-STS is published

You need three things: a TXT record at _mta-sts.example.com containing v=STSv1; id=20260930 (any value that changes when the policy changes), a web server answering on mta-sts.example.com with a publicly trusted certificate, and the policy file itself with version: STSv1, mode, one mx: line per mail host (wildcards like *.example.net are allowed) and max_age in seconds.

Start with mode: testing and a TLS-RPT record so you receive reports, then switch to mode: enforce once the reports show no failures. Sending servers refuse delivery in enforce mode if your MX certificate does not match the host name.

TLS-RPT reports

TLS-RPT (RFC 8460) is a TXT record at _smtp._tls.example.com such as v=TLSRPTv1; rua=mailto:tlsrpt@example.com. Gmail, Microsoft and others then send a daily JSON summary of TLS connection successes and failures, which is the only way to see MTA-STS problems before customers complain.

MTA-STS checker at a glance

How to use this tool

1. Enter the domain that receives the mail, for example example.com (not mta-sts.example.com).
2. Press Check MTA-STS. The tool reads the TXT record at _mta-sts.example.com, downloads https://mta-sts.example.com/.well-known/mta-sts.txt with a 10-second timeout and without following redirects, reads the MX records and compares every MX host with the mx: lines in the policy.
3. It also looks for a TLS-RPT record at _smtp._tls.example.com, because without reports you will not notice delivery failures caused by the policy.
4. Fix anything red, then check the mail servers themselves with the SMTP test: this checker compares host names but does not connect to your MX hosts or inspect their certificates.

No policy yet? The MTA-STS generator writes the TXT record and policy file for you, and the TLS-RPT generator the reporting record.

How to read the results

Field	What it means
DNS record (_mta-sts)	The TXT record starting with v=STSv1. Red when missing, and red when there is more than one, because senders then treat the domain as having no policy.
Policy file: “Served over HTTPS with a valid certificate”	The file was fetched with HTTP 200 over a trusted certificate. An added note about Content-Type (amber) means the server did not send text/plain.
Policy file: “HTTP 301 at …” (or 302, 404 and so on)	The server answered, but not with 200. Redirects are not followed by senders, so any 3xx makes the policy unusable.
Policy file: “Could not fetch …”	No HTTPS response at all: the host name does not resolve, the connection failed, or the certificate was rejected. The error text follows the dash.
Mode	enforce is green, testing amber (failures are only reported), and none or a missing mode red.
max_age	How long senders cache the policy, in seconds and days. Amber below one day (86400).
MX hosts vs policy	Each MX host is “covered by policy” (green) or “NOT in policy” (red). In enforce mode, senders refuse to deliver to a red host. “no policy loaded” means the file could not be read.
TLS-RPT (_smtp._tls)	The reporting record. Amber when missing.

The MX comparison follows RFC 8461: an exact name matches itself, and a wildcard such as *.example.net matches exactly one extra label on the left. So mx1.example.net is covered, but example.net and a.b.example.net are not.

Common problems and how to fix them

“Could not fetch … mta-sts.example.com does not resolve”

The mta-sts subdomain has no A or AAAA record. Create it and point it at a web server you control. In cPanel or DirectAdmin, add mta-sts.example.com as a subdomain first, so it gets a document root and is included in AutoSSL or Let’s Encrypt.

Certificate errors (“cURL error 60” and similar)

The policy host must present a publicly trusted, unexpired certificate valid for mta-sts.example.com. Self-signed certificates, the server’s default certificate and a certificate for www only all fail. On cPanel run AutoSSL after the subdomain resolves to the server; on a plain Linux server issue a certificate with certbot for that exact name. Check it with the SSL certificate checker.

certbot certonly --webroot -w /var/www/mta-sts -d mta-sts.example.com

HTTP 301, 302 or 404 instead of 200

A site-wide redirect (HTTP to HTTPS is fine, but HTTPS to www or to the main site is not) or a CMS catching the URL is the usual cause. Serve the file directly from the subdomain’s document root at .well-known/mta-sts.txt and exclude that path from rewrite rules. On nginx, a dedicated location block also fixes the Content-Type:

server {
    listen 443 ssl;
    server_name mta-sts.example.com;
    root /var/www/mta-sts;
    location = /.well-known/mta-sts.txt {
        types { }
        default_type text/plain;
    }
}

An MX host is “NOT in policy”

This happens after changing mail providers, adding a new MX, or using a wildcard that is one level too shallow. Add an mx: line for each host, then change the id in the TXT record so senders fetch the new file. Examples: Microsoft 365 MX hosts are covered by mx: *.mail.protection.outlook.com; Google Workspace needs mx: smtp.google.com, or for older setups mx: aspmx.l.google.com plus mx: *.aspmx.l.google.com.

You changed the policy but senders still use the old one

Senders cache the policy for up to max_age and only fetch a new one when they see a new id value in the TXT record. Change the id every time you edit the file; a date and time such as 20261007T1200 without punctuation works, since the id may contain only letters and digits (up to 32).

Mail stopped arriving after switching to enforce

A sender could not validate your MX: the certificate on the MX host does not match its name, has expired, or is self-signed, or the MX was missing from the policy. Look at the TLS-RPT reports for the failing host, fix the certificate, and switch back to mode: testing (with a new id) while you do.

A complete working example

DNS records:

_mta-sts.example.com.   3600  IN  TXT  "v=STSv1; id=20261007T1200"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
mta-sts.example.com.    3600  IN  A    203.0.113.10

Policy file at https://mta-sts.example.com/.well-known/mta-sts.txt, served as text/plain:

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

After a couple of weeks of clean TLS-RPT reports, change mode to enforce, raise max_age to 604800 or more, and update the id. Panel-specific steps are in MTA-STS on cPanel and DirectAdmin.

Official documentation: cPanel & WHM documentation, RFC 5321 (SMTP), Linux man pages.

Related guides: Setting up MailBaby with cPanel/WHM Exim: router, transport, SRS and DKIM · Whitelisting MailBaby in cPanel greylisting, CSF and SpamAssassin · Email forwarders with MailBaby: SRS, strict forwarding errors and backoffs.

Frequently asked questions