TLS-RPT record not published

The problem TLS-RPT exists to solve

SMTP encryption is opportunistic by design. STARTTLS was bolted onto a protocol that predates it, and it stayed backward compatible on purpose: a sending server offers to upgrade to TLS, and if the receiving server does not support it, the session continues in plaintext rather than failing. That kept mail working during the transition, but it created an obvious attack.

An on-path attacker can strip the STARTTLS advertisement out of the SMTP conversation. The sending server never learns encryption was available, falls back to plaintext, and delivers the message. Nothing errors. Nothing bounces. Both ends think it worked.

The receiving side cannot see any of this. A connection that got downgraded never reached you in the form you expected, and one that failed and got retried elsewhere leaves no trace in your logs at all. That asymmetry is the gap TLS-RPT fills. It moves the observation to the only party that can see it - the sending server - and gives that server a standard place to send what it saw.

What TLS-RPT is and is not

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a feedback mechanism. You publish a TXT record naming a destination, and cooperating sending servers deliver periodic aggregate reports describing how their TLS connections to your MX hosts went.

It enforces nothing. It will not stop a downgrade attack on its own, and publishing it does not make your mail more encrypted than it was yesterday. Enforcement is the job of MTA-STS (RFC 8461) or DANE for SMTP (RFC 7672). What TLS-RPT provides is the instrumentation those mechanisms otherwise lack.

TLS-RPT works standalone. You do not need MTA-STS or DANE first. When a sending server has no policy to evaluate for your domain, it reports the policy type as no-policy-found and still sends the success and failure counts. Deploy TLS-RPT alone, watch the data for a few weeks, and use that as the evidence base for whether an MTA-STS rollout is safe.

The deployment order that actually works

Most teams that get burned by MTA-STS get burned because they went to enforce mode without data. A policy in enforce mode tells senders to refuse delivery when TLS validation fails against your MX hosts. If one host has a certificate that does not cover its hostname, or a backup MX nobody has touched in three years is still in DNS with an expired cert, enforce mode turns a quiet misconfiguration into refused mail.

1. Publish TLS-RPT first. One TXT record, costs nothing, breaks nothing, starts producing data immediately.
2. Wait for reports and read them. Look for failures against hosts you did not expect, and for MX hosts showing up that you thought were decommissioned.
3. Deploy MTA-STS in testing mode. Senders evaluate the policy and report violations without changing delivery behaviour. Your TLS-RPT feed now shows exactly what enforce mode would have broken.
4. Move to enforce only when the reports are clean.

Skipping step one means doing step four blind.

What is in a report

Reports are JSON, covering a full UTC day. Each report identifies the reporting organisation, the date range, a report ID, and then one entry per policy evaluated. Each policy entry carries the policy type (sts, tlsa, or no-policy-found), the policy domain, the MX host pattern, and a summary with two counts: successful sessions and failed sessions.

RFC 8460 defines eleven result types. The key ones to know:

• starttls-not-supported - the MX did not offer STARTTLS at all. On a host you believe supports TLS, that is the signature of a stripping attack or a middlebox interfering.
• certificate-host-mismatch - the presented certificate did not cover the MX hostname.
• certificate-expired - self-explanatory, and depressingly common on backup MX hosts.
• certificate-not-trusted - untrusted CAs, chain problems, or name constraint failures.
• sts-policy-fetch-error - the sender could not retrieve your MTA-STS policy file.
• sts-webpki-invalid - the certificate on your MTA-STS web host failed validation. That expiry is separate from your mail server certificates.

How to publish the record

One TXT record at _smtp._tls under your domain:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

The v=TLSRPTv1 version tag has to come first, and rua is required. Both mailto: and https: destinations are supported, and you can list several separated by commas:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/v1/tlsrpt"

Two things that catch people out. Publish exactly one TLS-RPT record. If more than one TXT at that name starts with the version tag, senders treat your domain as not implementing TLS-RPT at all. Two valid records is not redundancy - it produces the same outcome as publishing none.

If your reporting URI contains a comma, semicolon, or exclamation point, percent-encode it. Commas separate URIs inside rua, so an unencoded one will split the URI unexpectedly.

Give the record a long TTL

TLS-RPT exists to help you detect downgrade attacks. An attacker capable of downgrading your mail transport is frequently also capable of interfering with DNS resolution - the cheapest way to blind you is to stop senders resolving the TLS-RPT record. A long TTL narrows the window in which a transient DNS attack can suppress discovery, because senders are working from cache. Signing the zone with DNSSEC addresses it more directly.

Where to send the reports

Point rua at something that parses JSON, not at a person. Reports arrive daily from every sender that supports the mechanism, and the large providers do. A human inbox fills with gzipped attachments nobody opens - functionally the same as not deploying it. Most teams reuse whatever service already handles their DMARC aggregate reports, since the operational shape is identical.

You will sometimes see advice to host the reporting mailbox on a separate domain so reports still arrive when your mail transport is broken. The spec handles the narrow version already: senders must deliver TLS-RPT reports even when TLS to your domain is failing, and must ignore MTA-STS and DANE failures while doing so. The broader argument still holds though - if your mail platform is down or misrouted, the reports explaining why should not be queued behind the same outage.

How this is rated

A missing TLS-RPT record is Informational with zero score impact. It is not a vulnerability - it is a blind spot. A domain with no TLS-RPT is in the same security position as every domain that deployed SMTP encryption before the mechanism existed. The finding is worth acting on, but DNSAudit will not drag your grade down for it.