DMARC stops unauthorized senders from impersonating your domain. But even when both mail servers support encryption, the connection between them is not guaranteed to be encrypted. An attacker on the network path can strip encryption silently or redirect email to a server they control. MTA-STS fixes that.
MTA-STS (RFC 8461) tells sending mail servers: "Only deliver email to my domain over a verified encrypted connection, and only to these specific mail servers. If encryption fails, do not deliver." It is HTTPS for email delivery.
What you will learn
What happens without MTA-STS
A downgrade attack in 4 steps
Step 1. Your company uses Gmail or Microsoft 365. Both support TLS. Email between your domain and your partners normally travels encrypted. Everything looks fine.
Step 2. An attacker gains access to a network between the sending and receiving mail server. This could be a compromised ISP router, a rogue Wi-Fi access point, or a BGP hijack. The attacker does not need access to either mail server.
Step 3. When the sending server asks "Do you support TLS?" the attacker intercepts the response and removes the STARTTLS capability. The sending server thinks TLS is not available. It falls back to plain text and delivers the email unencrypted.
Step 4. The attacker reads the email contents: contracts, invoices, credentials, confidential business data. Neither sender nor recipient gets any warning. The email arrives normally.
This is called a STARTTLS downgrade attack. It is not theoretical. The MTA-STS RFC itself was created specifically because these attacks were observed in the wild. Nation-state actors and ISP-level adversaries have used them to conduct mass surveillance of email traffic.
MTA-STS prevents this. When your domain publishes an MTA-STS policy set to mode: enforce, the sending server knows your mail servers always support TLS. If the STARTTLS response gets stripped, the sender refuses to deliver rather than falling back to plain text.
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.
The problem: STARTTLS is optional
When two mail servers talk to each other, they use SMTP. The connection starts unencrypted. 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: STARTTLS is opportunistic. If anything goes wrong, the sending server 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.
DNS TXT record (the signal)
Tells senders you have a policy to fetch
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.
Policy file over HTTPS (the rules)
Lists your MX hosts and enforcement mode
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.
What the sending server does
The verification and delivery flow
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).
Technical details: policy file format and modes
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
none
Deliver normally. No enforcement, no reporting.
Use when disabling the policy without removing DNS records.
testing
Deliver anyway, but send a failure report.
Start here. See what would break before enforcing.
enforce
Refuse to deliver. Email bounces back to sender.
Switch to this after confirming all MX hosts support TLS with valid certificates.
Setting up MTA-STS step by step
Start in testing mode. Just like DMARC, MTA-STS has a monitoring phase. Deploy with mode: testing first and review TLSRPT reports for 1-2 weeks before switching to mode: enforce.
List your MX hosts
Find out which servers receive email for your domain
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
Plain text file with your MX hosts and mode
Create a plain text file with your MX hosts. Start with mode: testing.
If you use a hosted email provider, you need wildcard patterns instead of exact hostnames. Getting this wrong is the most common cause of MX mismatch errors.
Microsoft 365 / Exchange Online
mx: *.mail.protection.outlook.com
Google Workspace
mx: *.aspmx.l.google.com
mx: *.googlemail.com
Host the policy over HTTPS
Serve the file with a valid TLS certificate
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.
Skip the hosting step
DMARCTrust can host your MTA-STS policy for you. Instead of setting up a web server, you publish one CNAME record and we handle the HTTPS hosting, TLS certificate, and policy file. We also auto-generate the policy ID so your DNS TXT record always stays in sync. See what the Receiver Shield module shows inside the dashboard.
Publish the DNS records
Two TXT records: the MTA-STS signal and TLSRPT reporting
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
Review TLSRPT reports before tightening the policy
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.
DMARCTrust receives and analyzes TLS-RPT reports for you. Point your TLSRPT rua= address to your DMARCTrust reporting mailbox and we parse the daily JSON reports, surface failure types, identify problem MX hosts, and tell you when it is safe to switch to enforce. No need to build your own report parser. Check your domain to see your current TLS-RPT status.
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. See MX and certificate mismatches.
HTTP redirect on the policy URL
RFC 8461 Section 3.3 prohibits following HTTP redirects. If your web server redirects http:// to https:// (common with Certbot or Cloudflare), some senders will get a 301 instead of the policy and give up. See policy fetch failures.
max_age below 86400
Google silently ignores MTA-STS policies with max_age under 86400 seconds (1 day). If you set a low value for testing, Google treats it as no policy at all. See enforce mode and cache traps.
Cloudflare blocking non-browser fetches
Cloudflare's Browser Integrity Check blocks requests from mail servers (they use non-browser User-Agents). The policy loads in your browser but fails for actual MTAs. Create a WAF rule to skip security checks for mta-sts.* requests. See policy fetch failures.
Validating your setup
Run these checks after deploying MTA-STS:
If any of these fail, fix the issue before switching to mode: enforce.
Skip the command line
Our free domain checker validates your MTA-STS DNS record, fetches your policy file, checks your TLS-RPT record, and grades your email security setup. All four checks above, in one click.
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 shows you real TLS failures before they cause bounced email.
Next steps
Here is a practical rollout plan:
- Check your current state. Use our domain checker to see if your domain already has MTA-STS and TLSRPT records
-
List your MX servers. Run
dig MX yourdomain.com +shortand verify each server supports TLS with a valid certificate -
Deploy in testing mode. Publish your policy file and DNS records with
mode: testing - Monitor TLSRPT reports. Review daily reports for 1-2 weeks to catch TLS failures
-
Switch to enforce. Once reports show no failures, update to
mode: enforceand bump the DNS id - Keep monitoring. TLSRPT reports continue in enforce mode. Watch for certificate expirations or MX changes that could break delivery
Troubleshooting
If something breaks after deploying MTA-STS, these guides cover every common failure:
- Policy fetch failures: sts-policy-fetch-error, hosting, and certificate problems
- MX and certificate mismatches: uncovered hosts, wrong certs, and missing STARTTLS
- Enforce mode: safe deployment, emergency rollback, and cache traps
- TLS-RPT reports: missing data, failure types, and how to read them
Learn more
Related guides:
- Free DMARC checker: check your domain's email security
- Introduction to DMARC: stop spoofing and protect email
- SPF explained: strengths, weaknesses and role in DMARC
- DKIM deep dive: pros, cons and alignment with DMARC
- DMARC alignment explained: why SPF and DKIM pass but DMARC fails
Sources and further reading
- RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
- RFC 8460 - SMTP TLS Reporting (TLSRPT)
- RFC 7672 - SMTP Security via Opportunistic DANE TLS
- Google Workspace: Set up MTA-STS and TLSRPT
Do not forget the DNS id. The most common MTA-STS failure is updating the policy file but not the DNS id value. Senders only re-fetch your policy when the id changes. If you change your MX hosts or switch from testing to enforce, always bump the id in the same update.