What is TLS reporting? Knowing your encryption actually works

Ask any IT supplier whether a business’s email is encrypted in transit and the answer will be yes - “we use TLS.” It is almost certainly true. It is also, on its own, close to meaningless.

Transport Layer Security (TLS) protects email between mail servers only when both ends of each delivery achieve an encrypted connection - and for any given message arriving at your domain, whether that happened depends on configuration, certificates, network conditions and, in the worst case, an attacker interfering en route. Your own server’s logs show your side of the story. They cannot show you the deliveries that other servers attempted, failed to encrypt, or abandoned.

SMTP TLS Reporting (TLS-RPT) exists to close exactly that blind spot. It is the simplest of the email security standards to adopt - one DNS record - and the National Cyber Security Centre (NCSC) recommends it alongside MTA-STS for UK organisations.

What TLS-RPT is

TLS-RPT is a published address. You add a single record to your domain’s DNS saying, in effect: if you send email to this domain, please report your encryption results here. Participating providers - including Google and Microsoft, which between them attempt delivery to almost every business domain daily - then compile a report every 24 hours describing their attempts to deliver mail to you securely:

• how many connections to your mail servers were successfully encrypted;
• how many failed to achieve encryption, and why - an expired or mismatched certificate, a server refusing modern encryption protocols, an unreachable MTA-STS policy file, or a policy mismatch;
• which of your mail servers each result related to.

Like DMARC’s aggregate reports, TLS-RPT reports contain no message content, no subject lines and no personal data - only counts and technical reasons. They are statistics about the security of the pipe, not about what flowed through it.

Why “we use TLS” is not the same as knowing it works

Three gaps make outbound confidence about inbound reality misplaced:

Failures happen at the other end’s discretion, silently. When a sending server cannot establish encryption with yours, what happens next is its choice. Most fall back to delivering unencrypted (so mail arrives, and nothing appears wrong); some defer or give up (so mail is delayed or lost, and the sender’s users blame you). Either way, nothing on your side flags it.

Certificates expire quietly. A mail server certificate that lapsed last Tuesday does not stop mail flowing - it stops mail flowing securely, while everything looks normal. TLS-RPT reports surface this within a day; without them, the usual discovery mechanism is an auditor, or never.

Downgrade attacks are designed to be invisible. As we covered in What is MTA-STS?, an attacker between two servers can strip the encryption offer so both sides politely converse in plain text. Neither server errors. TLS-RPT is the standard most likely to reveal the fingerprints - a pattern of unexplained encryption failures from senders who normally succeed.

What the reports show - and what an anomaly looks like

A healthy TLS-RPT week is gloriously boring: every report says every connection succeeded. The value is in the exceptions, and they have recognisable shapes:

• A sudden cluster of certificate failures from all senders - your mail server’s certificate has expired or been misissued. Fix today.
• Failures from one provider only - often a configuration mismatch specific to that sender’s requirements; worth investigating before their users’ mail starts deferring.
• “Policy not found” or policy-fetch failures - your MTA-STS policy file or its certificate has broken; if your policy is in enforce mode, legitimate inbound mail may already be refused.
• A low, persistent rate of negotiation failures from unexpected networks - sometimes harmless legacy servers; occasionally something that warrants attention. Context and history are what tell the difference.

This is also why TLS-RPT and MTA-STS belong together: TLS-RPT is the evidence stream that lets you run MTA-STS in testing mode safely, confirm the world can comply with your policy, and then keep watch once you enforce it. One without the other is either rules without eyes or eyes without rules.

The honest practicalities

Adoption is one DNS record and costs nothing. The real cost is the same as DMARC’s: the reports arrive daily, as JSON attachments designed for machines, and somebody has to read them - every day, indefinitely, mostly to confirm nothing is wrong, and to notice promptly when something is. That is a monitoring discipline, not a setup task.

For SealedMail subscribers, TLS-RPT reporting is part of the core service: your reports come to our infrastructure alongside your DMARC data, and anything anomalous is flagged and explained in the same weekly plain-English email - what happened, what it means, whether anything needs doing. The encryption findings also feed your weekly domain health check, alongside the authentication picture covered in What is DMARC?.

See your starting position

Whether your domain publishes a TLS-RPT record - and whether MTA-STS is present, absent or broken - takes two minutes to establish. SealedMail’s Free Domain Health Check covers both, alongside SPF, DKIM, DMARC, BIMI and blacklist status, delivered as a scored, plain-English certificate by email. Free, no sign-up, no sales call.