The reports keep arriving. Google sends one every twenty-four hours. Microsoft too. Comcast, Yahoo, every major mail
operator that respects RFC 8460 is, right now, attempting to deliver a JSON document telling you whether their servers
successfully negotiated TLS with your mail infrastructure yesterday.
If you have nowhere to receive them, that telemetry hits a 404 and dies.
This is the silent failure mode of modern email security. You publish an MTA-STS policy. You add the TLSA records for
DANE. You feel good about it. Then you set the rua=mailto: field in your TLS-RPT DNS record and assume someone, somewhere,
is going to make sense of the bursts of zipped JSON now landing in your inbox at three in the morning.
Nobody is. Not unless you build the receiver yourself or pay an enterprise vendor four figures a year to do it for you.
The gap nobody talks about
MTA-STS and DANE are policy declarations. You’re telling the world that mail bound for your domain must be delivered over
TLS, must use specific certificates, must not be downgraded. What you don’t have, by default, is any way of knowing
whether those policies are being honoured.
TLS-RPT is the feedback channel. Without it you’re shouting requirements into the void and hoping for the best. With it
you find out, day by day, which sending infrastructure is failing your handshake and why — expired certificates on a
relay, an MX record pointing somewhere stale, a sender on an ancient TLS version, an STS policy that didn’t propagate.
The protocol is trivial. A receiver endpoint accepts POSTs of JSON reports, validates structure, stores them, and tells
you when something breaks. That’s it. The whole specification fits on a couple of pages.
So why does the market price this at hundreds of euros a month? Because the established vendors built their pricing around
organisations sending hundreds of thousands of emails a day, and a solo operator running their own mail looks identical
to them: same JSON, same volume of inbound reports, same dashboard, same bill.
What I built
A single Cloudflare Worker. Free plan. KV for storage. ZeptoMail for alert delivery — already in my stack for every plugin
I ship, so the marginal cost is essentially zero.
The worker accepts TLS-RPT reports at a POST endpoint, handles both raw JSON and gzipped payloads (the spec allows both,
and real-world senders use both), validates the report against the schema, and writes it to KV. When a report contains any
failure record — a policy mismatch, a certificate problem, a downgrade attempt — the worker formats an HTML email and
ships it via ZeptoMail.
Two read endpoints round it out. GET /summary aggregates every stored report by date with success and failure counts. GET
/report/YYYY-MM-DD returns the full detail for any day in the summary. No dashboard, no SaaS layer, no account system.
Curl the endpoints, or wire them into whatever monitoring you already run.
Set the rua field in your _smtp._tls TXT record to point at the worker URL and you’re done. Daily reports start arriving
within twenty-four hours. Failures generate email. Everything else sits silently in KV until you want to look at it.
Why this should be free infrastructure
The argument for paying enterprise money to a vendor is that they aggregate, dashboard, alert, and explain. Useful, if
you’re running a Fortune 500 mail estate and the dashboard is the product. Useless if you’re running mail for yourself and
four clients and what you actually need is an email when something breaks.
The technical work to receive a TLS-RPT report is smaller than most contact forms. The fact that no free open-source
receiver dominated this space for the small operator is a market failure, not a technical one.
There is no good reason a single-person WordPress agency hosting its own mail should be unable to close the TLS-RPT loop
without a Visa bill.
The repo is here. Fork it, deploy it, point your DNS at it: https://gitlab.com/littlebigco/tls-rpt