What is TLS-RPT?

7 May 2026 · 12 min read

What is TLS-RPT and why does inbound email need it?

Most of the work that protects your domain happens at the application layer. SPF, DKIM and DMARC all decide whether a message is authentic once it has arrived. TLS-RPT sits one layer lower, at the transport, and answers a question those three cannot: was the connection that carried this mail actually encrypted, and if not, why not? That gap matters more than it sounds. A perfectly authenticated message can still be read or tampered with in transit if the sending server quietly fell back to a plaintext connection, and without TLS-RPT you would have no idea it ever happened.

TLS-RPT, short for SMTP TLS Reporting, is defined in RFC 8460. It is a small DNS record that asks other mail servers to send you a daily summary of how their connections to your inbound mail servers went, specifically whether STARTTLS succeeded, which policy they applied, and how many delivery attempts failed because encryption could not be negotiated. This article explains exactly what the record looks like, what a report contains, how to read one, and the concrete actions you take when the failures start rolling in. It is the natural companion to MTA-STS, so if you have already read about MTA-STS this fills in the missing feedback loop.

The transport problem TLS-RPT exists to expose

When one mail server delivers to another, it opens an SMTP connection on port 25 and, if both sides support it, upgrades that connection to TLS using a command called STARTTLS. The crucial and slightly alarming detail is that STARTTLS in classic SMTP is opportunistic. If the upgrade fails for any reason, the default behaviour is not to abort. It is to deliver the message anyway, in the clear.

That design made sense in the era when getting any encryption at all was a win, but it leaves two doors open:

• Silent downgrade. An active attacker sitting between the two servers can strip the STARTTLS announcement from the conversation, and the sending server will happily continue in plaintext, never knowing the upgrade was sabotaged. This is the classic downgrade attack.
• Silent misconfiguration. Your TLS certificate expires, or the wrong certificate is served, or a cipher mismatch occurs. The sending server cannot verify your identity, and depending on its policy it either delivers insecurely or, worse for you, defers and eventually bounces the mail. Either way you find out late, usually from an angry sender, not from your own monitoring.

MTA-STS addresses the first problem. It lets you publish a policy that says "connections to my mail servers MUST use TLS with a valid certificate, and if that is not possible, do not deliver." That closes the downgrade door. But it introduces a new risk: now a TLS problem does not just expose mail, it blocks it. You have turned a silent insecurity into a visible outage, and you need to see those failures the moment they start. That is precisely the job TLS-RPT does. The two are designed to be deployed together: MTA-STS enforces, TLS-RPT reports.

What the TLS-RPT record looks like

TLS-RPT is a single DNS TXT record published at a fixed, well-known location: the _smtp._tls subdomain of your domain.

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

There are only two tags you ever need to think about:

• v=TLSRPTv1 is the version identifier. It is mandatory and must come first. A record that does not begin with exactly this string is ignored.
• rua (report URI for aggregate reports) tells the world where to send the daily summaries. It is a comma-separated list of destinations.

The rua destination can be an email address or an HTTPS endpoint:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com
v=TLSRPTv1; rua=https://tlsrpt.example-monitor.com/v1/report
v=TLSRPTv1; rua=mailto:tls@yourdomain.com,https://tlsrpt.example-monitor.com/report

A mailto: destination receives reports as email attachments. An https: destination receives them as an HTTP POST, which most dedicated monitoring platforms prefer because it scales without cluttering a mailbox. You can list both, and reporters will try them in order.

Three things trip people up here, so they are worth stating plainly:

1. The record lives at _smtp._tls.<domain>, not at the apex and not at _dmarc. Mixing these up is the most common reason a record appears to do nothing.
2. The rua tag in TLS-RPT is not the same as the rua tag in DMARC. They share a name and nothing else. A DMARC rua collects authentication results; a TLS-RPT rua collects transport encryption results. Keep them in separate mailboxes so you do not confuse the two report formats.
3. TLS-RPT is purely a reporting mechanism. Publishing it changes nothing about how mail is delivered. It does not enforce TLS, it does not block anything, it cannot cause an outage. It only switches on a feedback stream. That makes it completely safe to publish first, before you ever touch MTA-STS.

The TLS-RPT report: JSON, not XML

If you have wrestled with DMARC aggregate reports you will be relieved to hear that TLS-RPT reports are JSON, not the gzipped XML that DMARC uses. They are sent once per day per reporting organisation, covering a 24-hour window, and they are usually compressed with gzip and given a .json.gz extension.

