Ask whether the mail your company receives is encrypted in transit and the honest answer, for most domains, is "usually, we think". Mail between servers is encrypted only when both sides agree to it in the moment — and the agreement happens in plaintext, where anyone sitting in the network path can quietly remove it.
That vagueness is fine until somebody needs a real answer: a customer's security questionnaire, an auditor, a data protection officer after an incident, or a contract that says personal data must be encrypted in transit. MTA-STS and TLS-RPT exist to replace "we think" with a policy you publish and evidence you receive.
Why STARTTLS alone is not enough
An SMTP conversation begins in the clear. The receiving server lists what it supports, including STARTTLS, and the sender may then upgrade the connection. This is opportunistic encryption, and it has two well-known weaknesses.
The first is downgrade. Because the capability list is sent before encryption exists, an attacker in the path can strip STARTTLS out of it. The sending server sees a receiver that apparently does not support encryption and, rather than fail, delivers the message in plaintext. Nothing is logged as an error on either side.
The second is identity. Even when TLS is negotiated, a sender doing opportunistic delivery typically accepts whatever certificate it is offered — expired, self-signed, issued for a different name. Encryption without verification protects you from passive eavesdropping and not from someone actively impersonating your mail servers.
MTA-STS, in two parts
MTA-STS (RFC 8461) publishes a policy in two places at once, which is what makes it resistant to tampering: a DNS record that announces the policy exists, and the policy itself served over HTTPS, where the certificate proves it came from you.
The DNS record is a TXT record on a fixed name:
_mta-sts.example.com. IN TXT "v=STSv1; id=20260911T120000Z"
The id is an opaque version string. Senders cache your policy and re-fetch it when the id changes, so it must be updated whenever the policy file changes — otherwise the world keeps using the old copy until it expires.
The policy lives at a fixed URL on a subdomain reserved for it, https://mta-sts.example.com/.well-known/mta-sts.txt, and looks like this:
version: STSv1 mode: enforce mx: mail.example.com mx: mail2.example.com mx: *.mail.example.com max_age: 604800
Three fields carry the meaning:
- mode —
none(policy withdrawn),testing(do not change delivery, just report failures) orenforce(refuse to deliver unless TLS succeeds and the certificate matches a listed MX name). - mx — one line per hostname that is allowed to receive your mail; wildcards cover one label. This list must match your real MX records, including every host your provider uses.
- max_age — how long senders may cache the policy, in seconds. A week (604800) is a reasonable starting point; a longer value is stronger against attackers and slower to correct if you get something wrong.
mta-sts.example.com. If that certificate expires, senders cannot fetch or refresh your policy — a failure mode that belongs squarely to your certificate renewed, it just never reached the server.TLS-RPT: the part that tells you the truth
TLS-RPT (RFC 8460) is a single DNS record asking receivers to send you a daily summary of how TLS delivery to your domain went:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls@example.com"
The reports are JSON, and they name the specific failure types you would otherwise never see: starttls-not-supported, certificate-expired, certificate-host-mismatch, validation-failure. They come from the large receivers who send you mail, which means they describe the internet's real experience of your mail servers rather than your own view from inside the network.
This is why TLS-RPT goes first in any sane rollout. It costs nothing, changes nothing, and tells you whether enforcement would have broken anything.
What about DANE?
DANE achieves a similar goal by publishing certificate fingerprints as TLSA records, secured by DNSSEC. Where DNSSEC is already deployed it is an excellent control, and some European providers enforce it. It requires a signed zone, which MTA-STS does not — that is the main reason MTA-STS is more widely deployed. The two can coexist, and senders that support both will use them both.
What breaks without it
- Mail can be read in transit by anyone able to interfere with the connection, with no error visible to sender or recipient.
- You cannot answer the encryption question. Security questionnaires and DPAs increasingly ask; "opportunistic TLS" is a description of intent, not of outcome.
- You never learn about broken TLS on your own servers. An expired certificate on a secondary MX silently downgrades deliveries for months.
- You are a weaker link than your peers. Domains that publish a policy get strict handling from the big senders; domains that do not, do not.
How to check it in 30 seconds
Run the MTA-STS check. It reads the DNS record, fetches the policy over HTTPS, validates the syntax and compares the mx: lines against the domain's actual MX records — the mismatch that turns enforce into rejected mail. Then run the TLS-RPT lookup to confirm reporting is on. By hand:
dig +short TXT _mta-sts.example.com dig +short TXT _smtp._tls.example.com curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt
Fix it
- Publish TLS-RPT first and let reports arrive for a couple of weeks. Send them to a mailbox somebody reads.
- Fix what the reports show — usually an expired or mismatched certificate on one MX host.
- Publish the policy file at
https://mta-sts.<domain>/.well-known/mta-sts.txtwithmode: testingand a shortmax_age, and make sure that subdomain has its own valid certificate. - Add the
_mta-stsTXT record with anidyou will remember to change. - List every MX host your provider uses, wildcards included. Check it against your live MX records rather than the onboarding email.
- Watch the reports again. When failures are zero, switch to
mode: enforceand raisemax_age. - Write down that changing MX records now requires updating the policy and the
id— before the person who knows that leaves.
Then keep it that way
Enforcement is a commitment: from the moment senders cache mode: enforce, a certificate that expires on an MX host or an MX record that changes without a policy update means mail to you is deferred and eventually bounced. That is the correct behaviour — it is the whole point — but it has to be maintained.
Add the domain to StatusDNS and the maintenance is watched for you: the _mta-sts record and the policy file are re-checked on a schedule, the policy's mx: entries are compared against live MX records, the TLS-RPT record is verified, and certificates on your mail hosts are tracked with expiry alerts at 30, 14, 7, 3 and 1 days. MX and other DNS changes are captured as snapshot diffs, so a mail migration that forgets the policy shows up as a change rather than as bounced mail. Alerts arrive by email, Slack or webhook.
We do not host your policy file or manage your DNS. What we do is make sure the three moving parts — record, policy and certificates — still agree with each other, which is exactly where this quietly falls apart. For the wider picture of how receivers decide to trust your mail, see why email stops arriving.