Encryption that is required, not merely offered
Without MTA-STS a sending server that cannot negotiate TLS will happily deliver your mail in plain text and tell nobody. The policy is what turns that into a refusal, and it only works while it is reachable and current
The policy, as a sender fetches it
The file is requested over HTTPS from the mta-sts subdomain exactly the way a sending server would, and what comes back is parsed
- Fetched from the real URL
- Mode read: enforce, testing or none
- The mx entries it names
- max_age checked for sanity
The DNS record and the policy agreeing
The id in your TXT record is what tells senders the policy changed. Publish a new policy without changing the id and nobody refetches it
- TXT record parsed
- Policy id compared
- Stale id detected
- Both sides checked in one run
TLS-RPT, so failures reach you
A receiver that could not encrypt a session will tell you, but only if you gave it somewhere to send the report
- TLS-RPT record checked
- Reporting address parsed and shown
- Reports parsed on arrival
- Failures shown by sending host
What the MTA-STS and TLS-RPT checks do
This is a two-part mechanism where each half is useless alone, so both halves are checked together
The policy file, actually fetched
Not inferred from DNS
The policy is requested over HTTPS from the mta-sts host the same way a sending server requests it. A policy that exists on a server nobody can reach is the most common failure here, and it is invisible from the DNS side
The mode you are really in
testing is not enforce
A policy in testing mode changes nothing about how mail is delivered, it only produces reports. Plenty of domains publish testing, forget, and believe they are enforcing encryption. The mode is read from the policy and stated plainly
The id that makes updates take effect
A policy nobody refetches
Senders cache your policy and only refetch it when the id in the TXT record changes. Edit the file and leave the id alone and your change reaches nobody for as long as max_age says, which is usually weeks
The hosts the policy names
Compared with your real MX
A policy that lists a host you no longer use, or omits one you do, causes refusals for exactly the mail it was meant to protect. The mx entries in the policy are read and shown against the MX records actually published
Somewhere for failures to go
TLS-RPT, and whether it resolves
The TLS-RPT record names an address receivers use to report a session they could not encrypt. If that address sits on a domain with no MX the reports vanish and you conclude everything is fine, so the address is parsed out and shown for you to check
The reports, once they arrive
JSON turned into hosts and counts
TLS-RPT reports arrive as compressed JSON. They are parsed into sending hosts, failure types and counts, so a receiver that has been failing to encrypt with you for a fortnight becomes a row you can see instead of a file nobody opened
What each mode does when a connection cannot be secured
The mode is the whole policy. Two of the three change nothing at all about how mail is delivered, and only one of those is honest about it
| mode | When TLS cannot be established | What you learn |
|---|---|---|
| enforce | The sending server gives up rather than deliver in the clear | Failures arrive as TLS-RPT reports, and mail that would have been downgraded is not sent |
| testing | Delivery goes ahead exactly as it would without a policy | The same reports arrive, so you see what enforce would have blocked before you block it |
| none | Delivery goes ahead, and the policy is withdrawn | Nothing. This is how you retire a policy, not how you start one |
max_age is how long a sender caches the policy. Under 3600 seconds is close to having none, and 604800 is the value to publish once you are confident
Three steps, and one of them is waiting
Going straight to enforce is how you find out that one of your MX hosts has a certificate problem
Publish TLS-RPT first
Before any policy, give receivers somewhere to report. You will start seeing which senders already fail to encrypt with you, and that list is the work
Publish the policy in testing mode
Nothing changes about delivery, but reports start telling you what enforce would have refused. This is the step people skip and then regret
Switch to enforce and change the id
The mode goes to enforce and the id in the TXT record changes, otherwise senders keep the cached policy. Both sides are checked on every run afterwards
Questions about MTA-STS
What the policy actually changes, why testing mode does nothing, and what happens when the id does not move
MTA-STS is a security standard that allows domain owners to declare their support for TLS encryption and specify whether sending servers should refuse delivery if TLS is not available. Using a dedicated checker helps ensure your policy and DNS records are correctly synchronized.
The id field in the _mta-sts TXT record tells sending servers when your policy has changed. If you update your policy file but do not change the id in DNS, servers will continue using the cached version.
DMARC protects the content and sender identity of the email. MTA-STS protects the transport, meaning the pipe the email travels through, specifically preventing interception.
TLS-RPT provides the feedback loop needed to know if your MTA-STS policy is causing delivery failures, allowing you to fix issues before they impact your business.
In testing mode, sending servers report TLS failures but still deliver mail even without encryption. In enforce mode, servers must refuse delivery if a secure TLS connection cannot be established. Start with testing to identify issues, then switch to enforce once TLS-RPT signals confirm stable encrypted delivery.
Check whether your policy is reachable
The policy file is fetched the way a sending server fetches it, which is where most problems turn out to be. Watching one domain is free and asks for no card