MTA-STS policy missing? Here’s how to fix it

You’re running email security checks on your domain, feeling pretty good about your DMARC setup, when suddenly you get hit with this error message: “MTA-STS policy is missing: STSFetchResult.NONE.”

Great. Another cryptic email authentication error to decode.

This warning is your email system saying it went looking for your MTA-STS policy file and couldn’t find it anywhere. MTA-STS (Mail Transfer Agent Strict Transport Security) is the protocol that guarantees your incoming emails use encrypted TLS connections instead of being sent in plain text where anyone can read them.

When MTA-STS is working correctly, it forces sending email servers to establish secure, encrypted connections before delivering messages to your domain. When it’s missing or broken, those same servers might fall back to unencrypted connections, leaving your email communications vulnerable to interception.

The “policy is missing” error typically means there’s a disconnect somewhere between your DNS configuration and the actual policy file that other email servers need to access:

• Your DNS might be pointing to the wrong location
• Your web server might not be serving the file properly
• The policy file itself could have formatting issues

Don’t panic. This error is completely fixable once you know what to look for. We’ll walk you through the most common causes of missing MTA-STS policies and show you exactly how to diagnose and resolve each one.

What is MTA-STS policy?

MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security protocol that forces incoming messages to your domain to use encrypted TLS connections. It’s basically HTTPS for email—it prevents your messages from being sent over insecure, unencrypted channels where they can be intercepted or tampered with.

The original SMTP protocol was built without security in mind. While the STARTTLS command was added later to enable encryption, it’s completely optional. Worse, it’s vulnerable to downgrade attacks where malicious actors can strip out the encryption request and force emails to be sent in plain text.

MTA-STS removes this vulnerability by creating a published policy that tells sending email servers, “you must use TLS encryption to deliver mail to this domain.” No exceptions, no fallbacks to unencrypted connections.

The policy itself is a simple text file that specifies which mail servers are authorized to receive email for your domain and what security requirements they must meet. It includes directives like which TLS version to use (1.2 or higher), which mail exchange servers are legitimate, and how long the policy should be cached.

For the policy to work, you need two components: 

1. A DNS TXT record that announces your domain supports MTA-STS
2. The actual policy file hosted on your web server where other email systems can retrieve it. 

When both pieces are in place and configured correctly, incoming emails to your domain get an extra layer of transport security that prevents eavesdropping and man-in-the-middle attacks.

The “MTA-STS policy is missing” error

The “MTA-STS policy is missing” error happens when an email server tries to retrieve your MTA-STS policy file and gets nothing back. It’s not finding a broken policy or a misconfigured one—it’s finding zero evidence that a policy exists at all.

Here’s how the discovery process is supposed to work: when an email server wants to send you a message, it first checks your DNS for an _mta-sts TXT record. If it finds one, it then tries to fetch your actual policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. If either of those steps fails completely, you get the “policy is missing” error.

This is different from other MTA-STS errors. A misconfigured policy might give you syntax errors or invalid directive warnings. A policy that’s present but has wrong settings might cause TLS connection failures. But “policy is missing” means the requesting server couldn’t even locate your policy file to begin evaluating it.

The impact varies depending on your policy mode. If you had your MTA-STS set to “enforce” mode before the policy went missing, sending servers that support MTA-STS will start rejecting emails to your domain entirely. If you were using “testing” mode, emails will still get delivered, but you’ll lose the transport security benefits and might see delivery warnings.

Unfortunately, this error can happen suddenly, even if MTA-STS was working fine before. A DNS change, web server reconfiguration, expired SSL certificate, or simple file permissions issue can make your policy file disappear from the perspective of external email servers (even though everything looks fine from your end).

Common causes of MTA-STS policy missing errors

Most errors come down to a handful of predictable problems. The good news is that once you know what breaks, fixing it becomes a lot easier:

