MTA-STS and TLS-RPT Records: The Forwarding Address Problem

On October 7, 2026, somebody asked a public resolver a dull question: what TXT record sits at _smtp._tls.ncsc.gov.uk?

The answer is a little odd.

The UK National Cyber Security Centre asks sending mail servers to deliver its TLS failure reports to Mail Check (Google Public DNS, queried 2026-10-07). Mail Check is the NCSC's own service. And the NCSC's own guidance page says this about it:

Mail Check no longer processes TLS reporting, so you will need to replace this with another appropriate email address.

— UK National Cyber Security Centre, “Using MTA-STS to protect the privacy of your emails”, August 18, 2021

In November 2025 the NCSC went further and announced it was retiring Mail Check altogether, telling organisations to have alternatives in place by 31 March 2026.

You might read that as an embarrassment. I'd read it as a useful example of what these two records are. They are public statements, written in DNS and on a web server where anyone can read them, and statements go stale.

Call it the old forwarding address problem. You file a change of address once, the office you named later closes, and the card on file still points there.

To see why that matters, and what else these records give away, start with the problem they were built to fix.

The hole in email encryption that MTA-STS plugs

Mail servers can encrypt their conversations with STARTTLS, but plain SMTP gives a receiving domain no way to tell senders to insist on it. That leaves room for downgrade attacks, and RFC 8460 puts the core difficulty plainly: they are not necessarily apparent to the receiving MTA. The receiving side may never know.

MTA-STS, published as RFC 8461 in September 2018, lets a receiving domain announce that it accepts TLS and tell senders whether to refuse delivery to any MX host that does not offer TLS with a trusted certificate. It does that in two pieces, and the split is the whole trick.

The first piece is a TXT record at _mta-sts.<domain>. It says almost nothing: a version and an id. Here is Gmail's, observed through Google Public DNS on 2026-10-07 (query):

The second piece is the actual policy, a plain text file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt. RFC 8461 section 3.2 defines four fields: version, mode (enforce, testing or none), one or more mx lines, and max_age in seconds, capped at 31,557,600, about a year. Gmail's file on the same day (live file):

The policy lives on a web server because MTA-STS rides on the web PKI, not DNSSEC. The RFC says so directly: DANE needs DNSSEC, while MTA-STS relies on certificate authorities, at a cost of risking malicious downgrades. The sender has to fetch the file from a host with a valid certificate for the mta-sts name. It has to get an HTTP 200, and it must not follow redirects.

Two TXT records and one text file make up the whole public surface of MTA-STS and TLS-RPT.

A record that looks like protection and isn't

Here is where intuition goes wrong. You would think the TXT record is the protection. It is closer to a sign on the door pointing at the protection, and if the room behind the door is empty, the RFC tells senders to carry on as if nothing were there:

If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.

— IETF / RFC Editor, “RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)”, September 2018

No error. No bounce. The protection just quietly isn't there. The same goes for a TXT record that is malformed or duplicated: if more than one v=STSv1 record exists, senders must assume there is no policy at all.

Then there is the id. It is 1 to 32 letters and digits, and its only job is to change. A sender holding a cached policy, the RFC says, need only check the TXT record's version 'id' against the cached value. Edit the policy file without changing the id and senders keep the old policy until max_age runs out, a point Microsoft Learn repeats in plain terms.

RFC 8461 section 8.1 adds an order of operations: update the file first, then the TXT id. Google tells admins to assign a new id every time the policy changes and suggests using the current date and time.

And the mx lines must actually match the domain's MX hosts. A wildcard covers exactly one label: *.example.com matches mail.example.com but not example.com or foo.bar.example.com. If you have read our piece on MX records, you can see how easily the two lists drift apart.

Three researchers, Ashiq, Fiebig and Chung, went and counted how often people get this wrong. Their IMC 2025 study scanned more than 87 million domains across four top-level domains over 31 months. Of the 68,000 domains with an MTA-STS record in their latest snapshot, 29.6% were misconfigured, and 3.2% should see delivery failures from senders that support MTA-STS. They also surveyed 117 mail operators. Almost all of them, 94.7%, knew what MTA-STS was. Nearly half, 48.8%, pointed to operational complexity.

The scan and the survey cover different groups, so together they don't prove a cause. But among the operators who answered, not knowing what MTA-STS was wasn't the problem. Complexity was the one they named.

Testing mode is not what it looks like either

