MTA-STS in practice: the 7 issues that break deployments (and how to fix them)

We launched Receiver Shield a few weeks ago. Since then we have been processing TLS-RPT reports across our customer base, reading community forums, and studying what actually goes wrong when people deploy MTA-STS.

The standard itself is straightforward. Three DNS records, one policy file, one mode switch. But the operational surface is wider than it looks. Small mistakes cause silent failures. Things work in your browser but break for sending mail servers. You change one record and forget another, and email stops arriving three days later when a cache expires.

This post documents the 7 most common MTA-STS failures we have seen. Each one links to a detailed troubleshooting guide on our docs site with diagnosis commands and step-by-step fixes.

1. The policy file is unreachable

This is the single most common failure. TLS-RPT reports show sts-policy-fetch-error, which means the sending server tried to fetch https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and got something other than HTTP 200 with the policy content.

Here is what goes wrong:

• Wrong path. The file must be at /.well-known/mta-sts.txt, not /mta-sts.txt or anywhere else.
• HTTP redirect. RFC 8461 Section 3.3 prohibits following redirects. If Certbot or Cloudflare redirects http:// to https://, some senders get a 301 and give up. The policy works in your browser (which follows redirects) but fails for MTAs (which must not).
• Cloudflare Browser Integrity Check. Cloudflare’s BIC blocks requests with non-browser User-Agent strings. Mail servers use agents like libwww-perl/6.68. The policy loads fine when you test it in Chrome, but MTAs get a challenge page instead of the policy file.
• GitHub Pages. Jekyll ignores directories starting with a dot. If you host on GitHub Pages without a .nojekyll file in the repository root, the /.well-known/ path returns 404.
• Expired certificate. The mta-sts subdomain needs a valid CA-signed TLS certificate. If your Let’s Encrypt renewal did not include the mta-sts subdomain, the cert expires and every policy fetch fails silently.

The fix depends on the cause, but the diagnosis is always the same:

curl -I https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

If that does not return HTTP/2 200 with content-type: text/plain, you have a problem. Our policy fetch failures guide walks through each cause with the exact fix.

If you want to skip the hosting complexity entirely, Receiver Shield (Pro plan) serves the policy for you. One CNAME record, no web server, no certificate to manage.

2. MX records not covered by the policy

The second most common failure. TLS-RPT reports show mx-mismatch or your MTA-STS validator flags “uncovered MX records.”

This happens when the mx: lines in your policy file do not match your actual MX DNS records. In enforce mode, senders refuse to deliver to any MX host not listed in the policy.

The tricky part is that hosted email providers use dynamic hostnames. You cannot list the exact hostname. You need a wildcard.

Microsoft 365 assigns MX records like yourdomain-com.mail.protection.outlook.com. The correct policy entry is:

mx: *.mail.protection.outlook.com

Not mx: mail.protection.outlook.com (missing the wildcard) and not the exact tenant-specific hostname (it varies by region).

Google Workspace uses two families of MX hostnames. You need both:

mx: *.aspmx.l.google.com
mx: *.googlemail.com

Missing either one leaves MX records uncovered.

There is also a Microsoft-specific gotcha: Exchange Online does not follow CNAME records when validating MTA-STS. If your MX target is a CNAME (common in shared hosting), Microsoft’s validation fails while Gmail works fine. You only see the failure in Microsoft’s TLS-RPT reports.

Full diagnosis and per-provider patterns are in our MX and certificate mismatches guide.

3. Certificate on the MX server does not match the hostname

TLS-RPT reports show certificate-host-mismatch. The TLS certificate presented by your mail server during the SMTP STARTTLS handshake does not include the MX hostname in its Subject Alternative Names.