• DNS record problems: Your _mta-sts DNS TXT record might be missing entirely, have syntax errors, or be pointing to the wrong policy version. Sometimes DNS changes take longer to propagate than expected, or the record gets accidentally deleted during other DNS updates. If external servers can’t find this record, they won’t even attempt to fetch your policy file.
• Subdomain configuration issues: The mta-sts subdomain (like mta-sts.yourdomain.com) needs to exist and resolve properly. If this subdomain isn’t set up in your DNS or is pointing to the wrong server, requests for your policy file will fail before they even reach your web server.
• Web server hosting problems: Your policy file needs to be accessible via HTTPS at the exact path /.well-known/mta-sts.txt. Web server misconfigurations, incorrect document root settings, or missing directory structures can make the file unreachable even if it exists on your server.
• SSL/TLS certificate failures: Since MTA-STS policy files must be served over HTTPS, any SSL certificate problems will prevent access. Expired certificates, incomplete certificate chains, or self-signed certificates that aren’t trusted will cause the policy fetch to fail.
• File location and permissions errors: The policy file might exist but be in the wrong location, have incorrect file permissions that prevent the web server from reading it, or be owned by the wrong user. These are especially common after server migrations or when different teams handle DNS and web hosting.
• Policy file syntax problems: Syntax errors in your MTA-STS policy file can cause some validators to report it as missing. Incorrect directives, wrong formatting, or encoding issues can make an otherwise accessible file unusable.

Step-by-step troubleshooting guide

The best way to fix MTA-STS policy issues is by working through the discovery process in the same order that external email servers do. Start from the DNS level and work your way down to the actual policy file:

1. Check your DNS TXT record for _mta-sts: Use a DNS lookup tool or command line to verify your _mta-sts record exists and has the right syntax. The record should look something like v=STSv1; id=20240101T000000; and be published at _mta-sts.yourdomain.com. If it’s missing or has syntax errors, external servers will never attempt to fetch your policy file.
2. Verify the mta-sts subdomain resolves: Test that mta-sts.yourdomain.com actually points to a working server. You can do this with a simple ping or by checking DNS resolution. If this subdomain doesn’t exist or points to the wrong IP address, policy file requests will fail before reaching your web server.
3. Test HTTPS access to your policy file: Try accessing https://mta-sts.yourdomain.com/.well-known/mta-sts.txt directly in your browser or with curl. You should get a successful HTTPS connection and see your policy file content. SSL certificate errors, 404 responses, or connection timeouts indicate hosting problems.
4. Validate policy file syntax and content: Once you can access the file, check that it follows proper MTA-STS syntax. Make sure it includes required directives like version: STSv1, mode: testing or mode: enforce, at least one mx: directive, and max_age:. Missing or malformed directives can make validators treat the policy as unusable.
5. Check web server configuration and permissions: Verify that your web server is configured to serve files from the .well-known directory and that file permissions allow the web server to read your policy file. Common issues include restrictive directory permissions or web server configurations that block access to dotfiles.
6. Verify certificate validity and chain: Use SSL testing tools to confirm your certificate is valid (not expired) and includes the complete certificate chain. Self-signed certificates or incomplete chains will prevent external servers from trusting your policy file, even if it’s otherwise accessible.

When to use testing vs enforce mode

Your MTA-STS policy mode determines what happens when email servers can’t establish secure connections to your domain. Getting this wrong can either leave you vulnerable or block legitimate emails entirely.

Start with testing mode when you’re first implementing MTA-STS or troubleshooting existing issues. In testing mode, emails still get delivered even if TLS connections fail, but you’ll receive TLS-RPT reports showing which senders had problems. This gives you visibility into potential issues without risking email delivery.

Use testing mode to identify problems like outdated certificates on your mail servers, senders that don’t support modern TLS versions, or configuration issues with your MX records. Monitor your TLS-RPT reports for several weeks to catch patterns and edge cases.

Switch to enforce mode only after you’ve confirmed that legitimate email traffic can consistently establish secure connections. In enforce mode, senders that can’t meet your TLS requirements will bounce emails back rather than delivering them insecurely.

Keep testing mode during major changes like mail server migrations, certificate renewals, or MX record updates. You can always temporarily switch back to testing if you need to troubleshoot new delivery issues without blocking emails.

Get your email transport security working (and keep it that way)

Troubleshooting MTA-STS policy errors doesn’t have to become a recurring nightmare. You’ve got the steps to fix what’s broken, but wouldn’t it be nice if this stuff just worked without you having to become a DNS and web server expert?

Strong email authentication starts with visibility. With Valimail Monitor and Enforce, you can easily publish your MTA-STS and TLS Reporting policies through the Valimail API and begin receiving MTA-STS TLS Reports, all without complex setup or manual monitoring.

Hosting of MTA-STS is available exclusively to Valimail Enforce users, but TLS Reporting is accessible to all Monitor and Enforce customers, allowing you to start improving your security posture today.

Gain the insights you need to strengthen your email infrastructure, detect potential delivery issues, and prepare for full enforcement with confidence.