MTA-STS & TLS-RPT Checker
Enter a domain to check its MTA-STS policy, TLS reporting setup, and verify that MX records match the declared patterns.
Enter the domain from your email's From address (e.g., yourcompany.com)
Checking MTA-STS setup...
Resolving DNS records
Your MTA-STS report is ready
Enter your email to see the full results. We'll send you a copy, that's it, no marketing emails.
All checks are done in your browser. No spam, no mailing list, just your report.
MTA-STS is fully configured for this domain.
MTA-STS DNS Record
TLS-RPT DNS Record
What is MTA-STS?
MTA-STS (Mail Transfer Agent Strict Transport Security) is a security standard defined in RFC 8461 that enables domain owners to declare that their mail servers support TLS encryption and that sending servers should refuse to deliver email over an unencrypted connection. It is designed to prevent TLS downgrade attacks and man-in-the-middle interception of email in transit between mail servers.
Without MTA-STS, email transport between servers relies on opportunistic TLS. This means a sending server will attempt to negotiate an encrypted connection, but if TLS negotiation fails or is actively interfered with by an attacker, the sending server will silently fall back to delivering the message in plain text. An attacker positioned on the network path between two mail servers can exploit this by stripping or interfering with the TLS handshake, forcing a downgrade to unencrypted delivery and allowing them to read or modify the message contents.
MTA-STS solves this by providing a mechanism for the receiving domain to publish a policy that says: "My mail servers support TLS, here are the server names to expect, and if you cannot establish a valid encrypted connection then you should not deliver the message at all." The sending server fetches this policy over HTTPS and caches it for the specified duration, providing a trusted channel that is separate from the DNS and SMTP protocols that are vulnerable to interception.
What is TLS-RPT?
TLS-RPT (TLS Reporting, defined in RFC 8460) is a companion standard to MTA-STS that provides a reporting mechanism for TLS negotiation failures. When a sending mail server encounters problems establishing an encrypted connection to your domain, TLS-RPT tells it where to send a report about the failure so you can diagnose and fix the issue.
Without TLS-RPT, you have no visibility into whether sending servers are successfully connecting to your mail servers over TLS. Failed connections happen silently, and you would never know if legitimate email is being bounced because of a misconfigured certificate, an expired policy, or an active downgrade attack. TLS-RPT closes this visibility gap by providing daily reports (in JSON format) that detail the sending domain, the type of failure encountered, and the count of affected sessions.
TLS-RPT reports can be delivered via email (using a mailto: URI) or via HTTPS (using an https: URI). Most organizations start with email-based reporting because it requires no additional infrastructure. The reports are typically small JSON files that can be parsed and monitored for anomalies, such as a sudden spike in TLS failures that might indicate an attack or a certificate problem.
How to Set Up MTA-STS
Setting up MTA-STS requires three components: a DNS TXT record to signal that MTA-STS is active, a web server to host the policy file over HTTPS, and the policy file itself. Here is the step-by-step process:
1. Create the MTA-STS DNS TXT record
Add a TXT record at _mta-sts.yourdomain.com with the value v=STSv1; id=YYYYMMDDHHMMSS. The id field is a unique identifier that must change every time you update your policy file. Using a timestamp format like 20260210120000 is a common convention. Sending servers check this record first, and if the id has not changed since their last fetch, they use the cached policy without re-downloading the file.
2. Set up the web host
Create a DNS record for mta-sts.yourdomain.com pointing to a web server. This can be a CNAME to a hosting service or an A record to your own server. The web server must serve content over HTTPS with a valid, trusted TLS certificate. Self-signed certificates will not work because sending servers will reject them.
3. Host the policy file
Create a plain text file at the URL https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The file should contain your policy in this format:
version: STSv1mode: testingmx: mail.yourdomain.commx: *.yourdomain.commax_age: 86400
The mx: lines must match your actual MX records. You can use wildcards (e.g., *.google.com) to match multiple servers.
4. Start in testing mode, then enforce
Set the mode to testing first. In testing mode, sending servers will report failures via TLS-RPT but will still attempt delivery even if TLS negotiation fails. Monitor your TLS-RPT reports for a few weeks to verify there are no issues. Once you are confident everything works, change the mode to enforce and update the id in your DNS record to trigger a policy refresh.
How to Set Up TLS-RPT
Setting up TLS-RPT is straightforward and requires only a single DNS TXT record. Add a TXT record at _smtp._tls.yourdomain.com with the value:
v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com
Replace tls-reports@yourdomain.com with the email address where you want to receive reports. You can specify multiple reporting URIs separated by commas, and you can mix email and HTTPS endpoints:
v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com,https://reports.yourdomain.com/tls
Once the DNS record is published, sending mail servers that support TLS-RPT will begin sending daily reports about TLS negotiation outcomes when connecting to your mail servers. These reports help you identify certificate issues, DNS misconfigurations, or potential downgrade attacks targeting your domain.
MTA-STS Policy Modes Explained
The MTA-STS policy file includes a mode field that controls how sending servers should behave when TLS negotiation fails. There are three possible modes:
| Mode | Behavior | When to Use |
|---|---|---|
enforce | Sending servers must refuse to deliver email if they cannot establish a valid TLS connection to one of the declared MX hosts. Messages will bounce rather than be delivered insecurely. | Use after you have validated your setup in testing mode and confirmed there are no TLS negotiation failures in your TLS-RPT reports. This is the target state for full protection. |
testing | Sending servers will attempt TLS and report any failures via TLS-RPT, but will still deliver the message even if TLS negotiation fails. This provides visibility without risking mail delivery. | Use when first deploying MTA-STS. Monitor TLS-RPT reports for 2 to 4 weeks to identify any issues before switching to enforce mode. |
none | The policy is effectively disabled. Sending servers should behave as if no MTA-STS policy exists. This mode is used to gracefully wind down an MTA-STS deployment. | Use only when you want to decommission MTA-STS. Set mode to none, wait for cached policies to expire (based on max_age), then remove the DNS record and policy file. |
Frequently Asked Questions
Do I need MTA-STS if I already have DMARC?
Yes, DMARC and MTA-STS protect against different threats. DMARC prevents email spoofing by verifying that the sender domain matches the authenticated domain via SPF and DKIM. MTA-STS protects email in transit by ensuring encrypted delivery between mail servers. Without MTA-STS, an attacker on the network path between two servers can intercept and read email even if DMARC is fully configured. They complement each other: DMARC secures the identity layer and MTA-STS secures the transport layer.
What happens to email if MTA-STS is set to enforce and TLS fails?
When the policy mode is set to enforce and the sending server cannot establish a valid TLS connection to any of the MX servers listed in the policy, the sending server will not deliver the message. The email will typically bounce back to the sender with a delivery failure notification. This is the intended behavior: it is better for a message to bounce than to be delivered over an unencrypted channel where it can be intercepted. This is why it is important to start with testing mode and verify your setup using TLS-RPT reports before switching to enforce.
How often should I update the MTA-STS policy ID?
You should update the policy ID (the id value in the _mta-sts DNS TXT record) every time you change the contents of the policy file. The ID signals to sending servers that the policy has changed and they should re-fetch it. If you do not update the ID, sending servers will continue using their cached version of the old policy until it expires (based on max_age). A common convention is to use a timestamp like 20260210120000 as the ID value.
What is a good max_age value for an MTA-STS policy?
The max_age value specifies how long (in seconds) sending servers should cache your policy before re-fetching it. A common starting value is 86400 (1 day) during initial testing, which allows you to make changes quickly. Once your setup is stable and in enforce mode, increasing max_age to 604800 (1 week) or even 2592000 (30 days) reduces the window of vulnerability if your policy file becomes temporarily unavailable. Longer cache durations mean better protection but less flexibility to make quick changes.
Does MTA-STS work with Google Workspace and Microsoft 365?
Yes, both Google Workspace and Microsoft 365 support sending and receiving email with MTA-STS policies. Google publishes its own MTA-STS policy for gmail.com and google.com, and Gmail checks MTA-STS policies when sending email to other domains. Microsoft 365 also supports MTA-STS validation on outbound email. When setting up MTA-STS for a domain hosted on either service, make sure the mx: patterns in your policy file match the MX records provided by your email hosting provider (e.g., *.google.com or *.outlook.com).