MTA-STS and TLS-RPT: Should a Small Business Set Them Up?

What MTA-STS and TLS-RPT protect against

When another company's server sends an email to you, it usually tries to encrypt the connection with TLS. But plain SMTP allows unencrypted delivery, and if encryption fails, most servers send the message anyway. Google lists the common problems: expired certificates, certificates that do not match the server name, untrusted certificates and no support for secure protocols (Google: About MTA-STS and TLS reporting).

That gap allows a man-in-the-middle attack: someone on the network path strips the encryption or redirects mail to their own server, reads it and passes it on. MTA-STS (defined in RFC 8461) fixes this by publishing a policy that says: only deliver to these mail servers, only with a valid certificate, and only over TLS. TLS-RPT (RFC 8460) asks sending servers to report problems to you.

MTA-STS protects incoming mail. Outgoing protection depends on your provider honouring the recipient's policy; both Gmail and Exchange Online already do that automatically.

Where MTA-STS ranks: priorities for a small business

Most email incidents at small businesses start with a stolen password or a spoofed invoice, not with someone intercepting server-to-server traffic. So MTA-STS comes after the basics.

1. MFA on every mailbox, especially admins.
2. SPF, DKIM and DMARC published, with DMARC moving towards quarantine or reject. See our guide to DMARC policies: none, quarantine and reject.
3. Basic tenant hardening: our Microsoft 365 security checklist or Google Workspace security checklist.
4. Then MTA-STS and TLS-RPT, especially if you receive contracts, bank details, medical or legal files by email.

It is a good fit for firms that receive sensitive documents from clients and suppliers, and for anyone working towards a security certification who wants evidence that email in transit is protected. It adds little if your email is a single shared Gmail account with no custom domain, because there is nothing for you to publish.

How MTA-STS works: one file and two DNS records

MTA-STS has three parts. All of them live on your own domain, not inside Microsoft 365 or Google Workspace.

• A policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, served over HTTPS with a valid certificate.
• A TXT record at _mta-sts.yourdomain.com containing v=STSv1; id=20261019T000000;. The id is any unique string; change it every time you change the policy.
• A TLS-RPT TXT record at _smtp._tls.yourdomain.com containing v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com.

The policy file is four kinds of line. RFC 8461's own example looks like this, one key per line:

• version: STSv1
• mode: testing (later enforce)
• mx: followed by each of your mail server hostnames, one per line
• max_age: 604800 (seconds; 604800 is one week)

For Microsoft 365, Microsoft's documentation shows mx: *.mail.protection.outlook.com (Microsoft: MTA-STS for Exchange Online). For Google Workspace and other providers, list each MX host exactly as it appears in your MX records. A wildcard only matches one level, so *.google.com does not match aspmx.l.google.com.

If DNS records are unfamiliar, our explainer on DNS records: A, CNAME, MX and TXT covers the basics.

MTA-STS setup, step by step

The order matters: publish the file first, then the DNS records that point senders to it.

1. 1

   List your current MX records

   Look them up at your DNS host. Every server that receives mail for you, including backup or filtering services, must be in the policy, or mail to it will fail in enforce mode.

2. 2

   Host the policy file on mta-sts.yourdomain.com

   Create the subdomain on any host that serves a static file over HTTPS with a valid certificate. Microsoft cannot host it for you and suggests Azure Static Web Apps; a static site host or Cloudflare also works.

3. 3

   Start with mode: testing

   Use a short max_age of one to two weeks, as Google recommends for testing (604800 to 1209600 seconds).

4. 4

   Add the _smtp._tls TXT record for reports

   Point rua= at a mailbox or a reporting service that turns the JSON reports into something readable.

5. 5

   Add the _mta-sts TXT record

   This switches the policy on for senders. Check it with an online MTA-STS checker or your provider's tool.

6. 6

   Read reports for about two weeks

   Google says two weeks of report data is enough to find and fix problems. Look for certificate mismatches and unknown MX hosts.

7. 7

   Switch to mode: enforce and update the id

   Raise max_age (weeks or more, up to the RFC maximum of 31557600 seconds) and change the id in the TXT record so senders fetch the new policy.

Testing mode, enforce mode and how it can break mail

In testing mode, senders that support TLS-RPT report failures but still deliver as normal. In enforce mode, senders that support MTA-STS will not deliver to a server that fails the certificate or MX check, or does not support STARTTLS. Microsoft notes that mail is only blocked when both sides use MTA-STS and validation fails.

To remove MTA-STS cleanly, RFC 8461 says to publish a policy with mode: none and a short max_age (for example one day), change the TXT id, and only delete the records after the old cached policies have expired.

What TLS-RPT reports look like and what to do with them

TLS-RPT reports arrive as daily emails, usually with a compressed JSON attachment, from large senders such as Google and Microsoft. Google's help page lists what they contain: the MTA-STS policy the sender saw, traffic statistics, failed connections and messages that could not be sent. Google also warns you may not receive many reports until more providers send them.

Raw JSON is hard to read. Several DMARC reporting services also parse TLS-RPT reports; if you already use one for DMARC, check whether it accepts TLS reports too.

Do it yourself or get help?

If you are comfortable creating a subdomain with HTTPS and editing DNS, MTA-STS takes about an hour to set up plus two weeks of watching reports. The common mistakes are a missing MX host, an expired certificate on the mta-sts subdomain, and forgetting to change the id after editing the policy.

If you would rather not, our Emails Land in Spam Fix (S$249) covers SPF, DKIM and DMARC and can add MTA-STS and TLS-RPT in testing mode, then move you to enforce once reports are clean. For DNS changes on their own, Domain & DNS Setup (S$99) handles the records.