Why two parts instead of one record?

Because the policy holds more information than sensibly fits into a DNS record, and because its authenticity is secured by the web server's certificate rather than by DNSSEC. The TXT record is only the signpost: it says that a policy exists and which version currently applies. The policy itself is fetched over HTTPS.

Do I have to run a web server for this?

You need a name under mta-sts.your-domain that is reachable over HTTPS and has a valid certificate for exactly that name. That can be an existing web server with an extra configuration, a static host or a service from your provider. What gets served is a single text file.

Where do I start, testing or enforce?

With testing. In that mode a sending server reports deviations but delivers normally, so you see whether your list of mail servers is complete without risking mail. It becomes useful together with TLS-RPT, because that is how the reports reach you in the first place. After that you switch to enforce.

What belongs on the list of mail servers?

Every host that accepts mail for your domain, which as a rule means exactly the names from your MX records. If your provider runs many machines under a shared naming scheme, a pattern such as *.example.net is the right way; it covers one level, not arbitrarily many.

What happens when I change the policy later?

Then the id in the TXT record has to change, otherwise sending servers do not fetch the file again but keep working with the old version until max_age expires. This generator computes the id from the contents of the policy: regenerate it with the changed values and you automatically get a new id, then enter both parts together.

How do I withdraw MTA-STS again?

Not by deleting. Set the mode to none and publish that policy with a new id. Sending servers that still hold the old version cached then learn explicitly that the rule no longer applies. Only once the old max_age has expired can the files go.

Does the generator change anything in my DNS or on my web server?

No. It produces two texts that you enter and serve yourself. It also queries nothing, it computes purely from what you enter.

MTA-STS Generator

Create the TXT record and the policy file for MTA-STS, both together.

MTA-STS makes other mail servers deliver messages to your domain only over an encrypted, verified connection. Without it, SMTP encryption is a mere courtesy: an attacker on the wire can simply negotiate it away, and the sending server notices nothing. A published policy takes exactly that option away.

What the generator does

It produces both parts an MTA-STS setup consists of, and that is the essential difference from an SPF or DMARC entry:

a TXT record on _mta-sts. in front of your domain. It holds only the version and an id and tells sending servers that a policy exists.
a policy file that has to be reachable at https://mta-sts.your-domain/.well-known/mta-sts.txt. It states which mail servers are responsible for your domain, how strictly the rule applies and how long sending servers should remember it.

The record alone does nothing, and the file alone is never found. That is why both parts sit here side by side, each with the full location it belongs to.

Reading the result

The mode decides the effect. Testing reports deviations but changes nothing about delivery: nothing is lost, but the domain is not protected yet. Enforce is the actual protection, because a sending server aborts delivery when the connection does not match the policy. That is precisely why testing belongs at the start: you first find out whether your list of mail servers is complete, before a gap in it turns into rejected mail.

The id in the TXT record is computed from the contents of the policy. It therefore changes exactly when the policy changes and stays the same otherwise. That matters more than it looks: sending servers notice solely by this id that they have to fetch the file again. Change the file and leave the record alone and you work for weeks against a policy nobody retrieves any more.

Background: what the RFC requires

RFC 8461 is authoritative. It requires the policy to be served over HTTPS from the mta-sts. subdomain, with a valid certificate for exactly that name, and to contain at least one mx field. The wildcard * is allowed, but only at the very front and only for one level: *.example.net covers mx1.example.net, not mx1.mail.example.net.

max_age determines how long sending servers cache the policy. RFC 8461 recommends at least one week. A short value sounds cautious but weakens the protection: the more often a server has to ask again, the larger the window in which it delivers without a valid policy.

MTA-STS and DANE pursue the same goal by different routes. DANE anchors the promise in DNS and requires DNSSEC there; MTA-STS works without DNSSEC and relies on the web server's certificate instead. Having both side by side is possible and common.

Common failure patterns

The policy file is missing or in the wrong place. The TXT record is there, the rest is not: for sending servers that is not half a protection but none.
The certificate does not cover mta-sts. A certificate for the main domain alone is not enough; the name has to be included.
The file was changed, the id was not. The old policy then stays in circulation until it expires.
A forgotten mail server. In enforce mode sending servers refuse delivery to any host that is not on the list.
Enforcing too early. The same pattern as with DMARC: the strict level without prior observation costs mail.

Once both are in place, check them with the MTA-STS and TLS-RPT Check: it reads the record, actually fetches the policy, inspects the certificate and compares the list of mail servers with the domain's real MX records.

Common questions

Why two parts instead of one record?: Because the policy holds more information than sensibly fits into a DNS record, and because its authenticity is secured by the web server's certificate rather than by DNSSEC. The TXT record is only the signpost: it says that a policy exists and which version currently applies. The policy itself is fetched over HTTPS.
Do I have to run a web server for this?: You need a name under mta-sts.your-domain that is reachable over HTTPS and has a valid certificate for exactly that name. That can be an existing web server with an extra configuration, a static host or a service from your provider. What gets served is a single text file.
Where do I start, testing or enforce?: With testing. In that mode a sending server reports deviations but delivers normally, so you see whether your list of mail servers is complete without risking mail. It becomes useful together with TLS-RPT, because that is how the reports reach you in the first place. After that you switch to enforce.
What belongs on the list of mail servers?: Every host that accepts mail for your domain, which as a rule means exactly the names from your MX records. If your provider runs many machines under a shared naming scheme, a pattern such as *.example.net is the right way; it covers one level, not arbitrarily many.
What happens when I change the policy later?: Then the id in the TXT record has to change, otherwise sending servers do not fetch the file again but keep working with the old version until max_age expires. This generator computes the id from the contents of the policy: regenerate it with the changed values and you automatically get a new id, then enter both parts together.
How do I withdraw MTA-STS again?: Not by deleting. Set the mode to none and publish that policy with a new id. Sending servers that still hold the old version cached then learn explicitly that the rule no longer applies. Only once the old max_age has expired can the files go.
Does the generator change anything in my DNS or on my web server?: No. It produces two texts that you enter and serve yourself. It also queries nothing, it computes purely from what you enter.