MTA-STS Checker
Enter your email domain to check its MTA-STS DNS record, fetch and validate the policy file, confirm your mail servers are covered, and see whether TLS reporting is enabled.
Overview
Mail servers usually encrypt email in transit with STARTTLS, but only opportunistically: an attacker on the network can strip the encryption and senders will quietly deliver in plain text. MTA-STS (RFC 8461) closes that gap. It tells sending servers that your domain always supports TLS with a valid certificate, so they refuse to deliver without it.
MTA-STS needs three pieces to line up: a TXT record at _mta-sts.yourdomain with a policy id, a policy file served over HTTPS at mta-sts.yourdomain/.well-known/mta-sts.txt, and mx lines in that policy that match every MX record. This checker verifies all three, including rules that are easy to miss, such as the policy URL not being allowed to redirect.
It also checks TLS-RPT (RFC 8460), the _smtp._tls record that tells other servers where to send reports about failed TLS connections. Reports are how you find problems while running in testing mode before switching to enforce.
Examples & Sample Data
Enforced policy
gmail.com
Pass: mode enforce, all 5 MX hosts covered by *.gmail-smtp-in.l.google.com, TLS-RPT reports to [email protected]
Not set up
example.com
Warning: No MTA-STS record. Warning: No TLS-RPT record.
How It Works
- Enter the domain that receives your email.
- The checker reads the _mta-sts TXT record and validates its id.
- It downloads the policy file over HTTPS without following redirects, then checks version, mode, max_age, and mx lines.
- It compares your MX records with the policy’s mx patterns and reads your TLS-RPT record.
Common Use Cases
Rolling out MTA-STS
Validate each step, from the DNS record to the policy file, before moving from testing to enforce.
Changing email providers
Make sure the policy’s mx lines match your new MX records so enforcing senders don’t reject your mail.
Email security audits
Check transport security alongside SPF, DKIM, and DMARC.
Tips & Best Practices
- Start in mode: testing with TLS-RPT enabled, review the reports for a couple of weeks, then switch to enforce.
- Change the id in the TXT record every time you edit the policy file, or senders keep using their cached copy.
- Use a max_age of at least a week (604800) once the policy is stable. Very short values leave gaps between fetches.
Frequently Asked Questions
In testing mode, senders report TLS failures through TLS-RPT but still deliver the email. In enforce mode, they refuse to deliver to servers that don’t offer valid TLS matching the policy.
RFC 8461 forbids senders from following redirects when fetching the policy, so a redirect makes the policy unusable. Serve the file directly from mta-sts.yourdomain with a valid certificate for that host.
One of your MX records doesn’t match any mx line in the policy. Senders enforcing MTA-STS won’t deliver to that server. Add a matching line, such as mx: *.mail.protection.outlook.com.
No, but it’s strongly recommended. Without it you won’t hear about delivery failures caused by certificate or TLS problems.
Related Tools
Explore more high-performance utilities.