If you scan a few big domains, you might be tempted to grade them. Gmail enforces. So does microsoft.com, whose policy file lists *.mail.protection.outlook.com with a max_age of 604800. Yahoo, on the same day, runs in testing mode. So does nhs.net.

That doesn't make Yahoo the laggard. In testing mode, senders that support TLS-RPT report failures but may still deliver. It is a monitoring stance, and the people who write the playbooks recommend starting there. Google tells admins to set testing mode first, with a max_age of one to two weeks. The NCSC suggests at least a month of testing before enforce. Microsoft documents switching back to testing, with a fresh id, as an incident mitigation that pauses enforcement while the reports keep coming. It is the same monitor-then-enforce arc as moving DMARC from p=none to reject.

Testing mode tells you where a domain is in a rollout, and not much more.

Enforce is where it gets real. In enforce mode, senders must not deliver to hosts that fail MX matching or certificate validation, or that lack STARTTLS. Exchange Online checks MTA-STS on all outbound mail with no admin action, and failures can come back as NDR 5.4.8 or 5.7.5. Gmail complies with enforced policies on outbound mail, after announcing it would begin enforcing in beta in April 2019. Microsoft also notes the limit of all this: mail is only blocked when both sides use MTA-STS and validation fails.

TLS-RPT: the record that tells you who is listening

MTA-STS has a companion, and RFC 8461 says outright that it is meant to be used with it. RFC 8460 defines TLS-RPT: a TXT record at _smtp._tls.<domain> that asks senders for a daily report on TLS failures. The record starts v=TLSRPTv1, and its rua field takes mailto: or https: destinations, comma-separated if there are several. Reports are gzip-compressed JSON covering a full UTC day, and they carry result types like starttls-not-supported, certificate-expired and sts-policy-fetch-error.

That last one is worth a moment. A domain whose policy file can't be retrieved has a result type made for exactly that failure. The reports are the smoke detector for everything in the section above.

But notice who reads the reports. The RFC explicitly allows destinations outside the domain, so a company can hand processing to a partner. Which means the rua value is a small public disclosure of who that partner is:

Gmail keeps reports in-house. Microsoft posts them to an HTTPS collector on Azure. Proton delegates the record by CNAME to another of its domains. When a commercial report processor is involved, its domain can show up in the address. URIports, for example, documents a customer format of rua=mailto:tlsrpt@account-subdomain.uriports.com (URIports). It is the same method we use to read SaaS vendors out of SPF and processors out of DMARC rua tags.

One caution: a third-party rua shows who processes TLS reports, not who runs the mail or security stack. And an HTTPS collector on a generic cloud host like azurewebsites.net may well be in-house.

Back to the NCSC: reading the whole chain

Now go back to the NCSC record. Its public artifacts, read together, say a good deal. Here are the key lines of its policy file, plus two DNS answers, all from 2026-10-07:

Line by line. The policy is in enforce mode with a two-week max_age, in line with the NCSC's own advice. The single mx line is a tenant-specific Exchange Online Protection host, so the mail service is Microsoft 365. (We cover that pattern in identifying an email gateway from MX records.) The policy host is a CNAME to Azure Static Web Apps, which is exactly the hosting Microsoft recommends, since Exchange Online won't host the file for its customers. And the reports go to Mail Check.

Three public answers, and you have a fairly detailed picture of a well-run setup with one stale line in it.

The NCSC is not alone. nhs.net lists the Mail Check address as its only TLS-RPT destination. hmrc.gov.uk lists it alongside its own tlsreporting@hmrc.gov.uk. One thing that may keep the address in circulation sits on GOV.UK. The page Set up government email services securely, last updated March 2024, still prints v=TLSRPTv1;rua=mailto:tls-rua@mailcheck.service.ncsc.gov.uk as the value to publish.

Be careful how far you take this. We don't know whether that mailbox bounces, and nothing here proves the reports are lost. The sourced fact is narrower: the NCSC says Mail Check no longer processes TLS reporting, and it told organisations to have alternatives to Mail Check in place by 31 March 2026. A stale rua also doesn't break mail, because reporting has no effect on delivery. What it costs is visibility, which is what TLS-RPT is for.

How to look these records up yourself

You need two DNS queries and one HTTPS fetch. With dig (our DNS lookup guide covers the basics, and the TXT lookup post covers the record type):

Then read what comes back against a short list:

