DMARC stops unauthorized senders from impersonating your domain. But the connection carrying your mail between servers is still exposed, and anyone on the network with the right tools can intercept the envelope, read it, or swap it for a different one. That is the problem MTA-STS solves.
MTA-STS is HTTPS for email delivery. Just like your browser refuses to load a banking website over plain HTTP, MTA-STS tells sending mail servers: "Only deliver email to us over an encrypted connection, and only to these specific mail servers. If encryption fails, do not deliver at all."
Without MTA-STS, an attacker sitting between two mail servers can silently strip encryption (a "downgrade attack") or redirect email to a server they control. This happens even when both servers support TLS, because STARTTLS is optional by default. The sending server just falls back to plain text and keeps going.
Where MTA-STS fits in your email security. SPF, DKIM, and DMARC protect the identity of the sender. MTA-STS protects the transport, the connection between mail servers. You need both. DMARC without MTA-STS is like signing a letter but sending it on a postcard: authenticated, but readable by everyone who handles it.
What you will learn
The problem: STARTTLS is optional
When two mail servers talk to each other, they use SMTP. The connection starts unencrypted, and then the sending server asks "Do you support TLS?" If the receiving server says yes, they upgrade to an encrypted connection. This is STARTTLS.
The problem is that STARTTLS is opportunistic. If anything goes wrong, the sending server shrugs and delivers the email in plain text. This creates two attack vectors:
Downgrade attack
An attacker on the network strips the STARTTLS response from the receiving server. The sending server thinks TLS is not available and falls back to plain text. The attacker reads everything.
MTA-STS fixes both. It tells sending servers: "I always support TLS, and my real mail servers are these specific hostnames. If something looks wrong, refuse to deliver." Because the policy is served over HTTPS (not DNS), it cannot be tampered with by the same network attacker.
MTA-STS vs DANE vs STARTTLS
Three protocols address email transport encryption. They solve different problems and work at different layers:
| STARTTLS | MTA-STS (RFC 8461) | DANE (RFC 7672) | |
|---|---|---|---|
| What it does | Upgrades SMTP to TLS if both sides agree | Requires TLS and pins MX hostnames via HTTPS policy | Pins TLS certificates in DNS via DNSSEC |
| Stops downgrade? | No | Yes | Yes |
| Stops MX hijacking? | No | Yes (pins MX hosts) | Yes (pins certificates) |
| Requires DNSSEC? | No | No | Yes (this is the catch) |
| Provider support | Nearly universal | Gmail, Outlook, and growing | Limited (requires DNSSEC on both sides) |
| Setup difficulty | Automatic on most servers | Moderate (DNS + HTTPS hosting) | Hard (DNSSEC + TLSA records) |
In practice, MTA-STS is the one to deploy. DANE provides stronger cryptographic guarantees, but it requires DNSSEC, which most domains do not have. MTA-STS works with standard DNS and standard HTTPS certificates, making it practical for any domain. If your DNS provider supports DNSSEC, you can deploy both.
How MTA-STS works
MTA-STS has two components that work together: a DNS record that advertises you have a policy, and an HTTPS-hosted file that contains the actual policy.
1. DNS TXT record (the signal)
A TXT record at _mta-sts.example.com tells sending servers: "I have an MTA-STS policy. Go fetch it."
The id value is a version string you choose. Change it whenever you update the policy file, so senders know to re-fetch.
2. Policy file over HTTPS (the rules)
The actual policy lives at https://mta-sts.example.com/.well-known/mta-sts.txt. It must be served over HTTPS with a valid certificate.
Senders cache this policy for max_age seconds (604800 = 7 days). During that time, they require TLS and only deliver to the listed MX hosts.
3. What the sending server does
Before delivering email to your domain, the sending server looks up your MTA-STS DNS record, fetches the policy over HTTPS, connects to one of your listed MX hosts, requires a valid TLS certificate, and delivers. If TLS fails or the MX host is not in the policy, the sender refuses to deliver (in enforce mode) or delivers anyway but sends you a report (in testing mode).
Policy file format
The policy file is plain text with four fields. Serve it at https://mta-sts.example.com/.well-known/mta-sts.txt with a valid TLS certificate.
| Field | Values | What it does |
|---|---|---|
| version | STSv1 | Always STSv1. No other value exists. |
| mode | none | testing | enforce | How strictly senders should follow the policy. |
| mx | hostname or *.wildcard | Which mail servers are allowed to receive email. One line per host. |
| max_age | seconds (e.g., 604800) | How long senders cache the policy. 604800 = 7 days is a good default. |
The three modes
| Mode | What happens on TLS failure | When to use |
|---|---|---|
| none | Deliver normally. No enforcement, no reporting. | Disabling the policy without removing DNS records. |
| testing | Deliver anyway, but send a failure report. | Starting out. See what would break before enforcing. |
| enforce | Refuse to deliver. Email bounces back to sender. | You have confirmed all MX hosts support TLS with valid certificates. |
Setting up MTA-STS step by step
List your MX hosts
Check which mail servers receive email for your domain:
Write down every hostname. You will need them for the policy file.
Create the policy file
Create a plain text file with your MX hosts. Start with mode: testing.
Host the policy over HTTPS
Serve the file at https://mta-sts.example.com/.well-known/mta-sts.txt. The subdomain mta-sts.example.com must have a valid TLS certificate.
Options: a dedicated web server, a CDN like Cloudflare Pages, GitHub Pages, or a static hosting service. The file rarely changes, so any cheap hosting works.
Publish the DNS records
Add two TXT records to your domain's DNS:
Change the id value every time you update the policy file. Use a date stamp (20250315) or an incrementing number.
Monitor, then enforce
Wait for TLSRPT reports to arrive (daily, from providers that support it). If no failures appear after 1-2 weeks, switch your policy to mode: enforce and update the DNS id.
TLSRPT: monitoring TLS failures
TLSRPT (RFC 8460) is the reporting companion to MTA-STS, like DMARC's rua reports but for transport encryption. Sending servers that support TLSRPT send you daily JSON reports listing any TLS connection failures they encountered.
You can also use https:// URIs to receive reports via webhook instead of email.
Deploy TLSRPT before switching to mode: enforce. It tells you whether any legitimate senders are failing TLS, so you can fix issues before they cause bounced email.
Common mistakes
These errors silently break MTA-STS. Your DNS record may look fine, but senders ignore the policy.
Policy served over HTTP (not HTTPS)
The policy file must be served over HTTPS with a valid certificate. An HTTP URL or an expired/self-signed certificate means senders cannot trust the policy.
MX host missing from the policy
Every MX hostname in your DNS must appear in the policy file. If you add a new MX record but forget to update the policy, senders in enforce mode refuse to deliver to that server.
DNS id not updated after policy change
Senders cache the policy for max_age seconds. They only re-fetch when the id in DNS changes. If you update the policy file but not the DNS id, senders keep using the old cached version.
max_age too short
A very short max_age (like 3600 = 1 hour) forces senders to re-fetch your policy constantly. If your HTTPS host goes down briefly, senders lose the cached policy and fall back to no enforcement. Use at least 604800 (7 days).
MX server TLS certificate mismatch
The TLS certificate on your MX server must match the hostname listed in the policy. If your policy says mx: mx1.example.com but the server's certificate is for mail.hosting-provider.com, senders in enforce mode reject the connection.
Validating your setup
Run these checks after deploying MTA-STS:
If any of these fail, fix the issue before switching to mode: enforce.
You can also check your domain's MTA-STS and TLS status using our free domain checker.
Operational tips
- Automate the id bump. Use a deployment script that updates both the policy file and the DNS TXT record at the same time. A date stamp (20250315) or a hash of the policy file contents works well.
-
Keep the HTTPS host simple. The
mta-sts.example.comsubdomain only needs to serve one file. A static site on Cloudflare Pages, GitHub Pages, or an S3 bucket with CloudFront is plenty. -
Plan for emergencies. If you need to remove MTA-STS enforcement quickly (e.g., you are migrating mail servers), switch to
mode: none, update the DNS id, and wait for caches to expire. A shortermax_age(86400 = 1 day) during the transition helps. - Use TLSRPT from day one. Do not wait until enforce mode. Testing mode with TLSRPT gives you visibility into real-world TLS failures before they cause bounced email.