Question 1

What is MTA-STS and why does my domain need it?

Accepted Answer

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets a domain owner declare that mail servers sending to the domain must use TLS and must verify the receiving servers certificate against the published MX hostnames. Without MTA-STS the SMTP STARTTLS handshake is opportunistic and vulnerable to a downgrade attack: an active attacker can strip STARTTLS from the SMTP banner and the message will still be delivered in cleartext. MTA-STS turns that opportunistic upgrade into an enforced policy. Pair it with TLS-RPT (RFC 8460) so receiving servers send aggregate failure reports back to a mailbox you control.

Question 2

What are the two records I need to publish for MTA-STS?

Accepted Answer

Two TXT records and one HTTPS-served policy file. The MTA-STS DNS record at _mta-sts.yourdomain.com TXT carries v=STSv1 and an id field that changes every time the policy is updated. The TLS-RPT DNS record at _smtp._tls.yourdomain.com TXT carries v=TLSRPTv1 and the rua mailbox or HTTPS endpoint that should receive aggregate reports. The policy file itself is hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and is fetched by sending servers over HTTPS. The certificate served on the mta-sts subdomain must be valid for that subdomain.

Question 3

What is the difference between mode=enforce, mode=testing, and mode=none?

Accepted Answer

mode=enforce tells sending servers to refuse delivery if MX hostname verification or TLS fails. mode=testing tells sending servers to attempt the policy and report failures via TLS-RPT but to deliver the message anyway, which is the recommended initial mode. mode=none disables the policy and is used to retire a previously published policy without breaking caches that still hold it. Roll out at testing for two to four weeks, watch the TLS-RPT aggregate reports, fix any MX or certificate issues, then move to enforce.

Question 4

Why does the policy file need a max_age value?

Accepted Answer

max_age is the number of seconds a sending server may cache the policy. RFC 8461 sets a minimum of 86400 seconds (one day) and a recommended starting value of around 604800 seconds (one week) once the policy is stable in enforce mode. Larger max_age values give better protection against an attacker that briefly takes the mta-sts host offline; smaller values let you roll changes faster. Every policy update must also bump the id in the DNS record so sending servers know to refetch.

Question 5

How does MTA-STS interact with DANE?

Accepted Answer

MTA-STS and DANE both bind SMTP TLS to the recipient domain. DANE (RFC 7672) does it through DNSSEC-signed TLSA records and is the stronger primitive but requires a DNSSEC-signed zone. MTA-STS does it through HTTPS-fetched policy and is easier to deploy because it only needs a valid web certificate on the mta-sts subdomain. The two are designed to coexist: a sending server that supports both will check DANE first and fall back to MTA-STS. If DNSSEC is not yet in place for the domain, MTA-STS plus TLS-RPT covers most of the practical risk.

Question 6

What goes in the TLS-RPT rua field?

Accepted Answer

rua is a comma-separated list of URIs that should receive the daily aggregate report. Each URI is mailto: for an email address or https: for a web endpoint that accepts the JSON report payload. Most teams point rua at a dedicated mailbox or at a hosted DMARC and TLS-RPT analyser. Reports arrive once per day and are signed JSON describing every TLS handshake outcome from sending servers that attempted the policy. Reading them is how you discover failing MX hosts, expired certificates, and downgrade attempts before they cause delivery problems.

Question 7

How do I update an MTA-STS policy without breaking cached copies?

Accepted Answer

Bump the id in the _mta-sts DNS record every time you change the policy file, then republish the policy file at /.well-known/mta-sts.txt. The id is a string that sending servers compare against the cached copy. When the id changes the cache is invalidated and the next message triggers a fresh policy fetch over HTTPS. Most teams use an ISO 8601 timestamp like 20260507T120000 for the id so the change is also human readable. Without the id bump, sending servers continue to enforce the previous policy until max_age expires.

Question 8

What domains does the policy mx list need to cover?

Accepted Answer

Every hostname returned by the MX records for the domain. Wildcards are allowed in the form *.example.net so that pools of inbound MX hosts share a single entry. The hostnames in the policy must match the certificate served by the receiving MX, including SAN values. A common operational error is to add a new MX host or migrate to a new mail provider without adding the new pattern to the policy file; the next aggregate report will show every sender failing the verification and TLS-RPT will be the canary. Keep the mx list narrow and explicit.

