You’ve got SPF, DKIM and DMARC sorted. Your mail proves who it’s from, and spoofed messages get rejected. Good. But there’s a separate question most domains never ask: when another server sends mail to you, is that connection actually encrypted, or is it travelling in plain text where anyone on the path can read it?
For most domains, the honest answer is “we don’t know.” That’s the gap MTA-STS and TLS-RPT close, and almost nobody has deployed them.
Why SMTP encryption is weaker than you think
When two mail servers talk, they’re supposed to upgrade the connection to TLS using a command called STARTTLS. The problem is that STARTTLS is opportunistic. If the encrypted handshake isn’t offered, or fails, the sending server quietly falls back to delivering the message in clear text rather than not delivering it at all.
That fallback is the weakness. An attacker sitting on the network path between the two servers can strip the STARTTLS offer out of the conversation. The sending server sees no encryption available, shrugs, and sends your mail unencrypted. This is a downgrade attack, and the sender never knows it happened. Even when TLS does get negotiated, plain opportunistic STARTTLS doesn’t validate the receiving server’s certificate, so a man-in-the-middle with any certificate can intercept the traffic.
So you can have perfect DMARC and still have inbound mail readable in transit. SPF, DKIM and DMARC authenticate the message. They say nothing about whether the pipe it came down was encrypted.
What MTA-STS actually does
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets you publish a policy that says: mail to my domain must use TLS, the certificate must be valid, and it must come through these specific MX hosts. A sending server that supports MTA-STS reads that policy, caches it, and from then on refuses to fall back to plain text for your domain. The downgrade attack stops working, because the sender already knows TLS is mandatory.
It has two parts, and you need both.
First, a DNS TXT record at _mta-sts.yourdomain.com that tells senders a policy exists:
v=STSv1; id=20260610T120000Z
The id is a version stamp, usually a timestamp. You change it every time you update the policy file, which signals senders to re-fetch the new version.
Second, the policy file itself, served over HTTPS at this exact path:
The file is plain text and looks like this:
version: STSv1
mode: enforce
mx: mail1.yourdomain.com
mx: mail2.yourdomain.com
max_age: 604800
Each mx: line is one of your authorised MX hosts, and these must match the hostnames in your actual MX records, not the IP addresses and not the bare domain. max_age is how long, in seconds, senders cache the policy. The maximum is 31557600 (one year).
There’s a detail in max_age that catches people out. A longer cache is safer, not riskier. If your policy file briefly goes offline, senders that already cached your policy keep enforcing it, so a short outage doesn’t drop your encryption guarantee. Start short while you test, then extend it once you’re stable.
Roll it out in testing mode first
The mode field has three values, and the order you use them in matters.
- testing: senders evaluate your policy but never block delivery. Failures get reported, nothing gets dropped. This is where you start.
- enforce: senders refuse to deliver over an unencrypted or invalid connection. This is the goal.
- none: you’re opting out. Used to cleanly retire a policy.
Never publish enforce on day one. If one of your MX hosts has an expired or mismatched certificate, or you missed an MX line in the policy, enforce mode will cause real mail to fail. Publish testing first, watch the reports for two to four weeks, fix anything that shows up, and only then switch to enforce and raise the max_age.
Which brings us to the reports.
TLS-RPT: the part that tells you what’s actually happening
MTA-STS without reporting is flying blind. TLS-RPT (RFC 8460) is the companion that sends you daily summaries of how TLS delivery to your domain is going: which connections succeeded, which fell back, and which failed certificate validation. It’s the only way to know whether your testing-mode policy is safe to enforce.
You enable it with one more DNS TXT record, at _smtp._tls.yourdomain.com:
v=TLSRPTv1; rua=mailto:tlsreports@yourdomain.com
You can send reports to multiple destinations, comma-separated, and an HTTPS endpoint also works in place of mailto. The reports arrive as JSON, one per sending source per day, summarising success and failure counts and the reason for any failure. A run of clean reports in testing mode is your signal that enforce is safe.
The reason most domains never do this
The concept is simple. The operational reality is where it dies. To deploy MTA-STS properly you have to stand up an HTTPS server at mta-sts.yourdomain.com, install a valid TLS certificate for that subdomain, host a small text file at a precise path, and then keep that certificate renewed forever. If the cert expires, the policy fetch fails. Add a second domain, or twenty, and you’re running and renewing certificates for every one of them just to serve a few lines of text.
That overhead is exactly why MTA-STS adoption is so low despite the standard being years old. The policy is five lines; the infrastructure to publish it reliably is the actual cost.
This is where DMARCS does the boring part for you. Hosted MTA-STS publishes and serves your policy file on a managed HTTPS endpoint with the certificate handled and renewed automatically, so there’s no web server to maintain and no cert to forget. You set the mode and the MX hosts; the hosting and renewal are not your problem. The TLS Reports view then takes the raw JSON from your TLS-RPT records across every domain and turns it into one readable picture of where encryption is succeeding and where it’s falling back, so you can move from testing to enforce with evidence instead of a guess.
Where to start
If you only do one thing this week, publish a TLS-RPT record and an MTA-STS policy in testing mode. That costs you nothing in delivery risk and immediately starts showing you whether mail to your domain is being encrypted or quietly downgraded. Once the reports come back clean, move to enforce and extend the max_age.
Run your domain through the free tools on dmarcs.com first to see what you’ve already got published, then start a trial if you want the policy hosted and the reports read for you across all your domains. DMARC told you who was sending. MTA-STS and TLS-RPT tell you whether anyone could read it on the way in.