• Exactly one record each. Two v=STSv1 records cancel the policy, and two v=TLSRPTv1 records cancel reporting.
• A file that actually loads. HTTP 200, a valid certificate for mta-sts.<domain>, no redirect. Otherwise senders without a cached copy deliver as if there were no MTA-STS.
• The mode. Testing is a stage in a rollout; enforce means blocking, but only by senders that support MTA-STS.
• mx lines against real MX records. Every MX host should match a pattern, and a wildcard covers one label only.
• The rua destination. Is it the organisation's own domain, a processor, or a service that has since been retired?

Whether the id changed after the last policy edit can't be read from a single lookup. Yahoo's id, for instance, is a timestamp from 2016, older than RFC 8461 itself. On its own, that proves nothing is wrong.

What these records can't tell you

A few honest limits. MTA-STS protects mail coming into the publishing domain, and only from senders that implement it, as Gmail and Exchange Online do. It says nothing about the domain's outbound mail. It is also trust-on-first-use: an attacker who can block DNS can hide the policy from a sender that has never cached it. DANE with DNSSEC avoids that, and 45.4% of the operators in the IMC survey said they preferred DANE.

And every observation in this post was made on 2026-10-07 and checked again on 2026-10-28, with identical results: the policy files were fetched over HTTPS, and the DNS answers came through one recursive resolver. Records change. That is rather the point.

Which brings us back to the NCSC. Its _smtp._tls line matches the value GOV.UK guidance still prints. The policy beside it enforces and matches the NCSC's own advice. None of that affects delivery. But the service behind one line stopped processing those reports, and the line stayed, which is what happens to any forwarding address nobody goes back to check. Somebody has to own these records after they are published.

Sources

1. RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) — IETF / RFC Editor, September 2018. rfc-editor.org
2. RFC 8460: SMTP TLS Reporting — IETF / RFC Editor, September 2018. rfc-editor.org
3. Enhance mail flow with MTA-STS — Microsoft Learn, July 21, 2026. learn.microsoft.com
4. About MTA-STS and TLS reporting — Google Workspace Admin Help, undated. knowledge.workspace.google.com
5. 2. Create an MTA-STS policy — Google Workspace Admin Help, undated. knowledge.workspace.google.com
6. 4. Turn on MTA-STS and TLS reporting — Google Workspace Admin Help, undated. knowledge.workspace.google.com
7. Gmail making email more secure with MTA-STS standard — Google Workspace Updates, April 10, 2019. workspaceupdates.googleblog.com
8. Unraveling the Complexities of MTA-STS Deployment and Management in Securing Email (Ashiq, Fiebig, Chung; IMC '25) — Virginia Tech VTechWorks (ACM IMC 2025), October 28, 2025. vtechworks.lib.vt.edu
9. Using MTA-STS to protect the privacy of your emails — UK National Cyber Security Centre, August 18, 2021. ncsc.gov.uk
10. NCSC to retire Web Check and Mail Check — UK National Cyber Security Centre, November 6, 2025. ncsc.gov.uk
11. Set up government email services securely — GOV.UK, March 4, 2024. gov.uk
12. Getting Started with DMARC and TLS-RPT — URIports, undated. uriports.com
13. gmail.com MTA-STS policy file (fetched 2026-10-07) — Google (live file), October 7, 2026. mta-sts.gmail.com
14. TXT _mta-sts.gmail.com via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
15. TXT _smtp._tls.gmail.com via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
16. microsoft.com MTA-STS policy file (fetched 2026-10-07) — Microsoft (live file), October 7, 2026. mta-sts.microsoft.com
17. TXT _smtp._tls.microsoft.com via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
18. yahoo.com MTA-STS policy file (fetched 2026-10-07) — Yahoo (live file), October 7, 2026. mta-sts.yahoo.com
19. TXT _mta-sts.yahoo.com via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
20. ncsc.gov.uk MTA-STS policy file (fetched 2026-10-07) — NCSC (live file), October 7, 2026. mta-sts.ncsc.gov.uk
21. TXT _smtp._tls.ncsc.gov.uk via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
22. CNAME mta-sts.ncsc.gov.uk via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
23. TXT _smtp._tls.nhs.net via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
24. nhs.net MTA-STS policy file (fetched 2026-10-07) — NHS (live file), October 7, 2026. mta-sts.nhs.net
25. TXT _smtp._tls.hmrc.gov.uk via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google
26. TXT _smtp._tls.proton.me via Google Public DNS (queried 2026-10-07) — Google Public DNS JSON API, October 7, 2026. dns.google

Share this article