MTA-STS: what it protects, the policy file, and TLS-RPT

Mail between servers is encrypted only when both ends offer TLS, and anyone on the network path can delete that offer so the message crosses in plaintext. MTA-STS lets you publish that your mail servers always take TLS with a valid certificate, and which hosts they are, so senders that support it refuse anything less.

Does MTA-STS stop spoofing? No. It protects mail coming in to your domain. SPF, DKIM and DMARC protect your name on mail going out.

Set up MTA-STS, testing first

1. List your MX hosts. Run dig +short MX example.com and write down every host it returns.
2. Write the policy file in testing mode, with one mx: line per host.
3. Serve the file over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt, with a valid certificate for mta-sts.example.com.
4. Publish the TXT record at _mta-sts.example.com with a fresh id.
5. Add a TLS-RPT record, then switch to enforce once the reports show no failures on your own hosts. Change the id in the TXT record every time you edit the file.

Check the file loads before you publish the TXT record:

You should get the policy back as plain text. A redirect, an HTML error page or a certificate warning here means senders get nothing either.

What MTA-STS protects against

Servers upgrade an SMTP connection to TLS with a command called STARTTLS. RFC 8461 describes the gap. An attacker who can delete the server's STARTTLS offer forces the session into plaintext. One who can overwrite your MX record, or reroute the connection, can read or change the message even when the connection uses TLS.

A published policy blocks both attacks. A sender with your policy cached insists on TLS, checks that the MX host is on your list, and checks that its certificate is valid for that name and not expired. If any check fails in enforce mode, the sender doesn't deliver.

The protection starts once a sender has your policy. Section 10 says it works only after a sender has fetched and cached it. A sender without a cached policy, and a sender that doesn't support MTA-STS at all, delivers the way it always has.

The TXT record at _mta-sts

Publish one TXT record at _mta-sts:

v=STSv1 is the only version. The id is up to 32 letters and digits, and it has to change every time you edit the policy file. Senders compare it with the one they cached, and a changed id is what makes them fetch the file again. Microsoft suggests the UTC time of the edit, as above, which never repeats.

The policy file, line by line

The file lives at a fixed path on the mta-sts host. This is Microsoft's example for a domain on Microsoft 365, set to testing:

Serve it as text/plain with a 200 response. Section 3.3 says senders must not follow a redirect, and it suggests they give up after a minute or past 64 kilobytes.

Microsoft 365 and Google Workspace mx lines

For a domain whose MX points straight at Exchange Online, Microsoft's MTA-STS guide gives the single line mx: *.mail.protection.outlook.com. Microsoft says the wildcard is safe there because only one organization can receive mail for a domain, and it says not to copy the wildcard pattern for other providers.

If you enabled inbound DNSSEC and your MX ends in mx.microsoft, list that exact host. Microsoft's DANE setup steps say to set the policy to testing first, swap the old mx line for the new host, and change the id in both places.

Google's own domain publishes these lines, covering smtp.google.com and the aspmx hosts:

Compare them with your own dig output and keep a line for every host you see. You host the file yourself on either provider. Google's steps say to upload it to a public web server. Microsoft's guide walks through serving it from an Azure Static Web App, which issues the certificate for you.

Both providers check other domains' policies on your outgoing mail. Google says Gmail follows a recipient's policy in enforce mode. Exchange Online does too, and a failure comes back as a bounce with 5.4.8 when the MX isn't on the recipient's list, or 5.7.5 when the certificate fails.

Testing first, then enforce

Start in testing. Google suggests a max_age of one to two weeks while you test. Read the TLS-RPT reports for failures from your own MX hosts before you move on.

In enforce, a mistake in the policy delays your mail. If you add a mail host and forget its mx line, or your MX certificate expires, senders with the policy cached refuse to deliver. The standard makes them check your TXT record for a new id before they bounce a message, so fixing the file and changing the id reaches them while they retry. A sender that ignores that rule keeps your old policy until its max_age runs out.

Hosting the policy file is the hard part

The record is one TXT line. The file needs a web server at mta-sts.example.com with a certificate for that exact name, renewed before it expires, for one short text file. If the host goes down or the certificate lapses, senders keep the policy they cached until max_age runs out, then deliver as though you had none, so your mail still arrives without the protection.

Any static host that serves a custom domain over HTTPS will do: a small web server you already run, a static site service, or Microsoft's Azure route above. Whatever you pick, put a reminder on the certificate's expiry date and on every change to your MX records.

On the Business plan and up, we host MTA-STS for you. You publish two CNAMEs, and we serve the TXT record, the policy file and a certificate for mta-sts.example.com. We read the mx lines from your DNS, change the id with every edit, and you switch between testing and enforce from a page. We read TLS-RPT reports too. Your domain's MTA-STS page gives the record to publish, and on the Business plan and up it lists the failures by mail server. Start with a free account and add it when you're ready.

TLS-RPT: reports on failed connections

With TLS-RPT, defined in RFC 8460, you publish a second TXT record and senders mail you a report when a TLS connection to you fails:

Senders that support it mail a JSON report for each UTC day, usually gzipped. Each failure carries a type such as starttls-not-supported, certificate-host-mismatch, certificate-expired or sts-policy-fetch-error. Microsoft's docs say Exchange Online sends these reports. Google's docs say to expect few reports until more providers support TLS reporting.

Reports that come by email must carry a DKIM signature from the sender, and the standard says to ignore any without one. Use a mailbox or collector that can open gzip attachments. A report full of sts-policy-fetch-error means senders can't load your policy file.

Switch MTA-STS off in order

Deleting the TXT record isn't enough, because senders keep a cached enforce policy until it expires. Follow the order in Section 8.3:

1. Publish mode: none with a short max_age, such as one day.
2. Change the id in the TXT record so senders fetch the new file.
3. Wait out the longest max_age you ever served, counted from the day you stopped serving it.
4. Delete the TXT record and the policy host.