MTA-STS Policy Generator

Generate an MTA-STS policy file and DNS TXT record for your domain. Enforce TLS encryption on inbound email delivery to prevent downgrade attacks.

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard defined in RFC 8461. It allows domain owners to declare that their mail servers support TLS and that sending servers should only deliver mail over encrypted connections. Without MTA-STS, even if your mail server supports TLS, a man-in-the-middle attacker can force a downgrade to plaintext delivery.

MTA-STS works by publishing a policy file at a well-known HTTPS URL on the mta-sts subdomain of your domain. Sending servers discover the policy through a DNS TXT record at _mta-sts.yourdomain.com and then fetch the full policy over HTTPS. The policy specifies which MX hosts are authorized, what mode to operate in, and how long to cache the policy.

How the Policy File Works

The MTA-STS policy file is a plain text file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It contains four directives:

version: Always STSv1. Identifies the policy format version.
mode: One of enforce, testing, or none. Controls how strictly the policy is applied.
mx:One or more authorized MX hostnames. Sending servers verify that the receiving server's certificate matches one of these entries. Wildcard prefixes are supported.
max_age: Cache duration in seconds. Sending servers remember and enforce the policy for this long, even if the DNS record is later removed or tampered with.

How to Use This Generator

Choose a policy mode — start with testing to monitor without enforcing, then switch to enforce once verified.
Enter your MX hosts— list the hostnames from your domain's MX DNS records, one per line.
Set the max age— use a shorter value during initial deployment, then increase once stable.
Generate the policy— the tool produces both the policy file content and the DNS TXT record.
Deploy the policy file— host the policy content at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS.
Publish the DNS record— add the TXT record at _mta-sts.yourdomain.com.

Frequently Asked Questions

What is MTA-STS?: MTA-STS (Mail Transfer Agent Strict Transport Security) is a mechanism defined in RFC 8461 that allows a domain to declare that it supports TLS for inbound email and that sending servers should refuse to deliver mail over an unencrypted connection. It prevents TLS downgrade attacks and DNS spoofing of MX records by requiring sending servers to validate the receiving server's certificate against the published policy.
What is the difference between testing and enforce mode?: In testing mode, sending servers will attempt TLS delivery and report failures via TLS-RPT, but they will still deliver mail even if the TLS connection cannot be established. In enforce mode, sending servers will refuse to deliver mail if a secure TLS connection to an authorized MX host cannot be established. Always start with testing mode to identify potential issues before switching to enforce.
How does MTA-STS relate to TLS-RPT?: TLS-RPT (TLS Reporting) is a companion standard defined in RFC 8460 that allows sending servers to report TLS connection failures back to the domain owner. While MTA-STS defines the policy, TLS-RPT provides the feedback loop. Publishing a TLS-RPT record alongside your MTA-STS policy is strongly recommended so you can monitor delivery issues, especially during the testing phase.
What should I set the max_age to?: The max_age value determines how long sending servers cache your MTA-STS policy, in seconds. During initial deployment, use a shorter value like 86400 (1 day) so you can quickly make changes if something goes wrong. Once you are confident the policy is correct, increase it to 604800 (1 week) or higher. A longer max_age provides better security because it reduces the window for a downgrade attack, but makes it harder to roll back changes quickly.
Do I need HTTPS to deploy MTA-STS?: Yes. The MTA-STS policy file must be served over HTTPS from the subdomain mta-sts.yourdomain.com with a valid, publicly trusted TLS certificate. This is a core requirement of the specification because the entire point of MTA-STS is to ensure transport security. The certificate must match the mta-sts subdomain and must not be expired or self-signed.

Need Continuous MTA-STS Monitoring?

Generating a policy is the first step. Inbox Insignia continuously monitors your MTA-STS policy, TLS-RPT reports, and related DNS records. Get alerted instantly when your policy expires, your certificate changes, or delivery failures spike.

Start Free Trial View Pricing

What is MTA-STS?

How the Policy File Works

The MTA-STS policy file is a plain text file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It contains four directives:

version: Always STSv1. Identifies the policy format version.

mode: One of enforce, testing, or none. Controls how strictly the policy is applied.

mx:One or more authorized MX hostnames. Sending servers verify that the receiving server's certificate matches one of these entries. Wildcard prefixes are supported.

max_age: Cache duration in seconds. Sending servers remember and enforce the policy for this long, even if the DNS record is later removed or tampered with.

How to Use This Generator

Choose a policy mode — start with testing to monitor without enforcing, then switch to enforce once verified.

Enter your MX hosts— list the hostnames from your domain's MX DNS records, one per line.

Set the max age— use a shorter value during initial deployment, then increase once stable.

Generate the policy— the tool produces both the policy file content and the DNS TXT record.

Deploy the policy file— host the policy content at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS.

Publish the DNS record— add the TXT record at _mta-sts.yourdomain.com.

Frequently Asked Questions

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) is a mechanism defined in RFC 8461 that allows a domain to declare that it supports TLS for inbound email and that sending servers should refuse to deliver mail over an unencrypted connection. It prevents TLS downgrade attacks and DNS spoofing of MX records by requiring sending servers to validate the receiving server's certificate against the published policy.

What is the difference between testing and enforce mode?

In testing mode, sending servers will attempt TLS delivery and report failures via TLS-RPT, but they will still deliver mail even if the TLS connection cannot be established. In enforce mode, sending servers will refuse to deliver mail if a secure TLS connection to an authorized MX host cannot be established. Always start with testing mode to identify potential issues before switching to enforce.

How does MTA-STS relate to TLS-RPT?

TLS-RPT (TLS Reporting) is a companion standard defined in RFC 8460 that allows sending servers to report TLS connection failures back to the domain owner. While MTA-STS defines the policy, TLS-RPT provides the feedback loop. Publishing a TLS-RPT record alongside your MTA-STS policy is strongly recommended so you can monitor delivery issues, especially during the testing phase.

What should I set the max_age to?

The max_age value determines how long sending servers cache your MTA-STS policy, in seconds. During initial deployment, use a shorter value like 86400 (1 day) so you can quickly make changes if something goes wrong. Once you are confident the policy is correct, increase it to 604800 (1 week) or higher. A longer max_age provides better security because it reduces the window for a downgrade attack, but makes it harder to roll back changes quickly.

Do I need HTTPS to deploy MTA-STS?

Yes. The MTA-STS policy file must be served over HTTPS from the subdomain mta-sts.yourdomain.com with a valid, publicly trusted TLS certificate. This is a core requirement of the specification because the entire point of MTA-STS is to ensure transport security. The certificate must match the mta-sts subdomain and must not be expired or self-signed.