RFC 8460 — TLS-RPT

RFC 8460 defines TLS reporting, the feedback channel for MTA-STS and DANE. It is to transport security what aggregate reports are to DMARC: without it, you publish a policy and have no idea whether it is working.

How it works

Publish a TXT record at _smtp._tls.yourdomain.com naming where reports should go:

v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com

Sending servers then deliver a daily JSON report summarising their TLS sessions with your MX hosts — how many succeeded, how many failed, and the failure type for each.

Why it is worth publishing before you enforce

The failure types are the useful part. They distinguish a certificate that does not match the MX hostname from an expired one, from a policy fetch that failed, from a sender that could not negotiate TLS at all.

That is precisely the information you need before switching MTA-STS from testing to enforce — and it is the only way to see failures that happen at someone else’s sending server rather than yours.

TLS-RPT is cheap: one DNS record, no policy file, and nothing breaks if you get it wrong.

What a report looks like

A daily JSON document per sending organisation, summarising sessions with your MX hosts:

{
  "organization-name": "Example Sender",
  "date-range": { "start-datetime": "...", "end-datetime": "..." },
  "policies": [{
    "summary": { "total-successful-session-count": 1041,
                 "total-failure-session-count": 3 },
    "failure-details": [{ "result-type": "certificate-host-mismatch",
                          "failed-session-count": 3 }]
  }]
}

The result-type is what makes it actionable — certificate-expired, certificate-host-mismatch, starttls-not-supported, validation-failure and others each point at a different fix.

Why publish it even without MTA-STS

TLS-RPT works on its own. You do not need a policy in force to receive reports; you only need the DNS record. That makes it the cheapest possible way to find out whether mail to your domain is actually arriving encrypted, and whether any sender is failing to negotiate TLS with you at all — before you commit to enforcing anything.

The reporting address

rua= in a TLS-RPT record accepts mailto: or https:. A mailbox is the usual choice, and the same caution applies as with DMARC aggregate reports: point it somewhere that can absorb daily mail from every organisation that sends to you, not a personal inbox.

Reports are gzipped JSON attachments, one per sender per day. For a domain with any volume that is a steady trickle, and reading them by hand stops scaling almost immediately — which is the same argument for collecting them the way DMARC Analyzer collects aggregate reports, on your own infrastructure.

Unlike MTA-STS there is no policy file, no max_age, and no failure mode where getting it wrong stops mail. The worst case is that reports go nowhere.

Read it: rfc-editor.org/rfc/rfc8460