Encryption you can require, not just hope for
Modes: testing first, then enforce
Policy and certificate managed for you
Email encryption is optional, and that’s the problem
When one mail server hands a message to another, it normally tries to encrypt the connection first. But in standard email that encryption is opportunistic: if it can’t be set up, the servers simply fall back to sending the message in plain text rather than not sending it at all. That keeps mail flowing, but it leaves a gap.
An attacker sitting in the network path can exploit that gap with a downgrade attack: quietly stripping the offer of encryption so the connection drops to plain text, then reading or even altering the message as it passes. MTA-STS (Mail Transfer Agent Strict Transport Security) removes the fallback. It is a published policy that tells every sending server: only deliver to me over a verified, encrypted connection, and if you can’t, don’t deliver at all.
Why this matters, whoever you are
- Where SPF, DKIM and DMARC protect mail sent as you, MTA-STS protects mail sent to you.
- Running your own domains? Inbound mail (invoices, contracts, password resets) can no longer be silently intercepted in transit.
- Managing clients? It’s a concrete encryption guarantee you can put in front of a client, on every domain you protect.
How it works: a policy plus a DNS pointer
MTA-STS has two moving parts that work together. A small DNS record tells sending servers a policy exists, and a policy file served over HTTPS spells out the rules. Because the policy is fetched over a properly certified HTTPS connection, a sending server can trust it really came from you, which is what makes the “you must encrypt” instruction trustworthy.
The DNS record and the policy file
The DNS record lives at _mta-sts.yourdomain.com and simply advertises that a policy exists, with an ID that changes whenever the policy does:
_mta-sts.example.com. TXT "v=STSv1; id=20260627T120000Z;"
The policy itself is hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and names the mail servers (your MX hosts) that are allowed to receive your mail, the mode, and how long to cache it:
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800
What a sending server does
- Sees the DNS record and knows to fetch your policy
- Downloads the policy over HTTPS and checks the certificate
- Confirms the server it’s connecting to is a listed MX host
- Requires a valid, encrypted TLS connection to deliver
- If encryption can’t be established, refuses to fall back to plain text
Start in testing, then move to enforce
MTA-STS is designed to be switched on safely. You begin in a mode that watches without blocking, prove your setup is sound, and only then turn on full enforcement, so you never accidentally stop your own legitimate mail.
Testing mode (report only)
Sending servers honour your policy but never block a message because of it; instead they note any problem and report it. Paired with TLS-RPT, this is your dress rehearsal: you can see exactly what enforcement would have done before it can affect a single message.
Enforce mode
Once the reports are clean, you flip to enforce. Now a sending server that can’t establish a verified, encrypted connection to a listed MX host will hold the message rather than deliver it insecurely. This is where the real protection kicks in.
The hard part: keeping it valid forever
MTA-STS is easy to publish once and surprisingly easy to get wrong over time. The policy has to be served from a working mta-sts web host with a TLS certificate that is always valid: the day that certificate expires, sending servers can no longer trust the policy. And the list of MX hosts in the policy has to stay perfectly in step with your real mail setup.
That last point is the classic trap: you change email providers or add a new mail server, the policy still names the old ones, and in enforce mode senders refuse to deliver to a host the policy doesn’t recognise. The protection that was meant to secure your mail ends up blocking it, quietly, with no obvious cause.
Where it goes wrong
- The HTTPS certificate on the policy host expires
- The policy lists MX hosts that no longer match your real ones
- Enforce is switched on before testing has proven it’s safe
- No TLS-RPT, so failures are completely invisible
- The policy ID isn’t updated when the policy changes
How DMARCER helps
DMARCER offers hosted MTA-STS: we host the policy file, run the HTTPS host, and keep its TLS certificate renewed for you, so the “forever” part takes care of itself. We help you start in testing mode, watch the TLS-RPT reports until they’re clean, and move you to enforce when it’s genuinely safe. Then we keep the policy in step with your MX and monitor it continuously, so a change to your mail setup can’t silently turn your encryption policy into a delivery blocker. For a business that’s enforced inbound encryption with nothing to maintain; for an MSP it’s the same guarantee, repeatable across every client.
Related
Hosted MTA-STS →
We run the policy and certificate for you.
TLS-RPT →
The reports that catch encryption failures.
MTA-STS checker →
Test your policy free, in seconds.
See where your MTA-STS stands
Run a free check to see your domain’s encryption posture, then let DMARCER host and maintain your MTA-STS policy for you.
Check your domain