← RFC Reference

RFC 8460: SMTP TLS Reporting (TLSRPT)

Why This Exists

Two standards enforce TLS for server-to-server email: MTA-STS (RFC 8461) and DANE (RFC 7672). Both tell sending servers "you must establish a valid TLS connection before delivering mail to this domain." But when TLS negotiation fails, the sending server either falls back to cleartext (bad) or refuses delivery (mail lost). Either way, the receiving domain has no idea there is a problem.

TLSRPT closes this visibility gap. Domain owners publish a DNS record requesting TLS reports, and sending MTAs aggregate their TLS connection results into daily JSON reports delivered via email or HTTPS.

Without TLSRPT, you might deploy MTA-STS with a certificate error and not realize that a significant percentage of incoming mail is being rejected or delivered insecurely.

How It Works

Step 1: Publish a TLSRPT DNS Record

Add a TXT record at _smtp._tls.yourdomain.com specifying where reports should be sent:

Step 2: Sending Servers Collect Data

When a sending MTA delivers mail to your domain, it records the TLS negotiation outcome: successful session with valid certificate, failed handshake, certificate mismatch, MTA-STS policy failure, DANE validation failure, etc.

Step 3: Daily Report Delivery

Once per day, the sending MTA aggregates its results and sends a JSON report. When delivered via email, it arrives as a multipart/report message with report-type=tlsrpt:

Content-Type: multipart/report; report-type=tlsrpt;
    boundary="TLSRPT-001"

--TLSRPT-001
Content-Type: text/plain

SMTP TLS report for example.com
Report period: 2026-03-10T00:00:00Z to 2026-03-11T00:00:00Z

--TLSRPT-001
Content-Type: application/tlsrpt+json

{
  "organization-name": "Sender Corp",
  "date-range": {
    "start-datetime": "2026-03-10T00:00:00Z",
    "end-datetime": "2026-03-11T00:00:00Z"
  },
  "contact-info": "postmaster@sendercorp.com",
  "report-id": "2026-03-10-example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce",
        "mx: mail.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 9450,
      "total-failure-session-count": 12
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.example.com",
      "failed-session-count": 12
    }]
  }]
}

--TLSRPT-001--

Key Technical Details

DNS Record Format

Failure Result Types

Policy Types

Common Mistakes

• Publishing MTA-STS without TLSRPT. MTA-STS in enforce mode will cause sending servers to reject mail when TLS fails. Without TLSRPT, you have no visibility into those failures. Always deploy both together.
• Ignoring the reports. Receiving TLSRPT reports is only useful if you actually parse and monitor them. Set up automated processing or use a service that aggregates and alerts on failures.
• Using only HTTPS delivery. While HTTPS POST is cleaner for automated processing, some sending MTAs only support email delivery. Provide both a mailto: and https: URI if possible.
• Wrong DNS record location. The record must be at _smtp._tls.yourdomain.com, not _tls.yourdomain.com or _tlsrpt.yourdomain.com. The prefix is specifically _smtp._tls.
• Letting certificates expire. The single most common failure reported via TLSRPT is certificate-expired. Automate certificate renewal (e.g., with Let's Encrypt) and monitor expiry dates.
• Not checking MX hostname vs. certificate. Your TLS certificate must cover the hostnames listed in your MTA-STS policy and MX records. If your MX is mail.example.com but your certificate is for example.com, senders will report certificate-host-mismatch.

Deliverability Impact

• Visibility into TLS failures. Without TLSRPT, TLS negotiation failures are invisible. You do not know that mail from a major sender is being rejected because your certificate expired last week.
• Prerequisite for safe MTA-STS enforcement. The recommended deployment path is: publish MTA-STS in testing mode, enable TLSRPT, monitor reports for failures, fix issues, then switch to enforce. Skipping the monitoring step risks mail loss.
• Detecting man-in-the-middle attacks. A sudden spike in certificate-not-trusted or starttls-not-supported from a specific network could indicate a STARTTLS stripping attack. TLSRPT makes this visible.
• Compliance evidence. For domains handling sensitive communications, TLSRPT reports provide evidence that TLS is being successfully negotiated for the vast majority of inbound connections.

Related RFCs