Back to Tools

MTA-STS Policy Generator

Generate an MTA-STS policy file and DNS records to enforce TLS encryption for inbound email. Includes the policy file, MTA-STS TXT record, and TLS-RPT reporting record.

About this tool

MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending mail servers that your domain requires encrypted TLS connections for email delivery. Without MTA-STS, an attacker could intercept the connection between mail servers and downgrade it from encrypted to plaintext, exposing email content. MTA-STS prevents this by publishing a policy that senders must verify before delivering email to your domain.

This generator creates the three components you need to deploy MTA-STS: the policy file that gets hosted on your web server, the DNS TXT record that advertises the policy, and the TLS-RPT record that lets senders report delivery failures to you.

How MTA-STS works

When a sending server wants to deliver email to your domain, it first checks for an MTA-STS DNS record at _mta-sts.yourdomain.com. If found, it fetches the policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The policy specifies which MX hosts are authorized and whether to enforce TLS. In "testing" mode, the sender delivers the email regardless but reports failures. In "enforce" mode, the sender refuses to deliver if a secure connection cannot be established.

Implementation steps

Start with "testing" mode to identify any TLS issues without blocking legitimate email. Set up the TLS-RPT record so you receive reports about connection failures. Monitor the reports for 2-4 weeks. If no issues appear, switch to "enforce" mode. You will need an SSL certificate for the mta-sts subdomain, which most certificate providers (including Let's Encrypt) support.

Part of a complete email security setup

MTA-STS protects inbound email encryption. Pair it with SPF, DKIM, and DMARC to protect against spoofing and phishing. Together these protocols form a comprehensive email security framework. Use our SPF checker, DKIM checker, and DMARC checker to verify your existing authentication setup before adding MTA-STS.

After deploying MTA-STS, check your overall email security posture with the domain reputation checker. A complete setup with SPF, DKIM, DMARC, and MTA-STS gives you the highest possible security rating.

Frequently Asked Questions

What is MTA-STS and why do I need it?

MTA-STS (RFC 8461) is a security standard that enables mail domains to declare their ability to receive TLS-secured connections. Without it, SMTP connections between mail servers can be downgraded to plaintext by a man-in-the-middle attacker, even when both servers support TLS. MTA-STS ensures that senders know your domain requires encryption and will only deliver over verified TLS connections.

Should I start with testing or enforce mode?

Always start with testing mode. In testing mode, sending servers will still deliver email even if TLS fails, but they will send you reports about failures. Monitor these reports for 2-4 weeks to identify any servers that cannot connect securely. Once you confirm there are no legitimate delivery issues, switch to enforce mode.

What MX hosts should I list in the policy?

List only the MX hosts that handle email for your domain. For Google Workspace, use *.google.com and *.googlemail.com. For Microsoft 365, use *.outlook.com. For custom mail servers, list their exact hostnames. You can use wildcards (*.example.com) to match all subdomains of a host. The MX hosts in your policy must match your DNS MX records.

What is TLS-RPT and do I need it?

TLS-RPT (RFC 8460) is a reporting mechanism that lets sending mail servers tell you about TLS connection failures when delivering to your domain. It is strongly recommended alongside MTA-STS because it gives you visibility into delivery issues. Without TLS-RPT, you would not know if senders are having trouble establishing secure connections to your mail servers.

What max_age value should I use?

For testing, use 604800 (7 days) so policy changes take effect quickly. For production enforce mode, use a longer value like 2592000 (30 days) or even 31557600 (1 year). Longer values reduce DNS lookups but mean changes take longer to propagate. The minimum recommended value is 86400 (1 day). Very short values reduce the security benefit.

Do I need an SSL certificate for the mta-sts subdomain?

Yes. The policy file must be served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid SSL certificate. The certificate must be trusted by sending servers, so use a certificate from a recognized CA like Let's Encrypt, DigiCert, or your hosting provider's included certificate. Self-signed certificates will not work.

How do I update my MTA-STS policy?

When you change the policy file content, you must also update the id value in your MTA-STS DNS TXT record. Sending servers cache the policy based on the id, so changing the id signals that they should fetch the updated policy. Use a timestamp or incrementing number as the id value.

Is MTA-STS supported by major email providers?

Google (Gmail) and Microsoft (Outlook/Office 365) both support MTA-STS as senders, meaning they will respect your MTA-STS policy when delivering email to your domain. Yahoo and other providers are adding support. Even if not all senders support MTA-STS yet, deploying it protects email from senders that do, and adoption continues to grow.

Compare email marketing software

Hands-on roundups to help you pick the right platform.