Log inTry the sandbox free

Email authentication

TLS-RPT record generator

Build the _smtp._tls record that asks senders to report failed TLS to your mail hosts.

Free, no accountIn your browser

Comma-separated if more than one. A plain address is fine; "mailto:" is added for you.

Try

Result

No report destination yet

Fix the problems below before publishing this record.

  • Failed

    The record has nowhere to send reports

    RFC 8460 §3 marks "rua" as required - its ABNF says so outright - because a TLSRPT record exists for no other reason than to name where reports go. Published without one, it tells a sender nothing.

    Add the address reports should be mailed to.

  • Warning

    Reports arrive daily, as gzipped JSON, and something has to read them

    RFC 8460 §4.1 says a report should cover a full UTC day, §4 says the body is JSON (not XML, as a DMARC aggregate report is), and §5.2 says it should be gzip-compressed for both mail and HTTPS transport. Publishing this record starts a daily stream of attachments from every sender that implements TLSRPT, and a mailbox nobody opens is the usual outcome.

    Point this at a mailbox or alias someone or something actually reads, or an address at a reporting service, before publishing the record rather than after.

  • Info

    A report mailed to you must be DKIM-signed by the sender to count

    RFC 8460 §3 says a report delivered over SMTP must carry a valid DKIM signature by the reporting domain and that an unsigned one must be ignored, and that the reporting domain's DKIM record should declare the service type "s=tlsrpt". It also says a report must be delivered despite TLS failures, which may mean it arrives unencrypted - the report about broken TLS cannot wait for TLS to be fixed.

  • Info

    Publish this before an MTA-STS policy, not after

    MTA-STS testing mode is defined in RFC 8461 §5 as reporting a policy failure instead of refusing the message - but only to senders that also implement TLS reporting, and only when the recipient domain has published a TLSRPT record. Without this record, testing mode tells you nothing.

TLS-RPT record to publish

v=TLSRPTv1; rua=

At _smtp._tls (TXT)

Publish this at "_smtp._tls.<yourdomain>" - both labels, in that order - and not at the domain itself or at "_mta-sts".

  • This writes the record. It does not send a test report, open the endpoint or check that the mailbox exists, so a destination that is valid syntax and nowhere real reads as correct here.
  • How many reports a domain will actually receive is not in RFC 8460 and is not predicted here: it depends entirely on which senders implement TLS reporting, and no provider documentation was read for that.
  • RFC 8460 sets no limit on the number of rua destinations and no required status code for an https endpoint, so neither is checked. The only size figure in the RFC is an observation that a commonly seen receiver limit is ten megabytes, not a rule.

What this is

This TLS-RPT generator builds the one-line TXT record that asks sending servers to tell you when TLS to your mail hosts went wrong - the record you want in place before an MTA-STS policy, because it is what turns MTA-STS testing mode from a guess into a report.

SMTP TLS Reporting (RFC 8460) is a record at "_smtp._tls" under your domain holding a version and one or more destinations. A sending server that implements it collects what happened when it tried to deliver to you over TLS - which policy it applied, which host it connected to, how many sessions succeeded and how many failed, and why - and sends you that summary.

The destination can be an email address or an https URL, and nothing else: those are the two schemes the specification supports. An https endpoint is given the report as a POST; an address is mailed it, and a mailed report has to carry a DKIM signature from the reporting domain or you are required to ignore it.

How to read the result

The record is the whole output, and the findings are about what happens after it is published. The warning about volume is the one to read twice: this is a request for a daily attachment from every sender that implements reporting, and the usual failure is an address nobody has opened since the week it was set up.

A destination is checked for syntax only. A comma separates destinations in the record itself, so a comma, semicolon or exclamation point inside a URL has to be percent-encoded - which is also why a DMARC-style "!10m" size limit copied across from a rua tag is refused here rather than quietly published.

Common mistakes

What goes wrong most often, and how to tell.

  • Copying a DMARC rua value across, size limit and allThe two records look alike enough to invite it, but TLSRPT has no size-limit syntax: an exclamation point inside the URI has to be percent-encoded, so "!10m" makes the destination unparseable rather than smaller.
  • Publishing the record at the wrong nameIt goes at "_smtp._tls" under the domain - both labels, in that order. Put it at "_tls._smtp", at the apex, or alongside the MTA-STS record at "_mta-sts" and no sender will ever look there.
  • Expecting XML, like a DMARC aggregate reportA TLS report is JSON, gzip-compressed, named after the sender, the policy domain and the period it covers. Anything built to swallow DMARC XML will not read one, so the tooling question is worth answering before the first report arrives.
  • Publishing an MTA-STS testing policy with no TLS-RPT recordTesting mode reports a policy failure instead of refusing the message - but a report has nowhere to go unless this record exists, so the testing period passes quietly and tells you nothing before you switch to enforce.

