MTA-STS Policy Generator
Generate both the MTA-STS policy file and DNS TXT record required to enforce TLS encryption on inbound email.
MTA-STS requires three things:
- The policy file hosted at
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt - A DNS TXT record at
_mta-sts.yourdomain.com - A valid TLS certificate on all mail servers listed in the policy
Your root domain (used to show the correct URLs in the instructions).
Add the hostname of each mail server that receives email for your domain. These must match your MX records exactly and have valid TLS certificates. Use *. prefix for wildcard matching (e.g. *.mail.protection.outlook.com).
version: STSv1 mode: testing max_age: 86400
Hosting Instructions
- • Host this file at:
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt - • The file must be served over HTTPS with a valid certificate
- • Content-Type should be
text/plain - • Update the policy ID in the DNS record each time you change this file
What the generator creates
MTA-STS needs two artifacts and the generator produces both. The Policy File tab gives you the text for https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The DNS TXT Record tab gives you the value for _mta-sts.yourdomain.com.
The policy lines are version: STSv1, mode, one mx line per host you enter, then max_age. The TXT value is v=STSv1; id=<timestamp>, where the id is a timestamp captured when the page loads. Reload the page to get a new one.
The generator does not create a TLS-RPT record. Add that yourself, as described below.
Example for a Google Workspace domain in testing mode
version: STSv1 mode: testing mx: aspmx.l.google.com mx: alt1.aspmx.l.google.com mx: alt2.aspmx.l.google.com mx: alt3.aspmx.l.google.com mx: alt4.aspmx.l.google.com max_age: 86400 _mta-sts.yourdomain.com TXT "v=STSv1; id=20261005120000"
Filling in the options
| Option | What to enter | Notes |
|---|---|---|
| Mode | Testing first | testing delivers mail even when TLS validation fails and produces reports. enforce makes senders refuse delivery to a host that fails validation. none withdraws the policy. |
| MX hosts | Exactly the host names in your MX records | Look them up with a DNS or MX lookup first. Remove trailing dots. Wildcards such as *.mail.protection.outlook.com are allowed. |
| Max age | 1 day while testing, 1 week to 30 days in production | Senders cache the policy for this long, so a mistake in enforce mode lingers. The RFC maximum is 31557600 seconds. |
Typical MX hosts: Google Workspace uses aspmx.l.google.com and the alt1 to alt4 hosts under aspmx.l.google.com, though domains set up more recently may point at smtp.google.com instead. Check your own MX records. Microsoft 365 uses a host like yourdomain-com.mail.protection.outlook.com, so *.mail.protection.outlook.com is a common mx line.
Hosting the policy file
The file must be reachable at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, return HTTP 200 directly (no redirects), use a certificate valid for mta-sts.yourdomain.com and ideally be served as text/plain. Create a DNS record for the mta-sts host first, then pick any host that satisfies those rules.
- Cloudflare: if your DNS is on Cloudflare, a small Worker with a custom domain or route on mta-sts.yourdomain.com can return the policy text with a text/plain header. Cloudflare manages the certificate. Cloudflare Pages with a custom domain also works.
- GitHub Pages: put the file at .well-known/mta-sts.txt in the repository, add an empty .nojekyll file so Jekyll does not drop the dot folder, set mta-sts.yourdomain.com as the custom domain and enable Enforce HTTPS once the certificate is issued. Point a CNAME for mta-sts at your username.github.io.
- Any web server or static host: Nginx, Apache, S3 behind a CDN or similar all work if you can attach a valid certificate to the mta-sts host name and serve the path exactly.
- Do not forget certificate renewal on the mta-sts host. If it expires, senders cannot fetch policy updates, and you cannot publish a change until it is fixed.
Publishing in order
- Publish the TLS-RPT record first: _smtp._tls.yourdomain.com TXT with v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com.
- Set up the mta-sts host and upload the policy file in testing mode.
- Open the file URL in a browser and confirm it loads without a certificate warning or redirect.
- Add the _mta-sts TXT record last so senders only discover a working policy.
- Run the MTA-STS checker and confirm the policy is reachable and the MX entries match.
Moving to enforce and updating later
After one to two weeks of clean TLS reports, change the policy file to mode: enforce and raise max_age. Whenever the policy file changes, whether that is mode, MX hosts or max_age, you must also change the id in the TXT record. Senders only refetch the policy when the id differs from the cached one. A date-based id such as 20261005120000 works well, and the id may contain letters and digits up to 32 characters.
If you change mail providers, add the new MX hosts to the policy and update the id before you change MX records, then remove the old hosts after mail has fully moved. Switching MX first while in enforce mode can make senders refuse the new host.
Mistakes to avoid
| Mistake | Effect | Fix |
|---|---|---|
| TXT record at mta-sts.<domain> | Senders never see a policy | The name is _mta-sts.<domain>. |
| mx lines that omit a real MX host | Mail to that host is refused in enforce mode | Mirror every MX record. |
| Policy file behind a redirect | Senders do not follow redirects, so the policy is ignored | Serve it directly. |
| Changing the file without changing the id | Senders keep using the cached version | Change the id every time. |
| Going straight to enforce | Any certificate or STARTTLS fault breaks inbound mail | Run testing mode first. |
Limitations
The generator writes text from your inputs and cannot verify that your MX hosts support STARTTLS with a valid certificate, that the mta-sts host exists or that the file is hosted correctly. The checker covers the discovery and policy part. MTA-STS also depends on the sender: it protects inbound mail only from servers that validate it, and it is not a replacement for good certificate hygiene on your mail servers.
Related tools and guides
Frequently Asked Questions
What is MTA-STS and why do I need it?
MTA-STS (Mail Transfer Agent Strict Transport Security) is a security standard that tells sending mail servers to use TLS encryption when delivering email to your domain and to reject delivery if a secure connection cannot be established. Without MTA-STS, email can be delivered over unencrypted connections or be subject to downgrade attacks. MTA-STS complements DMARC by securing the transport layer, not just authentication.
What does MTA-STS mode testing vs enforce mean?
In testing mode, MTA-STS is evaluated but not enforced — sending servers are informed about the policy but will still deliver mail even if TLS requirements cannot be met. This lets you check for issues without affecting delivery. In enforce mode, sending servers must deliver over a valid TLS connection matching the policy or reject the delivery entirely. Start with testing mode and only switch to enforce after confirming no legitimate mail is affected.
What needs to be set up for MTA-STS to work?
MTA-STS requires three things: (1) A policy file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid TLS certificate. (2) A DNS TXT record at _mta-sts.yourdomain.com containing the policy version ID. (3) Valid TLS certificates on all mail servers listed in the policy. All three must be in place before switching to enforce mode.
What is the MTA-STS policy ID and why does it need to change?
The policy ID (id=) in the DNS TXT record is a version identifier that tells sending mail servers when the policy has changed. Sending servers cache the policy for max_age seconds and use the ID to detect updates. When you update the policy file, you must also update the policy ID in the DNS record — otherwise servers will continue using the cached version. Use a timestamp format like YYYYMMDDHHmmss to ensure uniqueness.
Do I need MTA-STS if I already have DMARC?
DMARC and MTA-STS protect against different threats. DMARC prevents domain spoofing by verifying that email claiming to be from your domain was actually sent by an authorised server. MTA-STS protects the transport channel — ensuring email is encrypted in transit and cannot be intercepted or downgraded to an unencrypted connection. Both should be implemented for comprehensive email security.