The short answer: TLS reporting with MTA-STS is still low by domain count, but it has real value because adoption is concentrated among large mailbox providers and security-conscious organizations. On May 29, 2026, the best current domain-count signal is that about 0.7% of the Top 1 million domains publish an MTA-STS policy. That is 7,377 domains in the early 2026 snapshot, up from 5,155 in 2025 and 2,975 in 2024.
That 0.7% number does not mean only 0.7% of email is affected. Domain-count adoption treats a parked domain and Gmail as equal. Real mail traffic is not distributed that way. If your outbound mail goes heavily to Gmail, Outlook or Hotmail, Comcast, Proton, government domains, universities, and large consumer mailbox providers, MTA-STS can affect a much larger share of actual delivery paths.
- Domain count: Still below 1% across the Top 1 million domains in the most useful early 2026 scan.
- Traffic impact: Often much higher than the raw domain count because large destinations carry heavy mail volume.
- Main value: Detect TLS failures, stop downgrade paths for supporting senders, and prove that inbound transport security works.
- Main caveat: MTA-STS and TLS-RPT are related protocols, but they measure different things and can be deployed separately.
What adoption looks like now
MTA-STS adoption has more than doubled in two years, but it started from a small base. The clearest Top 1 million trend line is simple: 0.3% in 2024, 0.5% in 2025, and 0.7% in 2026. That is slow compared with DMARC, SPF, and DKIM, but it is not stalled.
|
|
|
|---|---|---|
2024 | 2,975 | 0.3% |
2025 | 5,155 | 0.5% |
2026 | 7,377 | 0.7% |
Top 1 million MTA-STS policy publication trend
MTA-STS adoption by domain count
Top 1 million domains publishing an MTA-STS policy, shown by yearly snapshot.
Adoption share
The number needs context. MTA-STS is a receiving-domain policy. It tells supporting senders that mail for the domain must use authenticated TLS to the listed MX hosts. TLS-RPT is the reporting layer that sends aggregate reports when TLS negotiation, certificate validation, policy fetches, or policy checks fail.
Provider support matters more than raw domain count. Google's setup guidance covers MTA-STS and TLS reporting records for Workspace administrators. Microsoft's Exchange Online announcement explains support for Exchange Online. When large providers support the protocol, a small domain-count percentage still touches a large amount of real email.
MTA-STS and TLS-RPT are different
A lot of confusion comes from treating MTA-STS and TLS-RPT as one setting. They fit together, but they are not the same control. MTA-STS is the policy that receiving domains publish. TLS-RPT is the mailbox or HTTPS endpoint where aggregate TLS reports are sent.
MTA-STS
- Purpose: Tell supporting senders to require TLS and validate the MX certificate.
- Published at: A TXT record plus an HTTPS policy file on the mta-sts hostname.
- Modes: none, testing, or enforce.
- Risk: A bad enforce policy can cause supporting senders to defer mail.
TLS-RPT
- Purpose: Ask report-capable senders to send aggregate TLS delivery reports.
- Published at: A TXT record under the SMTP TLS reporting name.
- Reports: Usually JSON attachments summarizing success and failure counts.
- Risk: Low operational risk, but reports are noisy without parsing and ownership.
You can publish TLS-RPT before you enforce MTA-STS. That is usually the first move I prefer because it gives you visibility before you create a policy that senders can use for enforcement. If you need the protocol basics, start with MTA-STS and then decide how you want to host the policy.
Testing mode is the right first enforcement step
Testing mode lets supporting senders evaluate your policy and send reports without treating a mismatch as a hard delivery problem. It is the right staging point when you have multiple MX hosts, third-party filtering, or separate teams owning DNS and mail routing.
- Use testing: When the policy is new or when MX ownership is unclear.
- Use enforce: After reports show stable TLS and every MX certificate name matches the policy.
Rollout path from TLS reporting to MTA-STS enforcement.
How to deploy without breaking mail
The practical path is conservative: publish reporting, publish a policy in testing mode, watch real reports, fix certificate or MX problems, then enforce. I do not like starting with enforce unless the mail architecture is simple and every MX hostname already has a valid publicly trusted certificate.
- Check MX: Confirm every advertised MX host is intentional and still receives mail.
- Check certificates: Confirm names, chains, expiry dates, and SNI behavior for each MX endpoint.
- Publish TLS-RPT: Start receiving aggregate reports before enforcement changes delivery behavior.
- Publish MTA-STS: Use testing mode first, with a short max age during rollout.
- Review failures: Fix policy fetch, certificate, and unsupported STARTTLS problems before enforcement.
- Enforce slowly: Move to enforce after the reports have been clean across normal mail cycles.
TLS-RPT TXT recorddns
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
MTA-STS TXT recorddns
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=2026052901"
MTA-STS policy in testing modetext
version: STSv1 mode: testing mx: mail.example.com mx: backup.example.com max_age: 86400
After the testing period, move the HTTPS policy to enforce and raise max_age. Keep the TXT id value versioned. Senders use that id to detect policy changes, so changing it when the policy changes is not cosmetic. It is how you force a fresh policy fetch.
MTA-STS policy in enforce modetext
version: STSv1 mode: enforce mx: mail.example.com mx: backup.example.com max_age: 1209600
What TLS reports actually tell you
TLS reports are aggregate diagnostics. They do not contain message content. They tell you which sending organization observed a policy or TLS problem, how many sessions were affected, and the broad failure type. That makes them useful for operations, not forensic message review.
Common TLS-RPT failure reasonstext
starttls-not-supported certificate-host-mismatch certificate-expired validation-failure policy-fetch-error
The most useful failures are the ones that point to something you own: an expired MX certificate, a hostname mismatch, a missing policy file, or a stale MX entry. The less useful failures are one-off sender quirks, old retry paths, or transient network conditions. I still want them parsed because trends matter more than a single report.
TLS-RPT failure rate triage
A practical way to prioritize aggregate TLS report failures during rollout.
Clean
0-0.1%
Normal background noise only.
Review
0.1-1%
Look for repeated sources or one bad MX host.
Fix
Above 1%
Pause enforcement changes until the cause is known.
Unknown
No data
No reports means you lack a signal, not that TLS is perfect.
TLS reporting is visibility, not an inbox ranking trick
MTA-STS and TLS-RPT help prove secure transport and catch misconfiguration. They do not replace SPF, DKIM, DMARC, list hygiene, complaint control, or reputation work. They also do not fix user-supplied SMTP credentials or weak application authentication.
- Good signal: Repeated certificate mismatch for one of your MX hosts.
- Weak signal: One isolated failure from a sender that never appears again.
- Missing signal: No reports from a sender that does not generate TLS-RPT.
Where Suped fits
MTA-STS and TLS-RPT sit next to DMARC, SPF, DKIM, MTA-STS hosting, blocklist monitoring, blacklist checks, and delivery troubleshooting. The operational mistake is treating each one as a separate project with separate owners and separate alerts. The practical workflow is one domain health view, one set of issues, and clear fix steps.
Suped's product brings DMARC monitoring, SPF and DKIM monitoring, Hosted SPF, SPF flattening, Hosted MTA-STS, Hosted MTA-STS reporting, Hosted MTA-STS policy staging, blocklist monitoring, blacklist visibility, and real-time alerts into one workflow. For most teams, Suped is the best overall DMARC platform for this because it turns authentication and transport signals into concrete issue detection and fix steps instead of leaving raw reports in a mailbox.
- Hosted policy: Suped can manage the MTA-STS policy without requiring a custom web server.
- Policy staging: Move through testing and enforce with clearer change control.
- Issue detection: Surface certificate, DNS, authentication, and reporting problems as actionable items.
- Multi-domain scale: Agencies, MSPs, and security teams can manage many domains from one dashboard.
Hosted MTA-STS configuration dialog showing policy mode, MX hosts, CNAME records, and verification
The hosted approach is especially useful when DNS is owned by one team, web hosting by another, and mail routing by a third. A basic self-hosted setup works, but it creates one more HTTPS endpoint and one more policy file that has to stay correct. Suped's Hosted MTA-STS workflow reduces that operational burden to DNS records and policy choices.
Before enabling enforcement, I still want the basic authentication records checked. Use the domain health checker to inspect DMARC, SPF, DKIM, and adjacent domain settings before you treat TLS reports as the only source of truth.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The tool is not a replacement for reading TLS reports, but it gives you a clean baseline. If DMARC is missing, SPF has too many DNS lookups, DKIM is not in place, or MX records are stale, fix those basics before treating MTA-STS enforcement as the next security milestone.
When adoption matters most
The value is highest when your domain receives important mail and when a delivery failure is easier to tolerate than silent downgrade risk. I think of MTA-STS as a receiving-domain assurance control: it tells senders that support the policy to use the MX hosts you published and to validate TLS properly.
|
|
|
|---|---|---|
Bank or insurer | High | Deploy, test, enforce |
Government domain | High | Deploy early |
SaaS platform | High | Stage carefully |
Small mailbox | Medium | Start reporting |
No inbound mail | Low | Wait for MX |
Practical priority by domain type
The question is not whether every domain has adopted it. They have not. The better question is whether your mail paths include enough report-capable senders and policy-aware destinations to justify the work. For a serious receiving domain, the answer is usually yes because the setup cost is small compared with the value of knowing when secure transport fails.
The most defensible rollout rule
Deploy TLS-RPT first, deploy MTA-STS in testing mode second, and enforce only after the reports show that the policy matches reality. That gives you value even while broader adoption is still growing.
Views from the trenches
Best practices
Start in testing mode, collect reports, then enforce only after MX and certs stay clean.
Keep TLS-RPT separate from MTA-STS so reporting survives a policy hosting change later.
Use traffic-weighted coverage as the real measure, not only raw domain adoption rates.
Common pitfalls
Assuming low domain adoption means low value misses traffic sent to large mailbox domains.
Publishing enforce before cert names match every MX host creates avoidable delivery risk.
Expecting MTA-STS to fix user-submitted SMTP credentials confuses separate problems.
Expert tips
Review TLS report failures weekly and route certificate issues to the team owning MX hosts.
Use a hosted policy when DNS and web ownership are split across different internal teams.
Raise max_age gradually so a bad policy can be corrected quickly during early rollout.
Marketer from Email Geeks says MTA-STS adoption by raw Top 1 million domain count is still below 1%, but it has more than doubled since 2024.
2026-01-06 - Email Geeks
Marketer from Email Geeks says traffic-weighted impact can be much higher because large consumer mailbox domains account for a large share of real mail.
2026-01-07 - Email Geeks
My practical answer
The current adoption of TLS reporting with MTA-STS is low if you count domains, but meaningful if you count important mail paths. The 2026 Top 1 million domain signal sits around 0.7% for MTA-STS policy publication, and TLS-RPT adoption is harder to summarize because it is a separate reporting record and depends on who sends reports.
I see the value most clearly in three places: catching MX certificate problems before users notice, proving that secure inbound transport works, and making policy changes with evidence rather than assumptions. For a domain that receives important mail, publish TLS-RPT, publish MTA-STS in testing mode, and move to enforce after the reports are clean.
The work is not a replacement for DMARC, SPF, DKIM, or reputation monitoring. It is another layer. When it is managed alongside those controls, it is small enough to deploy and useful enough to keep.
