The problem it solves

SMTP negotiates TLS with a command called STARTTLS, and if that negotiation fails the sending server usually delivers in plaintext instead. An attacker positioned between two mail servers can simply strip the STARTTLS offer and read everything that follows. This is a downgrade attack, and it works because the fallback is silent by design.

How it works

MTA-STS publishes a policy at a fixed HTTPS URL on your domain — https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — listing your MX hostnames and a mode. A DNS TXT record at _mta-sts.yourdomain.com tells senders the policy exists and carries a version ID so they know when it changes.

In enforce mode, a sending server that cannot establish valid TLS to your MX will refuse to deliver rather than fall back. testing mode reports failures without blocking, which is where you start.

TLS-RPT

The companion record is TLS reporting, at _smtp._tls.yourdomain.com. It asks senders to send you daily reports on TLS negotiation successes and failures. Without it you have no visibility into whether enforce mode is quietly rejecting legitimate mail, so publish it before you enforce.

The DNS record and the policy file

MTA-STS has two parts. A TXT record at _mta-sts.yourdomain.com that reads v=STSv1; id=20260930, where id is any string that changes whenever the policy changes — a date works. And a plain-text file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: smtp.google.com
max_age: 604800

Each mx line must match one of your actual MX hostnames, with a wildcard allowed for the first label — Microsoft 365 needs mx: *.mail.protection.outlook.com. The host serving the file needs a valid certificate for mta-sts.yourdomain.com, which on Cloudflare means a proxied record and nothing else. The MTA-STS generator writes both parts from your MX records.

Testing mode first, then enforce

Publish TLS-RPT before anything else, so you have reports from day one. Then publish the policy in mode: testing with a short max_age — one day. In testing mode senders check the policy, report whether they could have complied, and deliver regardless. After a week of reports showing no failures, change mode to enforce, raise max_age to a week or more, and bump the id in the TXT record so senders re-fetch the file. Senders cache the policy for max_age, which is why a long value in testing mode is a mistake: it delays your move to enforce by however long you set.

On Google Workspace and Microsoft 365 the whole thing takes an afternoon, because the MX hosts already support TLS correctly and the only work is the policy itself. Both providers also honour MTA-STS as senders, so mail from Gmail and Outlook to a domain with an enforced policy is encrypted or not delivered.

Failure modes

The policy host certificate. The file is served over HTTPS and the certificate must be valid for the mta-sts hostname. A wildcard on the parent domain covers it; a certificate for the bare domain does not. Senders that cannot fetch the policy treat it as absent — in testing mode that means a report, in enforce mode it means they fall back to their cached copy until it expires, then to nothing.

An mx line that does not match. If the policy lists smtp.google.com and the MX is still the old five aspmx hosts, or the other way round, senders in enforce mode refuse to deliver. Change the MX first, then the policy, then the id.

The id never changed. Senders that cached the old policy will not fetch the new one until max_age expires. Every policy edit needs a new id.

A CDN or firewall in front. Bot protection that challenges the request returns HTML instead of the policy, and the sender reads it as invalid. The policy path should be reachable by anything with no cookies and no JavaScript. The MTA-STS checker fetches the file the way a sender does and reports each of these.

Check yours

These run free in your browser. Nothing you type reaches a server.

Common questions