MTA-STS: forcing TLS on every email destined for your inbox.
Published 2026-05-13 · Last updated 2026-05-13 · Vantyris editorial
MTA-STS (Mail Transfer Agent Strict Transport Security) is to email what HSTS is to web traffic: it tells sending mail servers that yours requires TLS, and they must refuse to deliver in plain text. Without MTA-STS, an attacker on the network path between your customer's mail server and yours can downgrade the connection and read every email in transit. Adoption is still low (around 15% of UK domains in 2026); shipping it is a five-minute job and demonstrates a level of email-security maturity that most peers don't yet have.
What this means for your business
- Inbound email between mail servers historically delivers in plain text and 'opportunistically' upgrades to TLS if both sides support it. An attacker who can sit on the network can simply strip the TLS negotiation, and the receiving server delivers anyway.
- MTA-STS adds two things: a DNS record at `_mta-sts.<yourdomain>` announcing the policy exists, and a policy file served over HTTPS at `https://mta-sts.<yourdomain>/.well-known/mta-sts.txt` describing the rules (which MX hosts to trust, how long to enforce). Sending servers fetch the policy, cache it, and refuse to deliver in plain text to your domain for the cached lifetime.
- The companion TLS-RPT record asks receiving servers to report any TLS failures back to you, so you find out if mail is being dropped instead of just delivering insecurely.
How to fix
Publish two records: an MTA-STS policy file at a well-known HTTPS URL on a subdomain, plus a DNS TXT record pointing at it. Start in 'testing' mode for a month, then move to 'enforce'.
- Create the mta-sts subdomain and host the policy file. At your DNS provider, point `mta-sts.<yourdomain>` to your web host. At your web host, serve a file at `/.well-known/mta-sts.txt` with contents like: version: STSv1 mode: testing mx: mx.yourdomain.com max_age: 86400 Replace the mx value with your actual MX host (look at your domain's MX record).
- Add the DNS TXT record. At `_mta-sts.<yourdomain>`, publish a TXT record like `v=STSv1; id=2026052500;`. The id is any string you change when you update the policy.
- Verify the policy is reachable. Open `https://mta-sts.<yourdomain>/.well-known/mta-sts.txt` in a browser. It should return your policy as plain text. If it 404s or shows the wrong content, fix the web-host config first.
- Add a TLS-RPT record for failure reporting. At `_smtp._tls.<yourdomain>`, publish a TXT record: `v=TLSRPTv1; rua=mailto:tls-rpt@yourdomain.com`. You'll receive daily aggregate reports from major mail providers when TLS fails.
- Watch for a month, then switch to enforce mode. After 30 days of clean TLS-RPT reports, change the policy file from `mode: testing` to `mode: enforce`. Bump the id in the DNS TXT record so sending servers refresh their cache.
Owner: Your DNS administrator + your web host (the policy file needs to live on HTTPS). · Time: 20 minutes for the initial setup; 30-day watch period before enforcing.
Common gotchas
- The policy file must be served over HTTPS with a valid certificate. A self-signed or expired cert breaks MTA-STS for every sending server.
- Don't skip the 30-day testing period. If your mx record changes (provider switch) or your TLS cert expires, you've blocked your own inbound mail.
- MTA-STS protects inbound (people emailing your domain). Outbound (you emailing others) is the recipient's responsibility — you can't force them to publish MTA-STS for theirs.
- If your domain has subdomains that receive mail too, decide whether MTA-STS applies to them. The policy applies at the host you publish it for, not transitively.
How to verify the fix
Use Hardenize (hardenize.com) or Mecsa (mecsa.jrc.ec.europa.eu) for free MTA-STS + TLS-RPT validation. Or run a Vantyris scan — the Email category checks both.
Cyber Essentials alignment
This finding informs the following UK NCSC Cyber Essentials control areas:
- A2. Secure configuration — devices and services hardened against the inherent default vulnerabilities.
Vantyris is not a CE certifying body. The mapping above is informational.
Common follow-up questions
Is MTA-STS worth the effort if my email is hosted by Google or Microsoft?
Yes. Their outbound mail is fine without you doing anything. But MTA-STS protects INBOUND — mail other companies send TO you. That path is still vulnerable to downgrade without MTA-STS regardless of where your mailbox lives.
How is MTA-STS different from DANE?
DANE uses DNSSEC to bind TLS certificate fingerprints to mail hosts. It's more cryptographically rigorous but requires DNSSEC adoption (low among SMEs). MTA-STS is the HTTPS-based alternative — easier to deploy, slightly less rigorous, the consensus pragmatic standard today.
What if my sending counterparty doesn't support MTA-STS?
MTA-STS is enforced only by senders that fetch and honour the policy. Google, Microsoft, and most major receivers do. Smaller mail servers may not — those connections still happen in plain text. Adoption is a one-way ratchet; the more senders honour it, the more your mail is protected.
References
- RFC 8461 — MTA-STS IETF RFC
- RFC 8460 — SMTP TLS Reporting IETF RFC
- Google: MTA-STS configuration Vendor
Related explainers
- What is DMARC, and why every business with a domain needs one.
- DKIM: the cryptographic signature that completes your email authentication trio.
- SPF records, explained: the first line of defence against email spoofing.
Want Vantyris to scan your domain for this and 80 other findings?
Free teaser scan, no card. Verified scan from €10 with the full workspace around it: workflow, score trend, three PDF layouts, share links, monitoring.
Vantyris editorial team · methodology v1.0.0