Question 9

Does MTA-STS protect mail my domain sends or only mail it receives?

Accepted Answer

It protects mail your domain receives. Any sending server that supports MTA-STS will fetch your policy and enforce TLS plus MX verification when delivering to your domain. Outbound mail from your domain is governed by the recipient domain's MTA-STS policy if they publish one. To harden outbound delivery, configure your sending platform to honour MTA-STS and DANE policies on the destination domain. Major mailbox providers and many transactional senders already do this by default.

Question 10

Where does this generator differ from a DNS analyzer?

Accepted Answer

The generator builds the two DNS records and the .well-known policy file from scratch with validation against RFC 8461 and RFC 8460. A DNS analyzer checks what is already published on a live domain, including SPF, DKIM, DMARC, MTA-STS, and TLS-RPT. Use the generator to write the records and policy file, then publish them, then verify the deployment with the DNS security analyzer.

Field	Meaning
version: STSv1	Policy version. Required first line. RFC 8461 currently defines only STSv1.
mode: enforce	Receiving policy. enforce blocks delivery on failure; testing reports without blocking; none retires a previously published policy.
mx	One line per allowed MX hostname pattern. Must cover every MX returned by the domain. Leading wildcards allowed.
max_age	Seconds a sending server may cache the policy. Minimum 86400. Recommended start: 604800. Larger is more resilient against an attacker briefly downing the mta-sts host.
v=STSv1; id=...	The DNS pointer at `_mta-sts`. Bump id on every policy change so caches refetch immediately rather than at max_age.
v=TLSRPTv1; rua=...	TLS-RPT record at `_smtp._tls`. rua is a comma-separated list of mailto: or https: report destinations.

Field	Meaning
version: STSv1	Policy version. Required first line. RFC 8461 currently defines only STSv1.
mode: enforce	Receiving policy. enforce blocks delivery on failure; testing reports without blocking; none retires a previously published policy.
mx	One line per allowed MX hostname pattern. Must cover every MX returned by the domain. Leading wildcards allowed.
max_age	Seconds a sending server may cache the policy. Minimum 86400. Recommended start: 604800. Larger is more resilient against an attacker briefly downing the mta-sts host.
v=STSv1; id=...	The DNS pointer at `_mta-sts`. Bump id on every policy change so caches refetch immediately rather than at max_age.
v=TLSRPTv1; rua=...	TLS-RPT record at `_smtp._tls`. rua is a comma-separated list of mailto: or https: report destinations.

MTA-STS and TLS-RPT Generatorenforce SMTP TLS and receive failure reports

Generated artifacts

How to roll out MTA-STS safely

Field reference

Common policy examples

Google Workspace inbound

Microsoft 365 inbound

Self-hosted with two MX hosts

Retiring a previously published policy

MTA-STS, DANE, and the wider email stack

Related security resources

Frequently asked questions

What is MTA-STS and why does my domain need it?

What are the two records I need to publish for MTA-STS?

What is the difference between mode=enforce, mode=testing, and mode=none?

Why does the policy file need a max_age value?

How does MTA-STS interact with DANE?

What goes in the TLS-RPT rua field?

How do I update an MTA-STS policy without breaking cached copies?

What domains does the policy mx list need to cover?

Does MTA-STS protect mail my domain sends or only mail it receives?

Where does this generator differ from a DNS analyzer?

Related features

Vulnerability scanning tools that map your attack surface

Cyber security assessments

Verify the policy and the certificate after you publish

Generated artifacts

How to roll out MTA-STS safely

Field reference

Common policy examples

Google Workspace inbound

Microsoft 365 inbound

Self-hosted with two MX hosts

Retiring a previously published policy

MTA-STS, DANE, and the wider email stack

Related security resources

Frequently asked questions

What is MTA-STS and why does my domain need it?

What are the two records I need to publish for MTA-STS?

What is the difference between mode=enforce, mode=testing, and mode=none?

Why does the policy file need a max_age value?

How does MTA-STS interact with DANE?

What goes in the TLS-RPT rua field?

How do I update an MTA-STS policy without breaking cached copies?

What domains does the policy mx list need to cover?

Does MTA-STS protect mail my domain sends or only mail it receives?

Where does this generator differ from a DNS analyzer?

MTA-STS and TLS-RPT Generator
enforce SMTP TLS and receive failure reports