Questions

What people ask about this tool.

  • It names where sending servers should send daily summaries of their TLS connections to your mail hosts, including the failures. Without it, a sender that could not negotiate TLS or could not match your MTA-STS policy has no way to tell you, and the problem is only visible to them.

  • Yes - the destinations are a comma-separated list, and RFC 8460 places no limit on how many you may name. A reporter may attempt delivery to each of them, and may also choose to deliver to only one, so a second destination is a backup rather than a second copy you can rely on.

  • JSON, compressed with gzip, covering a full UTC day and delivered after a delay of some hours. A mailed report comes as a multipart/report with the JSON as an application/tlsrpt+json or application/tlsrpt+gzip part; an https endpoint is POSTed the same body.

  • No, and the order is usually the other way round. A TLS-RPT record on its own already collects reports about TLS failures, which is exactly what you want to read before an MTA-STS policy starts asking senders to refuse delivery over anything else.

Sources

Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.

Use it from the API

The same check, as one request.

Request
curl -X POST https://resellerhq.com/api/tools/tls-rpt-generator \
  -H "Content-Type: application/json" \
  -d '{"method":"mailto","email":"[email protected]","endpoint":""}'
Response
{
  "tool": "tls-rpt-generator",
  "input": {
    "method": "mailto",
    "email": "[email protected]",
    "endpoint": ""
  },
  "result": {
    "verdict": {
      "tone": "warning",
      "headline": "Reports to mailto:[email protected]",
      "summary": "Publish the record below as a TXT record at \"_smtp._tls.\" plus the domain."
    },
    "findings": [
      {
        "id": "reports-need-somewhere-to-land",
        "severity": "warn",
        "title": "Reports arrive daily, as gzipped JSON, and something has to read them",
        "detail": "RFC 8460 §4.1 says a report should cover a full UTC day, §4 says the body is JSON (not XML, as a DMARC aggregate report is), and §5.2 says it should be gzip-compressed for both mail and HTTPS transport. Publishing this record starts a daily stream of attachments from every sender that implements TLSRPT, and a mailbox nobody opens is the usual outcome.",
        "fix": "Point this at a mailbox or alias someone or something actually reads, or an address at a reporting service, before publishing the record rather than after."
      },
      {
        "id": "mailto-dkim-notes",
        "severity": "info",
        "title": "A report mailed to you must be DKIM-signed by the sender to count",
        "detail": "RFC 8460 §3 says a report delivered over SMTP must carry a valid DKIM signature by the reporting domain and that an unsigned one must be ignored, and that the reporting domain's DKIM record should declare the service type \"s=tlsrpt\". It also says a report must be delivered despite TLS failures, which may mean it arrives unencrypted - the report about broken TLS cannot wait for TLS to be fixed."
      },
      {
        "id": "pairs-with-mta-sts-testing",
        "severity": "info",
        "title": "Publish this before an MTA-STS policy, not after",
        "detail": "MTA-STS testing mode is defined in RFC 8461 §5 as reporting a policy failure instead of refusing the message - but only to senders that also implement TLS reporting, and only when the recipient domain has published a TLSRPT record. Without this record, testing mode tells you nothing."
      }
    ],
    "parts": [
      {
        "kind": "record",
        "title": "TLS-RPT record to publish",
        "value": "v=TLSRPTv1; rua=mailto:[email protected]",
        "note": "Publish this at \"_smtp._tls.<yourdomain>\" - both labels, in that order - and not at the domain itself or at \"_mta-sts\".",
        "at": {
          "name": "_smtp._tls",
          "type": "TXT"
        }
      }
    ],
    "limits": [
      "This writes the record. It does not send a test report, open the endpoint or check that the mailbox exists, so a destination that is valid syntax and nowhere real reads as correct here.",
      "How many reports a domain will actually receive is not in RFC 8460 and is not predicted here: it depends entirely on which senders implement TLS reporting, and no provider documentation was read for that.",
      "RFC 8460 sets no limit on the number of rua destinations and no required status code for an https endpoint, so neither is checked. The only size figure in the RFC is an observation that a commonly seen receiver limit is ten megabytes, not a rule."
    ]
  }
}

Resell mailbox licences for the domains you just checked, under your own brand.

Get started

Company names and logos are trademarks of their owners, shown only to identify each service.