Skip to content
correct.email
correct.email

TLS-RPT record checker

Checks the _smtp._tls record that tells sending servers where to report TLS problems with your mail servers — the feedback loop for MTA-STS and DANE.

A domain such as example.com. You can paste a URL or an email address.

How this check works

We query the TXT record at _smtp._tls.<domain>. Records that do not begin with “v=TLSRPTv1;” are ignored, and exactly one must remain (RFC 8460, section 3).

The rua field can list several destinations separated by commas. Only mailto: and https: are allowed; we validate each address and host name.

Limitations

  • We cannot tell whether reports actually arrive or whether the mailbox or endpoint accepts them.
  • TLS-RPT only reports problems; it does not change how mail is delivered.
  • Checked domains are not stored or logged.

Frequently asked questions

What does a TLS report contain?

A daily JSON summary from a sending organization: how many sessions negotiated TLS successfully, how many failed, and why — for example a certificate problem or a policy that could not be fetched (RFC 8460, section 4).

Do I need TLS-RPT without MTA-STS?

It is most useful together with MTA-STS or DANE, because those turn TLS failures into delivery failures. Without them, reports still show senders that could not negotiate TLS with you.

Can reports go to another domain?

Yes. Unlike DMARC, TLS-RPT has no authorization record for external destinations; any valid mailto: or https: destination works.

Why haven’t I received any reports?

Reports cover a full day and come only from senders that implement TLS-RPT and sent you mail that day. Expect the first report a day or two after publishing the record.