MTA-STS and TLS-RPT explained: encrypting the mail sent to you

MTA-STS (Mail Transfer Agent Strict Transport Security) lets you tell other mail servers that mail for your domain must be delivered over an encrypted, verified connection, and never in plain text. TLS-RPT (TLS Reporting) is its companion: receivers send you daily reports of any delivery where the encryption failed. Together they close a gap that SPF, DKIM and DMARC do not touch, and they roll out the same cautious way, by watching first and enforcing later.

The gap MTA-STS closes

SPF, DKIM and DMARC are about identity. They let receivers check that mail claiming to be from your domain really is, which stops people impersonating you. They say nothing about how mail travels between servers, or about mail coming in to you.

When one mail server delivers to another, encryption is opportunistic. The sending server connects, asks whether the receiving server supports encryption (a command called STARTTLS), and upgrades the connection if the answer is yes. If the answer is no, it carries on in plain text. That was a sensible way to introduce encryption gradually, but it means anyone positioned on the network path can strip the STARTTLS offer out of the conversation, and the sender will quietly fall back to sending your mail unencrypted. Plain SMTP also does not check that the receiving server’s certificate is genuine, so a server impersonating your mail server can accept the connection too.

MTA-STS, defined in RFC 8461, fixes both problems. It tells senders: for this domain, always use encryption, always check the certificate, and only deliver to these mail servers. If any of that fails, do not deliver at all.

How MTA-STS works

MTA-STS has two parts, a DNS record and a policy file served over HTTPS.

The DNS record is a TXT record at _mta-sts.yourdomain.com:

v=STSv1; id=20261003T000000

It says the domain has a policy, and gives it an id. Senders cache your policy, and the id is how they notice it has changed. Change the id every time you change the policy file.

The policy file lives at a fixed address, https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and looks like this:

version: STSv1
mode: testing
mx: yourdomain-com.mail.protection.outlook.com
max_age: 604800

mode is testing, enforce or none. In testing, senders report failures but still deliver. In enforce, they refuse to deliver over a connection that fails the checks. none withdraws the policy.
mx lists the mail servers allowed to receive your mail. You can list several, and use a wildcard such as *.mail.protection.outlook.com. These must match your real MX records.
max_age is how long, in seconds, senders may cache the policy. 604800 is one week.

The file must be served over HTTPS with a valid certificate for mta-sts.yourdomain.com, which is what stops an attacker on the network faking the policy itself. Your mail servers also need valid certificates that match their names. Hosted mail like Microsoft 365 and Google Workspace already has those.

Gmail, Microsoft and other large providers check MTA-STS when they send to you, so a policy covers a large share of your inbound mail as soon as it is published.

TLS-RPT: hearing about failures

TLS-RPT, defined in RFC 8460, is a TXT record at _smtp._tls.yourdomain.com:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

Senders that support it email a daily JSON report to that address, summarizing successful and failed encrypted deliveries to your domain and the reason for each failure: an expired certificate, an MX that does not match your policy, a server that did not offer encryption. It is the TLS equivalent of DMARC aggregate reports, and it serves the same purpose. You find problems in the reports before they turn into lost mail.

Roll it out the same way as DMARC

The safe path will feel familiar if you have read about starting DMARC at p=none.

Publish TLS-RPT first. It changes nothing about delivery and starts the reports flowing.
Publish MTA-STS in testing mode. Senders now check your setup and report failures, but still deliver.
Read the reports for a few weeks. Look for failures and fix their causes, usually an MX missing from the mx lines or a certificate problem.
Switch to enforce and change the id. Once the reports are clean, enforcement starts protecting your mail for real. A longer max_age, up to a few weeks, then makes the protection harder to strip.

The trap: changing mail provider

The way MTA-STS goes wrong most often is not on day one. It is months later, when someone moves mail to a new provider and updates the MX records but not the policy file. In enforce mode, every sender that honors MTA-STS will then refuse to deliver to the new servers, because they are not on the list. Senders that do not check MTA-STS still deliver, so the problem looks patchy and confusing rather than a clean outage.

Make the policy file part of any mail migration checklist: add the new MX to the mx lines and change the id before you switch the MX records, then remove the old entry once the move is done. Our MTA-STS checker compares your policy’s mx lines with your live MX records and flags any server the policy does not cover, which makes it a good last check before and after a migration.

Where MTA-STS fits

MTA-STS does not replace DMARC, and DMARC does not replace it. DMARC stops other people sending mail as your domain. MTA-STS protects mail that other people send to your domain from being read or redirected on the way. A well-secured domain has both, and they reinforce each other: getting DMARC to p=reject protects your outbound identity, and MTA-STS in enforce mode protects your inbound mail.

There is an alternative called DANE, which publishes certificate details in DNS instead of a policy file, but it relies on DNSSEC being set up across the domain and its mail servers. MTA-STS needs only ordinary DNS and a web server, which is why it is the easier first step for most businesses.

To see where your domain stands, run the MTA-STS checker for the policy, its mode and TLS-RPT, and the DMARC checker for the identity side.