MTA-STS and TLS-RPT Adoption Among 1,359 Major Domains (2026)

MTA-STS is still rare, even among the biggest domains on the internet. Of 1,359 major domains we checked on 2 October 2026, 58 (4.3%) published an MTA-STS record and only 28 (2.1%) served a working policy in enforce mode. TLS-RPT, the reporting half, was slightly more common at around 6%.

The big mailbox providers are the exception. Gmail and Outlook.com both enforce it, which means the mechanism works at scale. Most senders and receivers have simply not set it up.

What MTA-STS and TLS-RPT do

MTA-STS lets a domain tell senders "only deliver to me over verified TLS". Without it, server-to-server email encryption is opportunistic: if a connection's encryption is stripped or its certificate is wrong, most senders deliver in plain text anyway.

RFC 8461 defines two parts:

1. A DNS TXT record at _mta-sts.<domain>, such as v=STSv1; id=20261001, which says a policy exists.
2. A policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt, listing the permitted MX hosts, a mode (enforce, testing or none) and a max_age.

TLS-RPT (RFC 8460) is the reporting channel. A TXT record at _smtp._tls.<domain> names an address that receives daily reports of TLS failures from senders. Google's MTA-STS setup guide recommends starting in testing mode and reading these reports before moving to enforce.

How we measured

Three samples, 1,359 unique domains, DNS plus a fetch of every policy file.

Sample	Source	Domains
S&P 500	Wikipedia's "List of S&P 500 companies", website domains from Wikidata	496
SaaS	200 largest SaaS-tagged companies by team size in Y Combinator's public directory (yc-oss.github.io mirror)	200
Top sites	Tranco top 1,000 (list ID Y83YG, downloaded 2 October 2026), keeping only domains with a working MX record	700

Some domains appear in more than one sample, giving 1,359 unique domains.

We queried _mta-sts and _smtp._tls TXT records with dnspython against public resolvers at 03:38 UTC on 2 October 2026, counting only records beginning v=STSv1 and v=TLSRPTv1. For every domain with an MTA-STS record we then fetched the policy file over HTTPS with normal certificate validation, as a sending server would, and read its mode. We did not connect to any mail server.

The results

MTA-STS adoption sits between 3% and 5% in every group; TLS-RPT around 6%.

Sample	MTA-STS record	Enforce	Testing	Policy unreachable	TLS-RPT record
S&P 500 (n=496)	16 (3.2%)	6	8	2	30 (6.0%)
SaaS (n=200)	9 (4.5%)	3	3	3	11 (5.5%)
Tranco top 1,000 with MX (n=700)	36 (5.1%)	21	13	2	45 (6.4%)
All unique (n=1,359)	58 (4.3%)	28	23	7

A few patterns:

• Every domain with MTA-STS also had TLS-RPT. The reverse is not true: 14 S&P 500 companies publish TLS-RPT without MTA-STS. That is a sensible way to start, since the reports show what would break before you enforce anything.
• Testing mode is nearly as common as enforce. 23 of the 51 working policies were in testing. Testing is meant to be a phase; some of these domains have probably been in it for years, though a single snapshot cannot tell us how long.
• The top-sites group enforces most. 21 of its 36 policies were in enforce, against 6 of 16 in the S&P 500. The large mailbox and tech platforms in the Tranco list pull this up.

The big mailbox providers

Gmail and Outlook.com enforce MTA-STS. Several other large providers publish nothing.

Domain	MTA-STS	Mode	TLS-RPT
gmail.com	Yes	enforce	Yes
google.com	Yes	enforce	Yes
outlook.com	Yes	enforce	Yes
live.com	Yes	enforce	Yes
microsoft.com	Yes	enforce	Yes
comcast.net	Yes	enforce	Yes
yahoo.com	Yes	testing	Yes
mail.ru	Yes	testing	Yes
zoho.com	No		Yes
aol.com	No		No
icloud.com	No		No
apple.com	No		No
yandex.ru	No		No
qq.com	No		No
163.com	No		No
att.net	No		No

All of these were in the Tranco sample, checked at the same time as everything else. Domains such as hotmail.com and proton.me were not in the Tranco top 1,000 sample, so they are not listed.

Seven broken policies

12% of the domains that publish MTA-STS (7 of 58) serve no usable policy. The DNS record says "I have a policy", and the policy cannot be fetched.

What went wrong	Domains
mta-sts. hostname does not resolve	3
HTTPS certificate expired	1
TLS handshake timed out	1
HTTP 404 Not Found	1
HTTP 403 Forbidden	1

This failure is silent. Under RFC 8461, a sender that cannot fetch a valid policy (and has none cached) delivers as though MTA-STS were not configured. Mail keeps arriving, nobody notices, and the protection the DNS record advertises does not exist. If you remove an MTA-STS host, remove the _mta-sts record too, and renew the policy host's certificate like any other.

We re-tried each failing URL from a second client a few minutes later and got the same failures.

Policy settings in practice

Most working policies cache for a week or a day. The max_age field tells senders how long to remember the policy, in seconds.

max_age	Meaning	Policies
604800	7 days	22
86400	1 day	19
1209600	14 days	4
86401	1 day + 1 second	2
Other (28 days to 1 year)		4

RFC 8461 suggests longer values, in the range of weeks, once a policy is stable, since a long cache is what protects against an attacker who strips the policy lookup itself. A one-day max_age is reasonable while testing, but it offers less protection once a policy is enforced.

Ten working policies used a wildcard MX pattern such as *.example.com, which RFC 8461 permits.

TLS-RPT reports mostly went to specialist services. Counting report destinations across all samples, the most common were dmarcian (15 domains), Valimail (13) and Mailhardener (7).

Should you set it up?

If you receive sensitive mail, yes, but start with TLS-RPT. MTA-STS protects inbound mail to your domain against downgrade and interception. It does nothing for deliverability of the mail you send, so it is not a cold email priority. Fix SPF, DKIM and DMARC first.

When you do set it up:

1. Publish TLS-RPT first. _smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com". Read a few weeks of reports.
2. Host the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid certificate, listing every MX host, in mode: testing.
3. Publish the _mta-sts TXT record with a new id.
4. Move to mode: enforce once reports are clean, change the id, and raise max_age.
5. Monitor the policy host like production. In our data, 7 of 58 domains had let it break.

You can confirm your MX hosts with the MX lookup tool before writing the policy, and see the MTA-STS glossary entry for the terms. The wider deliverability check covers the records that affect inbox placement.

Limitations

• Big domains only. All three samples are large companies or popular sites. Adoption among small businesses is very likely lower.
• Apex domains only. We checked the registrable domain, not mail subdomains.
• Website domain, not mail domain. For the S&P 500 and SaaS samples we used each company's website domain, which is not always the domain its staff receive mail on.
• Fetch from one network. Policy fetches ran from a single location. A host that blocks some networks could look unreachable to us and work for others.
• One snapshot, on 2 October 2026. We cannot say how long any domain has been in testing mode.

The short version

• 58 of 1,359 major domains (4.3%) publish MTA-STS; only 28 enforce a working policy.
• Gmail, Outlook.com and Microsoft enforce it. Yahoo is in testing. AOL, iCloud and Yandex publish nothing.
• 7 of the 58 had broken policy hosts, which silently disables the protection.
• TLS-RPT is slightly more common (about 6%) and is the right first step.

Raw data: download the full dataset as CSV. It is free to reuse with a link back to this page.