MTA-STS and TLS-RPT, explained

SPF, DKIM and DMARC protect against mail forged in your name. MTA-STS protects something else: the journey mail takes from the sender's server to yours. Without it, that journey is encrypted only when nobody interferes.

Why encryption between mail servers is not enough on its own.

Mail servers encrypt their connections with STARTTLS: the receiving server offers encryption, and the sender takes it up. But the offer travels unprotected. An attacker who can sit between the two servers can remove it, and the sender then delivers in plain text, without an error. A sender also has no way to know which certificate your server should present, so a forged one is accepted too.

MTA-STS closes both gaps. You publish, over HTTPS, which servers receive your mail and that they must be reached over TLS with a valid certificate. A sender that supports MTA-STS then refuses to deliver any other way.

The two parts: a TXT record and a policy file.

The TXT record at _mta-sts announces that a policy exists, and gives it an id:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261114080000Z"

The policy itself is a short text file, served at a fixed address on the mta-sts subdomain:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mail1.example.com
mx: mail2.example.com
max_age: 604800

• mode is testing, enforce or none. In testing, senders report failures but still deliver; only enforce protects anything.
• mx lists the servers allowed to receive your mail, one line each. They must cover every host in your MX records. A wildcard such as *.example.net matches exactly one label at the start.
• max_age is how long, in seconds, senders keep the policy. RFC 8461 allows up to 31,557,600 (a year) and expects weeks or more in normal use.
• id in the TXT record is up to 32 letters and digits. A date and time works well. Senders fetch the policy again when the id changes or their cached copy expires.

The file must be served over HTTPS with a valid certificate for mta-sts. followed by your domain, without redirects: RFC 8461 forbids senders to follow them.

TLS-RPT: find out when delivery fails.

TLS reporting is a single TXT record at _smtp._tls. It asks sending servers to send you a daily summary of their connections to your domain, including the ones that failed:

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Reports arrive as compressed JSON, usually one per sending organisation per day. They name the reason for each failure, for example starttls-not-supported, certificate-expired, certificate-host-mismatch or sts-policy-fetch-error. Without them, a broken certificate or an attack on your mail is invisible to you; with MTA-STS enforced, it is also the first sign that some mail is not arriving.

Roll it out in four steps.

1. Publish TLS-RPT. It changes nothing about delivery, so it is safe on day one.
2. Publish the policy in testing mode, with a short max_age such as 86400 (one day), and then the _mta-sts TXT record.
3. Read the reports for a few weeks. Fix every failure from a server that should receive your mail: a certificate that does not match the host name, an expired certificate, or an MX host missing from the policy.
4. Switch to enforce and raise max_age to a week or more. Update the policy file first and the id second, so no sender caches an old policy.

Both Google Workspace and Microsoft recommend starting in testing mode. Microsoft's guide for Exchange Online gives a ready policy for domains whose MX points to Exchange Online (mx: *.mail.protection.outlook.com), and warns that the wildcard is specific to its service and should not be copied for other providers. Microsoft also states that Exchange Online cannot host the policy file, so it needs a small HTTPS site of your own on the mta-sts subdomain.

When something changes.

• Changing mail provider: add the new MX hosts to the policy (file first, then a new id) before you change the MX records, and remove the old ones only after the move.
• Something breaks under enforce: switch the policy to testing and change the id. Senders stop enforcing as soon as they fetch it again, and the reports keep coming.
• Removing MTA-STS: publish mode: none with a short max_age and a new id, wait until the old max_age has passed, then remove the TXT record and the policy file.

Common mistakes.

• A policy left in testing for good. It reports, but protects nothing.
• An MX host missing from the policy, typically a backup server or a host added later. Under enforce, senders will not deliver to it.
• The policy file edited without a new id. Senders keep the old policy until its max_age runs out.
• A redirect or a missing certificate on mta-sts., for example when the subdomain points at a website that sends visitors elsewhere. Senders treat the policy as unavailable.
• Enforcing before reading the reports.

What TrustSek checks.

The scan reads your _mta-sts and _smtp._tls records and fetches the policy file to read its mode. It does not try to deliver mail.

A domain with no MTA-STS policy at all raises no finding in the scan. Both checks apply only to domains that receive mail, so a domain without MX records, or with a null MX, is not judged on them. You can read all three records for any domain with the free MTA-STS and DNSSEC check. They are part of the email security module, with DKIM, SPF and DMARC.

Questions

Does MTA-STS protect the mail I send?

No. It protects mail sent to your domain. Whether your outgoing mail is protected depends on the recipient's policy and on your provider honouring it. Exchange Online and Gmail both do when they send.

Can enforce mode stop legitimate mail?

Only from senders that support MTA-STS, and only when your server fails the check: no TLS, an invalid certificate, or a host the policy does not list. Senders without MTA-STS support deliver as before. That is why the testing period with TLS reports comes first.

Does MTA-STS need DNSSEC?

No. It relies on HTTPS and ordinary web certificates instead. DANE for SMTP (RFC 7672) does the same job through DNSSEC-signed records. A domain can publish both.

Is the first message to a new recipient protected?

Not fully. A sender that has never fetched your policy has nothing to enforce yet, so the protection starts once the policy is cached. That is why a long max_age matters once you enforce.

Check your domain's email security

See whether your domain enforces MTA-STS and reports TLS failures, alongside DMARC, SPF and the rest of the outside-in score.

Your domain

Check your domain

Free, no sign-up. Takes about 30 seconds.