MTA-STS Checker
Enter any domain to check its MTA-STS configuration. We validate the DNS record, fetch the policy file, check the enforcement mode, and verify TLS-RPT reporting so you know whether encrypted email delivery is actually being enforced.
Understanding Your MTA-STS Check
Here's what each result means and what to do next.
MTA-STS Pass
Your domain enforces encrypted email delivery
A passing result means your MTA-STS DNS record exists, your policy file is correctly hosted and formatted, and your policy mode is set to enforce. Sending servers that support MTA-STS will require a verified TLS connection before delivering email to your domain. To complete your encrypted delivery setup, make sure TLS-RPT is also configured so you get reports when connections fail.
- Valid MTA-STS DNS record found
- Policy file is accessible and correctly formatted
- Policy mode is set to enforce
- MX hosts are listed and match your mail servers
MTA-STS Warning
Your configuration works but has issues worth addressing
A warning means your MTA-STS configuration is partially working but not providing full protection. The most common warning is a policy mode set to testing, which logs TLS failures but still allows plaintext delivery. This is the right starting point, but you need to move to enforce once you've confirmed all sending servers can establish TLS connections with your mail servers.
- Policy mode is set to testing (not enforcing)
- Max age is too short for reliable caching
- MX hosts in policy don't fully match DNS MX records
- TLS-RPT is not configured
MTA-STS Fail
Your domain is not enforcing encrypted email delivery
A failing result means your domain is not enforcing encrypted email delivery. Without MTA-STS, email connections to your mail servers can be silently downgraded to plaintext by network attackers. The most common causes are a missing DNS record, a policy file that is not hosted at the correct URL, or a policy file with formatting errors. Both the DNS record and the hosted policy file are required for MTA-STS to work.
- No MTA-STS DNS record found
- Policy file is missing or inaccessible
- Policy file has syntax or formatting errors
- No MX hosts listed in the policy
Common MTA-STS Problems and How to Fix Them
These are the MTA-STS problems we see most often. If your check flagged any of these, here's what they mean and how to fix them.
Missing Policy File
MTA-STS requires two components working together: a TXT record in DNS and a policy file hosted on your web server. Many domains publish the DNS record but forget to host the policy file (or host it at the wrong URL). The policy file must be accessible at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over a valid HTTPS connection. Without it, sending servers find the DNS record but have no policy to follow.
Stuck in Testing Mode
Testing mode is the right way to start with MTA-STS. It tells sending servers to attempt TLS and report failures, but still allows plaintext delivery if TLS fails. The problem is staying in testing mode indefinitely. While it gives you visibility through TLS-RPT reports, it does not actually prevent downgrade attacks. Once you have confirmed that all major senders can establish TLS connections, switch to enforce mode.
MX Host Mismatch
The MX hosts listed in your MTA-STS policy file must match the MX records in your DNS. If a sending server resolves your MX records and finds a host that is not listed in the policy file, it may refuse to deliver email to that server (in enforce mode) or report a failure (in testing mode). This is especially common after changing email providers or adding backup mail servers without updating the policy file.
No TLS-RPT Configured
TLS-RPT is the companion protocol to MTA-STS. It tells sending servers where to send reports when they encounter TLS connection issues with your mail servers. Without TLS-RPT, you have no way to know when encrypted delivery is failing. You could be losing emails or falling back to plaintext without any visibility. Adding a TLS-RPT record takes minutes and gives you the data you need to troubleshoot and maintain MTA-STS.
Why MTA-STS Matters for Your Business
MTA-STS is the protocol that enforces encrypted email delivery. Without it, TLS connections can be silently downgraded to plaintext, exposing your messages to interception.
Email Can Be Intercepted in Transit
Without MTA-STS, attackers can perform TLS downgrade attacks that force email connections to fall back to unencrypted plaintext. This allows them to read, modify, or redirect messages in transit. MTA-STS prevents this by requiring sending servers to use verified TLS connections.
TLS Support Alone Is Not Enough
Most mail servers support TLS, but support is not the same as enforcement. Without MTA-STS, a sending server that encounters a TLS error will silently fall back to plaintext rather than refusing delivery. MTA-STS changes that behavior by telling senders to fail rather than downgrade.
You Have No Visibility Into Delivery Failures
Without TLS-RPT alongside MTA-STS, you have no way to know when sending servers fail to establish encrypted connections with your mail servers. TLS failures can cause lost emails or plaintext delivery, and you only find out when someone reports a missing message.
Compliance and Security Frameworks Expect It
Security frameworks and compliance standards increasingly expect encrypted email delivery. MTA-STS demonstrates that your organization actively enforces transport-layer security rather than relying on opportunistic TLS that can be bypassed.
Check Your Full Email Authentication with iO™ DMARC
SPF is one piece of the puzzle. Use these tools to check the rest of your email authentication stack.
SPF Checker
Validate your SPF record and confirm which servers are authorized to send on your behalf. SPF verifies the sender, MTA-STS protects the delivery path.
DKIM Checker
Verify your DKIM signature to make sure outgoing emails are cryptographically signed. DKIM protects message content, MTA-STS protects the connection.
DMARC Checker
Check your DMARC policy and alignment. DMARC enforces authentication at the sender level, while MTA-STS enforces encryption at the transport level.
BIMI Checker
See if your domain qualifies to display your brand logo in supported inboxes. BIMI is the visible reward of a fully authenticated, securely delivered email.
TLS-RPT Checker
Verify your TLS reporting setup. TLS-RPT is the reporting companion to MTA-STS, it tells you when enforced encryption fails so you can act on it.
Email Authentication Audit
Get a complete picture of your SPF, DKIM, DMARC, BIMI, and MTA-STS configuration in one report. See what’s working, what’s broken, and what to fix first.
Learn About MTA-STS
Want to go deeper? These guides explain how MTA-STS works, how to set it up, and how TLS-RPT reporting fits into your email security stack.
What Is MTA-STS and How to Set It Up
A complete guide to MTA-STS: what it does, how to create the DNS record and policy file, how to choose between testing and enforce mode, and how to maintain your configuration.
Check Your TLS-RPT Configuration
TLS-RPT is the companion to MTA-STS. Use our free checker to verify that your TLS reporting is configured and that you are receiving encrypted delivery failure reports.
Managed MTA-STS and TLS-RPT
Don't want to host policy files and parse TLS reports yourself? iO DMARC handles MTA-STS policy hosting, TLS-RPT configuration, and encrypted delivery monitoring for you.
Ready to Enforce Encrypted Email Delivery?
Found issues with your MTA-STS configuration? Or just want someone to handle encrypted delivery and TLS reporting so you don't have to think about it? Let's talk.
Want Encrypted Delivery, Enforced?
iO™ DMARC generates your MTA-STS policy, hosts the policy file for you, and alerts you the moment a connection falls back to unencrypted. One less piece of DNS to babysit.