This is different from the certificate on the mta-sts subdomain (issue #1). This is the certificate on the actual mail server that receives email.

Common scenario: your hosting provider’s mail server has a certificate for mail.hostingprovider.com, but your MX record points to mail.yourdomain.com. The certificate does not cover your hostname, so MTA-STS validation fails.

Diagnose it with:

openssl s_client -starttls smtp -connect mail.yourdomain.com:25 \
  -servername mail.yourdomain.com </dev/null 2>/dev/null | \
  openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

If your hostname is not in the SAN list, contact your mail hosting provider. Most managed providers (Google, Microsoft, Fastmail) handle this correctly. It is most common with self-hosted servers and smaller hosting providers.

Our MX and certificate mismatches guide covers incomplete certificate chains and missing STARTTLS as well.

4. The policy ID is not updated after a change

This is the most common operational mistake. It is invisible until something breaks days later.

MTA-STS requires three things to stay in sync:

1. Your actual MX DNS records
2. The mx: entries and mode in your mta-sts.txt policy file
3. The id value in your _mta-sts DNS TXT record

When you change the policy file (for example, switching from mode: testing to mode: enforce), you must also change the id in the DNS TXT record. Senders cache the policy for max_age seconds. They only re-fetch when they see a new id. If the id stays the same, senders keep using the old cached policy.

With max_age: 604800 (7 days), your fix does not take effect for up to a week. With max_age: 2592000 (30 days), you are stuck for a month.

This is also why Receiver Shield auto-generates the policy ID from the policy content. When you edit the policy in the dashboard, the id updates automatically. You still need to update your DNS TXT record, but the dashboard tells you exactly when it is out of sync.

Our enforce mode and rollback guide covers the three-point sync rule in detail.

5. Jumping to enforce mode too early

Teams that skip the testing phase and go straight to mode: enforce learn about their problems the hard way: legitimate email stops arriving.

Microsoft Exchange Online sends specific NDR (non-delivery report) codes when MTA-STS enforcement blocks delivery:

• 551 5.7.4 STARTTLS is required by recipient domain’s MTA-STS policy
• 551 5.4.8 MX hosts of ‘domain’ failed MTA-STS validation
• 551 5.7.5 Remote certificate failed MTA-STS validation

If you see these bounce codes in your logs, your MTA-STS enforce mode is rejecting mail from senders that cannot meet the TLS requirements. The fix is to switch back to mode: testing, bump the id, and investigate.

There are two additional traps related to max_age:

• Too high on first deploy. Some guides show max_age: 31557600 (1 year). If anything is misconfigured, senders who cached the broken policy keep using it for up to a year. Start with max_age: 86400 (1 day) during testing. Increase once you are confident.
• Too low. Google silently ignores MTA-STS policies with max_age below 86400 seconds. If you set max_age: 3600 for quick testing, Google treats it as if you have no policy at all.

Our enforce mode and rollback guide includes a step-by-step emergency rollback procedure.

6. TLS-RPT reports are not arriving

You publish the _smtp._tls DNS record, wait a few days, and nothing arrives. This is normal and does not mean something is broken.

TLS-RPT reports come from the sending side. Only mail servers that have implemented RFC 8460 will send you reports. Today, that means Google, Microsoft, Comcast, Mail.ru, and a few others. If your domain does not receive much email from these providers, you will see few reports.

Other common causes:

• Wrong rua address. A typo in the mailto: value. Check with dig TXT _smtp._tls.yourdomain.com +short.
• Reports landing in spam. Google sends reports from [email protected] with a .json.gz attachment. If you have never seen one before, it looks suspicious. It is legitimate. Whitelist it.
• Microsoft only sends to the first rua. If you list multiple addresses (your inbox and a monitoring service), Microsoft delivers only to the first one. Put your monitoring service first.

The reports themselves are JSON, and reading them manually is not practical. Receiver Shield parses them automatically: failures grouped by type, by sender, by MX host, with trends over time. No .json.gz files to decompress, no JSON to decode.

Our TLS-RPT report failures guide covers every failure type with diagnosis commands.

7. Improper MTA-STS removal

When you want to disable MTA-STS, the instinct is to delete the DNS records and the policy file. This is wrong, and it can break email delivery for weeks.

Senders that previously fetched your enforce-mode policy have it cached. If the policy file disappears, those senders continue enforcing the cached version until max_age expires. If your MX hostnames or certificates change during that window, the cached policy no longer matches, and email bounces.

The correct procedure:

1. Change the policy mode to none in the policy file
2. Update the id in the _mta-sts DNS TXT record so senders re-fetch
3. Keep the policy file accessible for at least max_age seconds
4. Only then remove the DNS records

This is the MTA-STS equivalent of DMARC’s “do not jump from p=reject to removing the record.” Receiver Shield handles this automatically: when you disable hosting, we transition to mode: none and keep serving until caches expire.

Our enforce mode and rollback guide explains the full teardown sequence.

The pattern behind these failures

Most of these issues share a root cause: MTA-STS requires three separate systems (DNS, HTTPS hosting, and mail server TLS) to stay synchronized, and there is no built-in feedback loop. You make a change, and if something is wrong, you find out days later when a sender’s cache expires or when TLS-RPT reports arrive.

That delay between action and feedback is what makes MTA-STS harder to operate than DMARC. With DMARC, you publish a record and start receiving aggregate reports within 24 hours. With MTA-STS, you publish records, host a policy file, configure TLS on your MX servers, wait for senders to fetch the policy, wait for TLS-RPT reports to accumulate, and then parse the JSON to figure out if anything is wrong.

Receiver Shield shortens that loop. It handles the hosting, parses the reports, and tells you what would break before you enforce. If you are evaluating MTA-STS for the first time, start with our MTA-STS guide and run your domain through the free domain checker to see your current status.