dotvitals

MTA-STS Generator

Generate the MTA-STS DNS record and the HTTPS-hosted policy file it depends on, together.

MTA-STS protects mail coming in: a sending server looks the policy up under the domain it is delivering to. That is the domain with the MX records, which is not always the one you send from.

About the mta-sts generator

MTA-STS requires two things to line up: a DNS TXT record announcing that a policy exists, and a policy file hosted over HTTPS at a fixed URL under a mta-sts subdomain, listing your mail server hostnames and the enforcement mode. This generator produces both together, so they stay consistent rather than being written separately and drifting apart. You provide the mail server hostnames the policy should cover, which normally match your MX records, and the generator builds the policy file in the exact format RFC 8461 requires, along with the matching DNS record carrying a version identifier that changes whenever the policy content changes.

It defaults new policies to mode: testing, which reports failures via TLS-RPT without blocking any delivery, since publishing enforce immediately, before confirming the policy hostnames and certificates are all correct, risks rejecting legitimate mail if something in the policy does not match reality yet. Because the policy file must be served over HTTPS from a valid, trusted certificate on the mta-sts subdomain itself, the generator reminds you that hosting the file is a separate step from publishing the DNS record, and both need to be live before senders will honor the policy at all.

Testing the published policy with an MTA-STS checker confirms both the DNS record and the hosted policy file are reachable and consistent before relying on them, since a typo in either one leaves the policy silently unenforced rather than producing an obvious error. Running that confirmation immediately after publishing, rather than assuming both pieces deployed correctly, is the difference between catching a silent misconfiguration right away and only discovering it once TLS-RPT reports start showing unexplained failures weeks later.

Common questions

What two things does MTA-STS need?
A DNS TXT record at _mta-sts.yourdomain.com announcing the policy, and a policy file hosted over HTTPS at a fixed mta-sts subdomain URL listing the mail server hostnames and mode.
Why does it default to mode: testing?
So failures are reported through TLS-RPT without blocking any delivery, letting you confirm the policy is accurate before switching to enforce, which does reject connections that cannot be secured.
Where do I host the policy file?
At https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, served with a valid TLS certificate for that hostname, which is a separate step from publishing the DNS record.
What happens if I change my mail servers later?
Update the policy file's hostname list and increment the version id in the DNS record; senders re-fetch the policy when they see a new version id, not on every single delivery.