Inbox check guide
What is MTA-STS, and does my domain need it?
Reviewed
Short answer
MTA-STS (RFC 8461) tells other mail servers that your domain only accepts mail over an encrypted connection to a verified server. Without it, an attacker on the network path can strip encryption from delivery to you, or redirect it. It needs a TXT record at _mta-sts, a policy file served at https://mta-sts.<your domain>/.well-known/mta-sts.txt, and, to see failures, a TLS-RPT record at _smtp._tls. Start in testing mode, read the reports, then switch to enforce.
Build the MTA-STS records for your domain
What it protects
Server-to-server email uses opportunistic encryption: the sending server asks for TLS, but if anything on the way removes that offer, delivery quietly falls back to plain text. MTA-STS turns that into a rule: deliver to these named mail servers over valid TLS, or don’t deliver at all.
It protects mail sent to you, not mail you send. It doesn’t replace SPF, DKIM or DMARC, which prove who sent a message.
What to publish
Three pieces, all at your own domain:
- A TXT record named _mta-sts with the value v=STSv1; id=<a value you change whenever the policy changes>.
- A policy file at https://mta-sts.<your domain>/.well-known/mta-sts.txt listing your mail servers (one mx: line each), the mode (testing or enforce) and max_age.
- A TXT record named _smtp._tls with v=TLSRPTv1; rua=mailto:<an address you read>, so senders such as Google and Microsoft report delivery problems daily.
How to roll it out
Publish the policy in testing mode first: senders report failures but still deliver. After a week or two of clean TLS reports, switch mode to enforce and change the id in the _mta-sts record so senders fetch the new policy.
The policy file must be served over HTTPS with a valid certificate for mta-sts.<your domain>. Many teams host it on a static site or a CDN worker. If you change mail provider, update the mx: lines before the change.