MTA-STS and TLS-RPT Setup Guide: Enforce Encrypted Delivery in an Afternoon
SMTP encrypts opportunistically, which means anyone on the path between a sending server and yours can strip the encryption offer and the message falls back to plaintext without anyone knowing. MTA-STS closes that hole for mail coming to you, and TLS-RPT tells you when something tries. Both take an afternoon and neither needs anything more than DNS and a static file over HTTPS.
What each part does
The DNS record at _mta-sts.yourdomain announces that a policy exists and carries an id that changes whenever the policy changes. The policy file, served at https://mta-sts.yourdomain/.well-known/mta-sts.txt, lists your mail servers and says whether senders should enforce TLS to them. The TLS-RPT record at _smtp._tls.yourdomain names an address where sending servers report failures. Senders that support MTA-STS — Google, Microsoft, Proton, most large providers — check the DNS record, fetch the policy, cache it for max_age, and refuse to deliver over plaintext if the policy says enforce.
Step 1: TLS-RPT first
Publish reporting before the policy so you can see what is happening from day one. Create a TXT record:
_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"
Reports are daily gzip JSON files, one per reporting provider. They are small and mostly say "all successful". Use a dedicated mailbox, or point rua at a DMARC reporting service that handles TLS-RPT too.
Step 2: write the policy file
A plain text file with LF line endings. For Google Workspace:
version: STSv1 mode: testing mx: smtp.google.com mx: *.aspmx.l.google.com mx: aspmx.l.google.com max_age: 86400
For Microsoft 365, replace the mx lines with mx: *.mail.protection.outlook.com. The mx patterns must cover every MX record the domain publishes — check with the MX checker — and a wildcard matches one label only, so *.aspmx.l.google.com matches alt1.aspmx.l.google.com but not aspmx.l.google.com itself, which needs its own line. Start in testing with a one-day max_age.
Step 3: host it over HTTPS
The file must be served from exactly mta-sts.yourdomain, over HTTPS with a certificate valid for that hostname, at the path /.well-known/mta-sts.txt, with no redirects. The simplest hosting is a Cloudflare Worker or Pages project bound to the subdomain, or a static bucket behind a CDN. Cloudflare's proxy will issue the certificate for the subdomain automatically. If you use a Worker, add an Access-Control-Allow-Origin: * header — it costs nothing and lets browser-based checkers read the file.
Step 4: publish the DNS record
_mta-sts.yourdomain.com TXT "v=STSv1; id=20260905120000"
The id is any string up to 32 characters; a timestamp is conventional. Every time you edit the policy file, change the id, or senders keep using their cached copy until max_age expires.
Step 5: verify and wait
Run the domain through the MTA-STS checker. It confirms both DNS records, that the policy host resolves, and — where the server sends the CORS header — that the policy parses and covers every MX. Then leave it in testing for two weeks and read the TLS-RPT reports. On Google or Microsoft MX they will be uniformly successful. If you see failures, the usual cause is an MX host missing from the policy.
Step 6: enforce
Change mode: testing to mode: enforce, raise max_age to 604800 (a week) or 1209600 (two weeks), and bump the DNS id. That is it. From now on, a sender that supports MTA-STS will refuse to deliver to your domain over plaintext or to a server whose certificate does not match.
Do not set max_age to the maximum of one year. If you ever migrate mail providers, senders holding a year-old policy will refuse to deliver to the new MX. One to two weeks is the sensible range.
Does this help deliverability?
Not directly — it protects inbound mail, not outbound. It does contribute to how a domain looks to anyone assessing it, and the deliverability score counts it for that reason. Set it up on the primary domain where the value is real; on secondary cold email domains it is optional and mostly cosmetic.
Verify both records
Once published, run the domain through the TLS-RPT checker to confirm the _smtp._tls record and reporting address, and the DANE / TLSA lookup if your provider publishes TLSA — it also shows whether the zone is DNSSEC-validated, which DANE needs and MTA-STS does not.
Sources
- RFC 8461 — SMTP MTA Strict Transport Security — IETF
- RFC 8460 — SMTP TLS Reporting — IETF
- Enhance security for outgoing email (MTA-STS) — Google Workspace Admin Help
Tools for this
MX / ESP checkerIdentify which provider hosts the mail.MTA-STS checkerPolicy record, file and MX coverage.Deliverability scoreGrade a domain out of 100, fixes ranked.TLS-RPT checkerValidate _smtp._tls and its reporting address.Frequently asked questions
Do I need DNSSEC for MTA-STS?
No. That is the point of it — MTA-STS uses HTTPS for the policy instead of DNSSEC, so any domain can publish one. DANE is the DNSSEC-based alternative and the two can coexist.
What happens to mail from senders that do not support MTA-STS?
Nothing changes. They deliver exactly as before. MTA-STS only affects senders that check for it, which today includes Google, Microsoft and most large providers.
Can I use a CNAME for mta-sts.yourdomain?
Yes, as long as whatever it points to serves the file with a certificate valid for mta-sts.yourdomain. Cloudflare-proxied CNAMEs handle this automatically.
How often do TLS-RPT reports arrive?
Once a day from each reporting sender that delivered to you, only if they support reporting. Google and Microsoft do. Expect one or two small files a day for a typical domain.
Should cold email sending domains have MTA-STS?
Optional. It protects mail sent to the domain, which on a sending domain is mostly replies. It is a small positive signal and the deliverability score counts it, but it is not where the risk is.