MTA-STS and TLS-RPT – encryption that cannot be stripped away
MTA-STS makes encrypted delivery to your mail servers binding, and TLS-RPT reports failures daily. Here is the record, the policy file and every transport finding.
Mail between servers is encrypted by default – but only if both sides feel like it. The sending server asks "can we do this encrypted?", the receiving server says yes, and the conversation continues under TLS. The weak point is the question itself: it is asked in the clear. Someone sitting between the two servers can remove the offer, both sides shrug, and the message travels in plain text. Nobody notices, because nothing failed.
MTA-STS closes that gap. You publish, once, a binding statement: mail to this domain is delivered encrypted, to these servers, with a valid certificate – and if that is not possible, do not deliver at all. A sending server that supports MTA-STS keeps your statement in its cache and no longer accepts a downgrade. TLS-RPT is the companion: a daily report telling you when delivery to you ran unencrypted or failed.
What the records look like
MTA-STS is two things that have to match: a small DNS record, and a file on a web server.
_mta-sts.example.com. TXT "v=STSv1; id=20260916120000"The record does nothing but announce that a policy exists, and carry an id. The id has to change whenever you change the file – it is how sending servers notice that their cached copy is stale. A date-and-time stamp is the usual choice.
The policy itself is a plain text file served at https://mta-sts.example.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mx01.mail.protection.outlook.com
mx: *.mail.protection.outlook.com
max_age: 604800| Line | What it means |
|---|---|
mode | enforce binding, testing observe only, none switched off. |
mx | One line per mail server name. Wildcards are allowed for a whole level. Every name in your MX records must be covered here. |
max_age | How long sending servers may cache the policy, in seconds. 604800 is a week and is the common choice. |
TLS-RPT is a single record and independent of MTA-STS:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls@example.com"It costs nothing, breaks nothing and is the only way you will ever learn that encrypted delivery to you failed somewhere.
From DNS and the web we read the MTA-STS record, fetch the policy file, compare the names in it against your actual MX records, and read the TLS-RPT record. We do not open an SMTP connection: outgoing SMTP is blocked on the checking server, so STARTTLS itself and your mail server's certificate cannot be measured from here. The report says "not measurable" rather than quietly calling it fine.
The one mistake that stops your own mail
Everything about MTA-STS is harmless except one combination: mode: enforce together with a policy that does not list all of your mail servers. A sending server that honours the policy then finds your real MX name missing from the permitted list and refuses to deliver. Your own mail stops arriving, and the more carefully a sender implements the standard, the worse it gets.
This happens on its own, without anybody editing the file. You change mailbox provider, the MX records change – and the policy file from two years ago still names the old servers. That is why the order below matters, and why mode: testing exists.
How to set it up
- Create the subdomain
mta-sts.example.comand point it at a web server with a valid certificate. Any hosting package will do; it serves one text file. - Put the policy file at
/.well-known/mta-sts.txt, exactly that path, served as plain text. - Start with
mode: testingandmax_age: 604800, and list every name from your MX records. - Publish the TXT record at
_mta-stswith a freshid. - Publish the TLS-RPT record at
_smtp._tlswith an address you read. - Wait a few weeks, read the reports, and only then change the file to
mode: enforce– remembering to change theidat the same time.
| Provider | The practical part |
|---|---|
| Microsoft 365 | MX is <tenant>.mail.protection.outlook.com; the wildcard *.mail.protection.outlook.com covers it safely |
| Google Workspace | List smtp.google.com, or all five aspmx names if you still use the older set |
| Cloudflare | DNS records in the panel; the policy file can be served from Pages or any host |
| GoDaddy, Namecheap, Bluehost, Rackspace, Fasthosts, 123-reg | A subdomain with an SSL certificate and one text file – no special product needed |
Add a calendar note: whenever the mailbox provider changes, the policy file changes with it, before the MX records do.
The findings in detail
Multiple MTA-STS records
More than one TXT record at _mta-sts starts with v=STSv1. Only one is allowed; with several, sending servers cannot tell which id is current and treat the policy as unusable.
What to do: keep the record with the newest id, delete the rest.
MTA-STS in test mode
Your policy is mode: testing. Nothing is enforced – deviations are reported through TLS-RPT and delivery continues regardless. As the first phase of a rollout this is exactly right, and it carries no risk.
What to do: check the reports for a few weeks. If nothing unexpected appears, switch the file to mode: enforce and change the id. If you have no TLS-RPT record yet, add one first, otherwise the testing phase produces nothing to read.
MTA-STS disabled (mode: none)
The policy file says mode: none, which explicitly switches the protection off. It is the correct way to retire MTA-STS gracefully – senders see the policy, learn it no longer applies, and stop enforcing the old one. Left in place indefinitely it is simply a file that does nothing.
What to do: decide. Either set it to testing or enforce and change the id, or remove the DNS record and the file once the previous max_age has expired everywhere.
MTA-STS validity very short
max_age is below one day. Sending servers cache the policy for that long, so a short value means that most of the time nobody has a copy – and an attacker who can block one request removes the protection entirely.
What to do: set max_age to at least 86400 seconds. 604800, a week, is the common choice and the one to use unless you have a reason. Change the id when you change the value.
Policy does not list all mail servers
Your MX records name servers that do not appear in the policy file. In testing mode nothing is blocked – you get failure reports instead. This is precisely what the testing phase is for, and the finding is the early warning that matters.
What to do: add the missing names to mta-sts.txt, or cover them with a wildcard, and change the id. Fix this before you switch to enforce.
Enforced policy excludes your own mail servers
The policy is enforced and does not list all of your mail servers. This is the most damaging fault in this area: sending servers that honour the policy abort delivery, and your own mail does not arrive. It usually appears after a provider change, when the MX records were updated and the policy file was not.
What to do: act now. Either add all MX names to the file immediately, or set mode: testing as a stopgap – and in both cases change the id, otherwise senders keep using their cached copy. Only then work out how the two drifted apart.
MTA-STS record without a policy file
The DNS record exists but the file could not be retrieved – wrong path, missing subdomain, an invalid certificate, or a redirect. Senders that see the record and cannot fetch the file may abort delivery, so this is not a cosmetic fault.
What to do: open https://mta-sts.example.com/.well-known/mta-sts.txt in a browser. It must return the plain text file over HTTPS with a valid certificate, with no redirect to a different host. If the file cannot be served for now, remove the DNS record while it is missing.
TLS-RPT without a recipient address
The record at _smtp._tls has no rua field, so no reports are sent anywhere. The record is present and does nothing.
What to do: add rua=mailto:tls@example.com with an address you read. The reports are JSON in a compressed attachment, one per sending provider per day, and they are the only notice you get when encrypted delivery to you failed.
Frequently asked questions
Is MTA-STS worth it for a small company?
It is worth it for anyone who receives mail that matters – invoices, contracts, customer data. The work is one subdomain, one file and two DNS records. The risk lies only in switching to enforce too early, which the testing phase prevents.
Does MTA-STS encrypt the message itself?
No. It protects the connection between mail servers and prevents that protection being stripped away. The message sits unencrypted on both servers. For end-to-end secrecy you need message encryption, which is a separate matter.
What is DNSSEC doing in this section?
DNSSEC signs your DNS records so that MX, SPF and MTA-STS answers cannot be swapped in transit. It is a switch at most DNS providers and complements everything on this page. The check reports whether your domain is signed.
Do I have to change the id every time?
Yes, whenever the file changes. Sending servers keep their cached copy for the whole max_age and only fetch a new one when the id in DNS differs. A changed file with an unchanged id is a change nobody sees.
The Mail Check measures exactly what this page describes – on your own domain, in one to three seconds, without signing up.
Check a domain now →