MTA-STS Record & Policy Generator

Generate the two components of an MTA-STS (Mail Transfer Agent Strict Transport Security) deployment: the DNS TXT record at _mta-sts.<domain> and the policy file hosted at https://mta-sts.<domain>/.well-known/mta-sts.txt. MTA-STS lets you tell sending mail servers that your inbound MX hosts support TLS and that they should refuse to deliver mail if a valid TLS connection cannot be established, preventing downgrade attacks.

1. DNS TXT Record
2. Policy File — serve at https://mta-sts.<domain>/.well-known/mta-sts.txt

How to use the MTA-STS Record & Policy Generator

Fill in your domain, choose a mode, list your MX hostnames (one per line), and set max-age. Click Generate.

You need to publish two things:

  1. DNS TXT record at _mta-sts.<domain>. The value contains v=STSv1; id=<timestamp>. The id is a version token — change it whenever you update your policy file so senders know to re-fetch it. This generator sets id to the current UTC date/time.
  2. Policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt. This file must be served with Content-Type: text/plain and a valid TLS certificate (not self-signed). It lists the MX hostnames senders should accept TLS certificates for.

Rollout steps:

  1. Start with mode: testing. Configure TLS-RPT (_smtp._tls TXT) at the same time to receive failure reports. Test for 1–2 weeks.
  2. If no unexpected TLS failures appear in TLS-RPT reports, switch to mode: enforce. Update the id= in the DNS record so senders re-fetch.
  3. Set max_age to a longer value (up to 31536000 seconds / 1 year) once you are confident the policy is stable.

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security), defined in RFC 8461, is a mechanism that allows domain owners to declare that their inbound mail servers support TLS and that sending servers should require a valid, trusted TLS connection before delivering mail. Without it, a network attacker who can intercept SMTP traffic can strip the STARTTLS upgrade and receive the mail in plaintext — a well-known attack called STARTTLS downgrade or stripping. MTA-STS prevents this by giving senders a cached policy saying "do not deliver if TLS cannot be verified".

The architecture has two components: a DNS TXT record at _mta-sts.<domain> that signals MTA-STS is in use and contains a policy version ID, and a policy file hosted over HTTPS at a well-known URL. The HTTPS hosting ensures the policy itself is authenticated — an attacker who can manipulate DNS cannot serve a fake policy because they cannot get a certificate for mta-sts.<domain> without controlling the domain. The policy file lists the MX hostnames whose TLS certificates should be validated (using the public CA trust chain, not DANE/TLSA records). Senders cache the policy for up to max_age seconds, which means once a policy is cached, even if DNS is temporarily unavailable or tampered with, senders still enforce TLS.

MTA-STS addresses the same threat as DANE (DNS-Based Authentication of Named Entities) but without requiring DNSSEC, making it easier to deploy on standard infrastructure. The two are complementary rather than competing — you can deploy both. MTA-STS should be paired with TLS-RPT (_smtp._tls TXT record) so you receive reports when a sending server encounters TLS negotiation failures against your MX hosts.

Common use cases

  • Prevent STARTTLS downgrade attacks — ensure that legitimate sending servers cannot be tricked by a network attacker into delivering mail in plaintext to your MX hosts.
  • Google Workspace / Microsoft 365 inbound security — both platforms support MTA-STS for their inbound MX infrastructure and recommend it as part of a defence-in-depth email security posture.
  • Compliance — regulations such as GDPR and sector-specific frameworks expect mail containing personal data to be transmitted securely; MTA-STS provides the mechanism and audit evidence.
  • Pair with TLS-RPT for visibility — deploy MTA-STS in testing mode alongside a TLS-RPT record to get reports of TLS failures before switching to enforce mode.
  • Protect mail for parked domains — publish an MTA-STS policy with mode=none for domains that should not receive mail at all, signalling senders not to deliver to those domains.

Frequently asked questions

What happens if I set mode=enforce but my MX server has an invalid or self-signed certificate?
Sending servers that support MTA-STS will refuse to deliver mail and may queue it until the policy expires or the TLS issue is fixed. Always test with mode=testing and TLS-RPT first to confirm your MX certificates are valid before switching to enforce.

Why does the policy file have to be hosted at mta-sts.<domain>?
The subdomain mta-sts. is specified by RFC 8461. You need to create a subdomain DNS record pointing to a web server that serves the policy file over HTTPS with a valid certificate. For Google Workspace or Microsoft 365, these providers can often host the policy file for you.

What does changing the id= do?
The id= in the DNS TXT record is a version token. When senders see a different id= from what they have cached, they know to re-fetch the policy file from HTTPS. Change the id= every time you update the policy file content (e.g. when adding or removing MX hosts, or changing mode). If you forget to update id=, senders will continue to use the cached old policy.

Can I use wildcard MX hostnames in the policy?
Yes. RFC 8461 allows wildcard patterns like *.example.com in the mx: lines. A certificate for mail.example.com will match the wildcard *.example.com. This is useful for providers that use many MX hostnames sharing a wildcard certificate.

Does MTA-STS work for outbound mail?
MTA-STS policies are published by the receiving domain and enforced by the sending MTA. To benefit from MTA-STS as a sender, your mail transfer agent (Postfix, Exim, Haraka, etc.) must implement the MTA-STS policy fetching and enforcement logic. Most modern hosted email services (Gmail, Outlook) do this automatically.