BYTETOOLS

MTA-STS Policy Generator

Generate both halves of RFC 8461 MTA-STS: the mta-sts.txt policy file with mode, mx and max_age, plus the _mta-sts TXT record with a fresh id.

testing
Mode
0
MX hosts
604800s
max_age
7 days
Lifetime

1. Policy file

Fix the fields above and the policy file appears here.

2. DNS TXT record

The TXT record appears here once the domain and id are valid.

Deployment checklist

  1. Create the mta-sts.example.com host with a valid HTTPS certificate.
  2. Publish the policy file at /.well-known/mta-sts.txt as text/plain. Do not redirect it.
  3. Add the _mta-sts.example.com TXT record.
  4. Every MX host you listed must present a certificate that is publicly trusted and valid for its own name, or enforcing senders will bounce your mail.
  5. Add a TLS-RPT record (_smtp._tls TXT with v=TLSRPTv1; rua=mailto:…) so you find out about failures before you switch to enforce.

Everything is generated in your browser — no DNS lookup is made and nothing you type is uploaded.

What is the MTA-STS Policy Generator?

MTA-STS tells other mail servers that your domain always accepts mail over authenticated TLS, closing the downgrade hole that plain opportunistic STARTTLS leaves open.

  • Writes the full policy file — version, mode, one mx line per host and max_age
  • Generates the matching _mta-sts TXT record with a UTC-stamped id
  • Validates hostnames, wildcard placement and the RFC 8461 max_age ceiling
  • Warns about enforce mode, short lifetimes and wildcard matching limits
  • Downloads the policy with CRLF line endings as the specification requires
  • Deployment checklist covering the HTTPS host, certificates and TLS reporting

How to use the MTA-STS Policy Generator

  1. 1

    Enter your mail domain and choose a mode — start with testing, not enforce.

  2. 2

    List every MX hostname the policy covers, one per line, exactly as they appear in your MX records.

  3. 3

    Pick a max_age (one week is the usual floor) and press the refresh button to stamp a fresh policy id.

  4. 4

    Copy or download the policy file and publish it at https://mta-sts.yourdomain/.well-known/mta-sts.txt as text/plain.

  5. 5

    Add the _mta-sts TXT record, then work through the deployment checklist before switching to enforce.

About the MTA-STS Policy Generator

MTA-STS tells other mail servers that your domain always accepts mail over authenticated TLS, closing the downgrade hole that plain opportunistic STARTTLS leaves open. It has two halves, and this tool writes both: the policy file served over HTTPS at mta-sts.yourdomain, and the small DNS TXT record at _mta-sts.yourdomain that senders poll to notice changes.

Pick enforce, testing or none, list every MX host the policy should cover — a single leading wildcard label is allowed — and choose a max_age. The tool stamps the policy id from the current UTC time, checks your values against the limits in RFC 8461, and warns you before you switch a live domain straight into enforce mode.

The policy file is generated with the CRLF line endings the specification calls for, and a deployment checklist walks through the HTTPS host, the certificate requirements on every MX and the TLS reporting record you want in place first. The whole thing runs in your browser: no DNS query is made, no host is contacted, and nothing you type is uploaded or logged anywhere.

Frequently asked questions

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

MTA-STS is a policy that tells sending mail servers your domain always supports TLS and which MX hosts are legitimate. Without it, an attacker who can intercept traffic can strip STARTTLS and read mail in the clear, because plain SMTP falls back silently.

What is the difference between testing and enforce mode?

In testing mode a sender that cannot validate your TLS still delivers the message and simply reports the failure. In enforce mode it refuses to deliver. Always run testing for a few weeks with TLS reporting enabled before you switch, or a certificate slip will bounce real mail.

Where exactly does the MTA-STS policy file go?

At https://mta-sts.yourdomain/.well-known/mta-sts.txt, served as text/plain with a publicly trusted certificate valid for mta-sts.yourdomain. It must be reachable without authentication and should not be behind a redirect.

Why does the id have to change when I edit the policy?

Senders check the cheap TXT record on every delivery but only refetch the policy file over HTTPS when the id differs from the one they cached. If you edit the file without bumping the id, senders keep using the old policy until max_age runs out.

What max_age should I choose?

RFC 8461 recommends at least a week (604800 seconds) and caps it at 31557600. A long max_age protects you better, but it also means senders keep enforcing an old policy for that long if your policy host disappears — so start short during rollout and lengthen it once you are confident.

Do I still need DANE if I have MTA-STS?

They solve the same problem differently. DANE requires DNSSEC and pins the certificate in DNS; MTA-STS relies on the public web PKI and needs no DNSSEC. Large providers often publish both, and there is no harm in doing so.

Related tools