The MTA-STS & TLS-RPT Generator is a three-step wizard, and each step is made of input cards with a What's this? link in the corner. This article is the long-form version of those pop-ups: one section per card, in wizard order, with the same control rendered inline. Where a card offers a choice, select an option in the preview and the explanation for that specific value appears underneath.
MTA-STS is unusual among the email standards because the answers you give here end up in three separate places, and all three have to agree:
# 1. DNS — tells senders a policy exists
_mta-sts.acme-corp.com. IN TXT "v=STSv1; id=20260802T090000;"
# 2. HTTPS — the policy itself, served from https://mta-sts.acme-corp.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.acme-corp.com
mx: mx2.acme-corp.com
max_age: 604800
# 3. DNS — where senders report what they found
_smtp._tls.acme-corp.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@acme-corp.com"Domain
Step 1. Unlike SPF and DMARC, this is the domain that receives mail — MTA-STS is a statement to the rest of the internet about how mail arriving at you must be delivered.
Enter the bare domain — the part after the @ in the addresses you receive mail on. The wizard derives both DNS names from it (_mta-sts. and _smtp._tls.) and the HTTPS host the policy must be served from (mta-sts.).
That HTTPS host is what makes MTA-STS more work than the other records. It needs to resolve, serve /.well-known/mta-sts.txt over HTTPS, and present a valid publicly-trusted certificate for mta-sts.yourdomain. A self-signed certificate or a redirect to another hostname will fail — senders treat a policy they cannot fetch cleanly as no policy at all.
Look up existing fetches whatever the domain publishes today — both the record and the policy file — and offers to prefill the wizard with it, which is how you edit an existing deployment rather than rebuild it.
Policy mode
Step 2 opens with the field that decides what actually happens when a sender cannot verify your server. It is the single most consequential choice in the wizard. Select a mode to see what it does.
The attack MTA-STS closes is the downgrade: SMTP negotiates encryption after the connection is open, so an attacker in the path can strip the STARTTLS offer and watch the mail go by in plain text. Without a policy the sending server has no way to know that TLS was ever on offer. With mode: enforce it knows, and refuses.
Allowed MX hosts
The list of hostnames a sender is permitted to deliver to. The certificate the server presents must match one of these names, which is what ties the policy to your actual infrastructure.
Fetch from DNS reads the domain's live MX records and fills the list, which is the safest way to populate it — the failure mode here is forgetting a host, and your DNS already knows the full set.
A single wildcard label is allowed at the front of the name. *.acme-corp.com matches mx1.acme-corp.com but not mx1.mail.acme-corp.com — the wildcard covers one label, not a whole subtree.
| Pattern | Matches | Does not match |
|---|---|---|
mx1.acme-corp.com | That host exactly | Anything else |
*.acme-corp.com | mx1.acme-corp.com, mx2.acme-corp.com | mx1.mail.acme-corp.com, acme-corp.com |
*.mail.protection.outlook.com | A Microsoft 365 tenant host | Hosts one level deeper |
Whenever you add or change an MX record, come back and update the policy before the new host starts receiving mail — and remember that senders may be holding a cached copy for as long as the max_age you published.
Policy cache
Step 3. max_age is how long, in seconds, a sender may keep using its cached copy of your policy before fetching it again. Select a value to see the trade-off.
A long cache is a security feature, not just a performance one. An attacker who can block a sender's access to your policy file cannot make that sender forget the policy — the cached copy keeps enforcing until it expires. That is the whole point of the field, and the reason the specification recommends at least a week for a settled deployment.
The cost is symmetrical: your own changes take just as long to propagate. Plan MX migrations around the value you published, not around DNS TTLs.
id — a timestamp the wizard regenerates each time. Senders compare it against the one they cached to decide whether to re-fetch the policy. If you edit the policy file without changing the id, senders will not notice for up to max_age.TLS-RPT reporting
The last card. TLS-RPT is a separate standard that pairs with MTA-STS: senders post you a daily JSON summary of every TLS negotiation with your servers, successful and failed.
Point it at a mailbox you read or at a reporting service that parses the JSON for you. Several addresses are allowed. The record is independent of MTA-STS — you can publish TLS-RPT on its own to find out how much of your inbound mail is already encrypted before you commit to a policy at all.
What the wizard does with your answers
Pressing Generate produces all three artifacts at once: the policy file with its version, mode, mx and max_age lines, the _mta-sts TXT record with a fresh id, and the _smtp._tls TLS-RPT record if reporting is on. Each comes with the deployment step that goes with it, plus a validation checklist covering the mode you chose, the MX coverage and the cache duration.
Nothing is published for you — the policy file in particular has to be uploaded to a web host you control. Once it is live, confirm the whole deployment with the MTA-STS Checker.
Frequently Asked Questions
1. Do I need to host the policy file myself?
It has to be served from mta-sts.yourdomain over HTTPS with a valid certificate, but it can be any web host — a static site, an S3 bucket behind a CDN, a subdomain on your existing web server. The file is a few lines of plain text and never changes unless your policy does.
2. What happens if my certificate expires?
In enforce mode, senders holding your policy will refuse to deliver to a server whose certificate does not validate — mail queues rather than arrives. This applies to the MX servers’ certificates, not just the policy host’s. Certificate monitoring stops being optional once you enforce.
3. How is this different from DANE?
Both force verified TLS on inbound mail. MTA-STS trusts the public CA system and publishes its policy over HTTPS; DANE pins the certificate in DNS and trusts DNSSEC instead. MTA-STS is easier to deploy because it needs no DNSSEC; DANE is stronger because it does not depend on any CA. Large providers publish both.
4. Can I skip testing mode?
You can, and if your MX list is short and your certificates are known-good it usually works. The risk is asymmetric though: the failure mode of testing is a slightly noisy report, and the failure mode of a wrong enforce policy is inbound mail that never arrives and never bounces until the sending queue gives up.
5. Why does the id change every time I generate?
Because senders use it to decide whether their cached policy is stale. The wizard derives it from the moment you pressed Generate, so re-publishing after any edit automatically tells senders to re-fetch.