Why it matters
Email is the transport for most targeted attacks. An attacker positioned between your server and the receiver’s can exploit two distinct vulnerabilities:
Downgrade attack: If the destination server supports TLS but the negotiation fails (or is disrupted), the sending server can fall back to plaintext. Your email travels unencrypted across the network.
DNS spoofing (MX hijacking): An attacker can manipulate DNS responses to replace your MX records with a server they control. The sender delivers the email straight to the attacker, who reads it, optionally manipulates it, and forwards it to the real destination as if nothing happened. Since MX records point to domain names (not IPs), the attacker can use their own domain with a valid certificate, so STARTTLS alone doesn’t protect against this.
MTA-STS is the solution to both problems: it publishes a policy over HTTPS (which resists MITM attacks, unlike DNS) telling servers worldwide that if they want to deliver email to your domain, they MUST encrypt - there’s no plaintext option, and that the only valid MX hosts are those listed in the policy. If they can’t encrypt or the MX doesn’t match, the email gets rejected.
Without it, anyone with access to your network (ISP, compromised router, local network attack) can read or manipulate your emails, even though the origin server supports TLS.
The problem
Without MTA-STS, even if your server supports TLS, the sender can fall back to plaintext if negotiation fails, or an attacker can redirect the email by manipulating DNS. Your email travels unencrypted or to the wrong destination.
What it does
Tells the world: “If you send me email, you MUST use TLS. If you can’t encrypt, DON’T deliver.” Additionally, sending servers verify that the MX they connect to matches the policy published over HTTPS.
Implementation
1. DNS TXT (assertion record)
This record indicates your domain supports MTA-STS. The id must change every time you modify the policy:
_mta-sts.yourdomain TXT "v=STSv1; id=20260304"
2. DNS record for the mta-sts subdomain
You need an A or CNAME record so that mta-sts.yourdomain points to the web server hosting the policy file:
mta-sts.yourdomain A 203.0.113.10
Or if using a hosting service:
mta-sts.yourdomain CNAME your-hosting.example.com
3. Policy file
At https://mta-sts.yourdomain/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
max_age: 604800
The mx values must match the MX records in your DNS that support TLS. The max_age (in seconds) indicates how long sending servers can cache the policy - the recommended minimum is one week (604800).
Available modes:
testing- the sender can fall back to plaintext if TLS fails, but reports the failureenforce- if TLS can’t be established, the email is not deliverednone- disables MTA-STS (useful if you previously used it and want to deactivate it gracefully)
4. TLS-RPT
_smtp._tls.yourdomain TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain"
🛡️ Start with mode: testing. Once everything works, switch to enforce.
SPF = who can send. DKIM = signature. DMARC = what to do with failures. MTA-STS = encryption in transit.
Verification
Once deployed, verify it’s working:
- DNS: Use
digor an online DNS tool:
dig _mta-sts.yourdomain TXT
dig _smtp._tls.yourdomain TXT
You should see your records published.
-
Policy file: Visit
https://mta-sts.yourdomain/.well-known/mta-sts.txtin your browser. It should return the file without errors. -
Testing mode: Keep it in
mode: testingfor 1-2 weeks. Check the TLS-RPT reports (sent to the email you set inrua=) to see if there are any connection issues. -
Switch to enforce: Only when reports show 100% encrypted deliveries, change to
mode: enforce.
Useful tools:
- MTA-STS Checker - validates your configuration
- DMARC Report Analyzer - if you need DMARC context too
Learn more
For user-level phishing protection, read Detect a phishing email in 10 seconds.
By: Cesar Rosa Polanco - Written from a real experience, with the assistance of artificial intelligence as a cognitive amplification tool.