# MTA-STS & TLS-RPT Record Generator

URL: https://iblockspam.com/tools/mta-sts-generator
Last updated: 2026-10-23

> Enter your domain and MX hosts to get the three things MTA-STS needs: the _mta-sts DNS record, the policy file to host over HTTPS, and a TLS-RPT record so you get reports.

Free tool: Build the _mta-sts and _smtp._tls records and the MTA-STS policy file, with safe max_age defaults from RFC 8461. Use it at https://iblockspam.com/tools/mta-sts-generator

## What the generator builds

MTA-STS ([RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html)) lets your domain tell sending mail servers to use encrypted, authenticated connections when they deliver to you, instead of falling back to plain text when an attacker interferes. It needs three pieces, and this generator writes all of them:

1. **The `_mta-sts` TXT record**, such as `v=STSv1; id=20261023120000`. It tells senders a policy exists and which version it is.
2. **The policy file**, served at `https://mta-sts.<your domain>/.well-known/mta-sts.txt`. It lists the mode, your MX hosts and how long senders may cache it.
3. **The `_smtp._tls` TXT record** for TLS reporting ([RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html)), such as `v=TLSRPTv1; rua=mailto:tls-reports@yourcompany.com`. Senders that support it email or post you a daily report of connections that succeeded and failed.

The generator makes no DNS lookups and publishes nothing; you copy the results to your DNS host and web server. When they're live, the [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker) fetches your policy and compares it with your real MX records.

## The policy file, line by line

| Line | Allowed values | Our default | Notes |
|---|---|---|---|
| `version` | `STSv1` | `STSv1` | The only version defined |
| `mode` | `testing`, `enforce`, `none` | `testing` | Testing asks for reports but doesn't block delivery |
| `mx` | A host name or a `*.` wildcard, one per line | What you enter | Required at least once unless the mode is `none` |
| `max_age` | 0 to 31557600 seconds | 604800 (1 week) | RFC 8461 expects "weeks or greater" |

The generator writes one `mx:` line per host, as RFC 8461 requires, converts international names to their punycode form, and skips MX preference numbers if you paste lines like `10 mail.example.com`. Google's [MTA-STS policy help](https://support.google.com/a/answer/9276511) recommends a max_age between 604800 and 1209600 seconds (one to two weeks) for testing mode.

**Which mx values?** Every host in your MX records must match one of the lines, or senders in enforce mode won't deliver to it. If your MX points directly to Exchange Online, Microsoft says you can use `mx: *.mail.protection.outlook.com`, the same value Microsoft uses itself ([Microsoft Learn: MTA-STS](https://learn.microsoft.com/en-us/purview/enhancing-mail-flow-with-mta-sts)). If a filtering service receives your mail first, list that service's MX hosts. Our [MTA-STS and TLS-RPT guide](https://iblockspam.com/blog/mta-sts-tls-rpt-explained) covers the gateway case.

## How to publish it

1. **Check your MX hosts support TLS** with valid certificates for their names. That's what enforce mode requires; testing mode tells you if they don't.
2. **Create the policy host.** Add an A, AAAA or CNAME record for `mta-sts.<your domain>` pointing at a web server you control, and get an HTTPS certificate for that name.
3. **Upload the policy file** so that `https://mta-sts.<your domain>/.well-known/mta-sts.txt` returns it with HTTP 200 and the `text/plain` content type. RFC 8461 says senders must not follow redirects, so the URL has to answer directly.
4. **Publish the TLS-RPT record** at `_smtp._tls.<your domain>`, so reports start arriving.
5. **Publish the `_mta-sts` TXT record** last. Senders only look for the policy once this record exists.
6. **Read the reports** for a few weeks. Our [TLS-RPT Report Analyzer](https://iblockspam.com/tools/tls-rpt-analyzer) opens them in your browser.
7. **Switch to enforce**: change `mode` to `enforce` in the file, then change the `id` in the TXT record.

Whenever you change the policy file, change the `id` too. Microsoft's documentation makes the same point: without a new id, senders keep the cached policy until its max_age runs out.

## Turning MTA-STS off

RFC 8461 describes a clean opt-out: publish a policy with `mode: none` and a small max_age (it suggests one day), change the id, and remove the TXT record and the policy file only after all previously served policies have expired. Choose **none** in the generator to build that policy.

## TLS-RPT addresses

The `rua` in the TLS-RPT record takes a `mailto:` address or an `https://` URL, or several separated by commas. Reports arrive as JSON, usually compressed, roughly once a day from each sending organization that supports TLS-RPT. RFC 8460 says reports sent by email must be DKIM-signed by the reporting domain. Use a mailbox that can take automated mail: a shared or dedicated address works better than a person's inbox.

## Limitations

- It doesn't look up your MX records. Enter them yourself, or copy them from the [MX Lookup](https://iblockspam.com/tools/mx-lookup).
- It can't check that your MX hosts offer valid TLS, or host the policy file for you.
- MTA-STS protects mail sent **to** your domain by senders that support it. It doesn't change how your own outgoing mail is sent.

## Sources

- [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html)
- [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html)
- [Microsoft Learn: Enhancing mail flow with MTA-STS](https://learn.microsoft.com/en-us/purview/enhancing-mail-flow-with-mta-sts)
- [Google Workspace Admin Help: Create an MTA-STS policy](https://support.google.com/a/answer/9276511)
- [Google Workspace Admin Help: About MTA-STS and TLS reporting](https://support.google.com/a/answer/9261504)

## Frequently asked questions

### What max_age should an MTA-STS policy use?

Start with one to two weeks (604800 to 1209600 seconds) in testing mode, which is what Google recommends. RFC 8461 allows up to 31557600 seconds and expects values of weeks or more, because longer caching leaves fewer chances to tamper with a policy refresh. Raise it once enforce mode is stable.

### Where do I host the MTA-STS policy file?

At https://mta-sts.yourdomain/.well-known/mta-sts.txt, on any web server that can serve a plain text file over HTTPS with a valid certificate for the mta-sts host name. Senders don't follow redirects, so the file must answer directly with HTTP 200 and the text/plain content type.

### When do I change the MTA-STS policy id?

Every time you change the policy file, for example when you add an MX host or switch from testing to enforce. Senders compare the id in the _mta-sts TXT record with the one they cached; if it hasn't changed, they keep using the old policy until its max_age runs out.

### Can I use a wildcard in the MTA-STS mx line?

Yes. RFC 8461 allows a pattern such as *.example.net, and Google says the wildcard replaces only the leftmost label. Microsoft's own example for domains whose MX points directly to Exchange Online is mx: *.mail.protection.outlook.com.

### How do I turn MTA-STS off safely?

Publish a policy with mode: none and a short max_age, such as one day, and change the id so senders fetch it. Remove the TXT record and the policy file only after every previously cached policy has expired, which can take as long as the old max_age.

---

Source: iBlockSpam, https://iblockspam.com/tools/mta-sts-generator (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt