MTA-STS Policy Not Found: Fixing DNS and HTTPS Deployment Failures

What This Error Means

The mxio MTA-STS Checker reports this error in two scenarios:

MTASTS_POLICY_FETCH_FAILED — The DNS TXT record at _mta-sts.example.com exists and is valid, but the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt cannot be retrieved. The sending server found your MTA-STS declaration in DNS but cannot download the actual policy it references.

MTASTS_DNS_ERROR — The DNS lookup for _mta-sts.example.com itself failed. No TXT record exists, the subdomain does not resolve, or the DNS query returned an error. Without this record, sending servers do not know your domain uses MTA-STS at all.

Both errors mean MTA-STS is not functioning for your domain. Sending servers that support MTA-STS (RFC 8461) will treat your domain as if MTA-STS is not deployed.

Why This Matters

MTA-STS tells sending mail servers that your domain requires TLS encryption for email delivery and that they should validate the receiving server's certificate. Without a working MTA-STS policy, your domain is vulnerable to downgrade attacks — a man-in-the-middle can strip STARTTLS from the SMTP conversation and intercept email in cleartext, even if your mail server supports TLS.

MTA-STS is the mechanism that upgrades SMTP TLS from opportunistic ("try TLS, fall back to cleartext") to mandatory ("require TLS or don't deliver"). When the policy is unreachable, that upgrade does not happen. Your mail server still supports TLS, but sending servers have no way to know that cleartext delivery should be refused.

For domains that handle sensitive communications — financial services, healthcare, legal — a broken MTA-STS deployment is a compliance gap. The policy exists to prevent exactly the class of attack that a missing policy leaves open.

How to Diagnose

MTA-STS has two independent components that must both work. Check them separately.

Check the DNS Record

Query the TXT record at _mta-sts.yourdomain.com:

dig TXT _mta-sts.yourdomain.com

A valid response looks like:

_mta-sts.yourdomain.com.  300  IN  TXT  "v=STSv1; id=20260408;"

If there is no TXT record, or the query returns NXDOMAIN, the DNS component is missing. Sending servers will not attempt to fetch the policy at all.

Check the Policy File

Attempt to fetch the policy file over HTTPS:

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

A valid response returns HTTP 200 with a plaintext body:

version: STSv1
mode: enforce
max_age: 604800
mx: mail.yourdomain.com
mx: backup.yourdomain.com

If curl returns a connection error, certificate error, 404, 403, or 500, the policy file is unreachable.

Use the mxio MTA-STS Checker

The mxio MTA-STS Checker performs both checks automatically — DNS record lookup and HTTPS policy fetch — and reports exactly which component failed, what error occurred, and what the expected configuration should be.

How to Fix

If the DNS Record Is Missing

Create a TXT record at _mta-sts.yourdomain.com with the following value:

v=STSv1; id=20260408;

The v=STSv1 tag identifies this as an MTA-STS record. The id field is a unique identifier that signals policy changes to sending servers — they cache the policy and re-fetch it when the id value changes. Use any string you want for the id (a date stamp works well). Update the id whenever you change the policy file.

In your DNS provider's control panel, the record looks like:

Some DNS providers want just _mta-sts as the name; others want the full _mta-sts.yourdomain.com. Follow your provider's convention.

If the Policy File Is Unreachable

The policy file must be served at exactly this URL:

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

Every part of that URL is a requirement. Here is what to verify:

1. The mta-sts subdomain exists. Create a DNS A or CNAME record for mta-sts.yourdomain.com pointing to a web server you control. This is a separate subdomain from your main website — it can point to the same server or a different one, but it must resolve.

2. HTTPS works with a valid certificate. The policy file must be served over HTTPS with a certificate that covers mta-sts.yourdomain.com. Self-signed certificates do not work. If you use Let's Encrypt, ensure the certificate includes this subdomain (either as a SAN or via a wildcard certificate for *.yourdomain.com).

Test the certificate:

openssl s_client -connect mta-sts.yourdomain.com:443 -servername mta-sts.yourdomain.com

The output should show a valid certificate chain with mta-sts.yourdomain.com in the subject or SAN list.

3. The .well-known directory is served. Some web servers block dotfiles or dot-directories by default. Ensure your server configuration allows requests to /.well-known/mta-sts.txt. For nginx:

location /.well-known/mta-sts.txt {
    root /var/www/mta-sts;
    default_type text/plain;
}

For Apache:

<Directory "/var/www/mta-sts/.well-known">
    Require all granted
</Directory>

4. The file exists at the exact path. Create the policy file at /.well-known/mta-sts.txt on the web server that handles requests for mta-sts.yourdomain.com. The file content should be plaintext with CRLF or LF line endings:

version: STSv1
mode: testing
max_age: 604800
mx: mail.yourdomain.com

Start with mode: testing while validating. In testing mode, sending servers fetch and evaluate the policy but do not enforce it — they still deliver email if TLS negotiation fails. Switch to mode: enforce after confirming everything works.

5. No redirects on the policy URL. RFC 8461 requires that the policy URL return a direct 200 response. HTTP-to-HTTPS redirects, www redirects, or any 3xx response on the policy URL may cause fetch failures with some sending servers.

6. Firewall allows inbound HTTPS. Ensure port 443 is open on the server hosting mta-sts.yourdomain.com. If the server is behind a CDN or reverse proxy, verify that requests to /.well-known/mta-sts.txt are not cached with stale content or blocked by WAF rules.

Verify the Fix

After setting up both components:

1. Confirm the DNS record: dig TXT _mta-sts.yourdomain.com
2. Confirm the policy file: curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
3. Run the mxio MTA-STS Checker to validate the complete configuration
4. Ensure the mx: lines in the policy match your actual MX records (see MTA-STS MX Mismatch if they do not)

Prevention and Ongoing Monitoring

MTA-STS breaks silently. When the policy file becomes unreachable — because a certificate expired, a server was decommissioned, or a CDN configuration changed — there is no bounce, no error message to your users. Sending servers simply stop enforcing your TLS policy and fall back to opportunistic encryption. You do not find out unless you are monitoring.

Common causes of MTA-STS breakage after initial deployment:

• Certificate expiry on the mta-sts subdomain. If your main site auto-renews but the MTA-STS subdomain is on a separate certificate, the renewal may not cover it.
• Server migration that moves your website but forgets the mta-sts subdomain.
• CDN or proxy changes that alter routing for the .well-known path.
• DNS changes that accidentally remove the _mta-sts TXT record or the mta-sts A/CNAME record.

Set up domain health monitoring to continuously verify your MTA-STS configuration alongside your SPF, DKIM, and DMARC records. Automated monitoring catches policy fetch failures the moment they start — before your TLS enforcement degrades.

Related Issues

• MTA-STS MX Mismatch — Policy file does not cover all MX hosts
• MTA-STS Configuration Issues — DNS record or policy file syntax errors
• STARTTLS Required Error — TLS negotiation failures in SMTP
• SMTP Server Test Explained — Testing TLS and SMTP connectivity