A trimmed report looks like this:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-06-21T00:00:00Z",
    "end-datetime": "2026-06-21T23:59:59Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-06-21T00:00:00Z_yourdomain.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "yourdomain.com",
        "mx-host": ["*.mail.yourdomain.com"]
      },
      "summary": {
        "total-successful-session-count": 5821,
        "total-failure-session-count": 14
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "203.0.113.9",
          "receiving-mx-hostname": "mx1.yourdomain.com",
          "failed-session-count": 14
        }
      ]
    }
  ]
}

Read it from the top down and it tells a complete story:

• Who is reporting. organization-name and contact-info identify the sending side, usually a large mailbox provider such as Google, Microsoft or a corporate gateway.
• The window. date-range is the 24-hour period the report covers.
• The policy they saw. policy-type is one of sts (they found and applied your MTA-STS policy), tlsa (they used DANE, which relies on DNSSEC and a TLSA record), or no-policy-found (neither was present, so they used plain opportunistic TLS).
• The summary. Two counts that are the headline numbers you watch every day: how many sessions succeeded and how many failed.
• The failures, itemised. For every distinct failure type, the report names the result type, the sending IP, the receiving MX hostname that had the problem, and the count. This is the part that turns "something is wrong" into "mx1 served an expired certificate to 14 sessions from this IP".

Decoding the failure result types

The value of TLS-RPT is in the result-type field, because each value points to a specific, fixable cause. These are the ones you will actually encounter:

• certificate-expired is exactly what it says. The certificate on the named MX host has passed its expiry date. This is the single most common TLS-RPT failure and the easiest to fix, and it is almost always an automation gap rather than a one-off.
• certificate-not-trusted means the certificate chain does not lead to a trusted root, or an intermediate certificate is missing from what your server presents. Browsers are forgiving about missing intermediates because they fetch them; mail servers usually are not.
• certificate-host-mismatch means the name on the certificate does not match the MX hostname the sender connected to. Common after a migration where the MX record points at a host the certificate was never issued for.
• validation-failure is a catch-all for a TLS handshake that failed for a reason the reporter could not classify more precisely, including cipher or protocol-version mismatches.
• sts-policy-fetch-error and sts-policy-invalid are MTA-STS-specific. The sender found your TLS-RPT or DNS record telling them you have an STS policy, but could not fetch the policy file over HTTPS, or fetched it and found it malformed. This points at your mta-sts.<domain> web host or the policy file itself, not at your mail server's certificate.
• sts-webpki-invalid means the certificate on the policy web host (the one serving https://mta-sts.yourdomain.com/.well-known/mta-sts.txt) is itself untrusted. A subtle one, because the mail server can be perfectly healthy while the policy host is broken.
• starttls-not-supported means the receiving MX did not offer STARTTLS at all, or it was stripped in transit. On a domain that publishes an STS policy this is the signature of a downgrade attempt or a server that has lost its TLS configuration entirely.

Each of these maps to an owner and an action. Certificate types are a job for whoever manages your mail server certificates. The sts-* types are a job for whoever manages the MTA-STS policy host and DNS. Splitting them this way is how you turn a daily JSON file into a short, assignable to-do list.

What to actually do with the reports

Receiving reports is not the point. Acting on them is. Here is the workflow that turns TLS-RPT from a curiosity into a genuine safety net.

1. Publish the record first, in monitoring mode

Before you enforce anything with MTA-STS, publish the TLS-RPT record on its own and leave it for a couple of weeks. Because it changes nothing about delivery, this is risk-free. You will start receiving reports that establish a baseline: your normal success volume, which providers report on you, and any failures that already exist. Discovering that 0.3% of sessions already fail on an expired certificate before you switch MTA-STS to enforce mode is exactly the kind of thing that prevents a self-inflicted outage. Pair this with the MTA-STS checker to confirm your policy host and record are healthy at the same time.

2. Read the first few reports manually

The first time you receive a report, open it and read the whole thing. Confirm the success counts look like your real inbound volume, confirm the reporting organisations are the big providers you expect, and confirm any failures are ones you understand. This calibration step is worth doing by hand even though you will automate it later, because it teaches you what "normal" looks like for your specific domain.

3. Triage failures by result type, not by count

A small absolute failure count can still be a five-alarm fire. Fourteen certificate-expired failures might be the leading edge of a certificate that expired an hour ago and will take down all inbound mail within the renewal window if MTA-STS is enforcing. Always look at the result type first and the count second. Group the day's failures by result-type and receiving-mx-hostname, and you will see immediately whether it is one host with one problem or a systemic issue.

4. Fix the cause, then confirm in the next report

Because reports arrive daily, they give you a built-in verification loop. Renew the expired certificate today, and tomorrow's report from the same provider should show the certificate-expired count drop to zero and the success count rise to absorb it. If it does not, the fix did not take, or there is a second host with the same problem. Never close a TLS-RPT issue until a subsequent report confirms the failure type is gone.

5. Automate the boring parts

Reading JSON by hand does not scale past the first week. A busy domain receives reports from dozens of organisations every day. The sustainable pattern is to send the rua stream to a system that parses every report, tracks success and failure rates over time, and alerts you the moment a new failure type appears or a rate crosses a threshold. That is the same principle behind ongoing DMARC monitoring: the standard gives you the data, but you need something to ingest it continuously and tell you when something changed. Our monitoring does this for the authentication side, and a complete email-security posture treats transport reporting the same way.

How TLS-RPT fits with MTA-STS, DANE and your wider setup

It helps to see where TLS-RPT sits in the family of transport-security controls, because each one does a distinct job and they are strongest together.

• STARTTLS is the opportunistic upgrade that may or may not happen. It is the thing being measured.
• MTA-STS turns "may" into "must" using a policy published over DNS and HTTPS, so senders refuse to deliver to you without valid TLS. It is the enforcement.
• DANE does the same enforcement using TLSA records anchored in DNSSEC, an alternative route to the same goal that does not depend on the public certificate authority system.
• TLS-RPT is the feedback for whichever of those you deploy. It reports on STS policies, DANE/TLSA validation, and plain opportunistic TLS alike.

The recommended order of operations is deliberate. Publish TLS-RPT first and watch. Then publish an MTA-STS policy in testing mode, which (like TLS-RPT) enforces nothing but causes reporters to start exercising your policy and certificates and to flag problems in the TLS-RPT stream. Only once a run of clean reports confirms every MX host presents a valid, trusted, correctly-named certificate do you move MTA-STS to enforce. At that point TLS-RPT stops being a setup tool and becomes a permanent tripwire: the thing that pages you the day a certificate renewal silently fails, before your senders start bouncing.

This is the same philosophy that runs through the rest of email authentication. You do not flip a domain to p=reject on day one; you publish, you collect aggregate reports, you fix every legitimate source, and only then do you enforce. TLS-RPT is the transport-layer version of that exact discipline. It lets you tighten encryption requirements with eyes open rather than crossed fingers.

A worked example: from publish to enforce

Walking through a realistic sequence makes the abstract concrete.

You manage yourdomain.com with two inbound MX hosts, mx1 and mx2. You publish:

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

For a fortnight, reports arrive and show roughly 6,000 successful sessions a day across the big providers and zero failures. Good baseline. You then publish an MTA-STS policy in testing mode and the next day's report from Microsoft shows something new: 31 certificate-host-mismatch failures, all on mx2. Investigation shows mx2 was rebuilt last quarter and is serving a certificate issued only for mx1. Nobody noticed because opportunistic TLS does not check the hostname strictly, so mail kept flowing in the clear. Had you skipped straight to MTA-STS enforce, those 31 sessions a day would have been deferred and bounced, and you would have learned about it from senders, not reports.

You reissue the certificate for mx2 with both hostnames as subject alternative names. The next report shows the mismatch count at zero and the success count higher to match. You let two more clean days pass, then switch MTA-STS to enforce. TLS-RPT keeps running in the background. Six months later it catches an automated renewal that silently failed on mx1, surfacing a single certificate-expired failure on the very first day, hours before the certificate would have taken inbound mail down. You renew, confirm zero in the following report, and nobody outside the team ever knows there was a problem.

That is the whole value proposition in one story: TLS-RPT converts invisible transport problems into a dated, itemised, daily list you can act on, and it does it without ever putting your mail flow at risk.

The practical takeaway

TLS-RPT is one of the cheapest wins in email security. It is a single safe-to-publish TXT record, it cannot break delivery, and it gives you a daily, machine-readable account of whether the connections carrying your inbound mail are actually encrypted and trusted. Publish it first, read the early reports by hand to learn your baseline, triage failures by result type rather than raw count, fix the cause, and confirm the fix in the next day's report. Then deploy MTA-STS on top with confidence, knowing TLS-RPT will tell you the moment a certificate or policy goes wrong.

If you want to confirm your current transport setup before you start, run your domain through the MTA-STS checker and browse the rest of the free tools. And if you would rather not hand-roll the record, the policy host and the daily report parsing yourself, our done-for-you platform sets up MTA-STS, publishes TLS-RPT, ingests every report and alerts you on any change, so the whole transport-security loop runs itself.