Validates TLS-RPT for email security monitoring
3 of 3 free audits left today
See what DNS Mail TLS-RPT finds on your site. No sign-up needed.
Domain — takes the hostname of the audited URL and strips one leading www.; https://www.example.com/page audits example.com. The audited page is never fetched.
Lookup — resolves the TXT records of _smtp._tls.<domain> with the system resolvers. A resolver failure (SERVFAIL, timeout) ends the audit with 500; a URL without a hostname ends it with 501.
Rules — no TXT record at all warns (300, TLS-RPT is optional). Every TXT record that does not start with v=TLSRPTv1 fails (400). More than one v=TLSRPTv1 record warns (301): RFC 8460 section 3 tells senders to ignore reporting then. A v=TLSRPTv1 record whose tag list (;-separated key=value pairs) has no rua tag fails (401).
Aggregate — FAIL wins over WARNING; when every rule passes the audit is SUCCESS (200) and the message names the record and its rua.
Specification pin — every run emits 37A-DnsMailTlsRptAuditor-100 (INFORMATION), naming RFC 8460 SMTP TLS Reporting (September 2018). It does not change the overall status.
Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. CheckCode suffixes use status ranges: 100 information, 200 success, 300–399 warning, 400–499 fail, 500–599 error.
| CheckCode | Status | When it fires | Recommendation | Why it matters |
|---|---|---|---|---|
37A-DnsMailTlsRptAuditor-100 | INFORMATION | Always. Records the specification this auditor implements (RFC 8460, 2018-09). | — (recommendation is null; nothing for the site to change) | — |
37A-DnsMailTlsRptAuditor-300 | WARNING | _smtp._tls.<domain> has no TXT record at all (NXDOMAIN, NODATA or an empty answer). | Publish a TXT record at "{fqdn}" such as "v=TLSRPTv1; rua=mailto:tls-reports@{domain}" so sending servers can report failed TLS connections to {domain}. | Without TLS-RPT you never hear about sending servers that fail to deliver mail to you over TLS, so a broken certificate or a downgrade attempt on your mail domain goes unnoticed. |
37A-DnsMailTlsRptAuditor-400 | FAIL | A TXT record at _smtp._tls.<domain> does not start with v=TLSRPTv1 (case-insensitive); one check per record. | Replace "{record}" at "{fqdn}" with a record that starts with "v=TLSRPTv1" and names a reporting address, for example "v=TLSRPTv1; rua=mailto:tls-reports@{domain}". | Sending servers ignore a record that does not start with the TLS-RPT version tag, so the domain receives no reports of failed TLS connections. |
37A-DnsMailTlsRptAuditor-301 | WARNING | More than one v=TLSRPTv1 TXT record is published at _smtp._tls.<domain>. | Keep exactly one "v=TLSRPTv1" TXT record at "{fqdn}" and remove the other {count - 1}; currently published: {records}. | Senders that find more than one TLS-RPT record drop reporting entirely, so the domain gets no failure reports even though a record is published. |
37A-DnsMailTlsRptAuditor-401 | FAIL | A v=TLSRPTv1 record has no rua tag, or an empty one, in its tag list; one check per record. | Add a rua tag to "{record}" at "{fqdn}", for example "v=TLSRPTv1; rua=mailto:tls-reports@{domain}". | The rua tag is where reports are sent; without it the record is unusable and failed TLS deliveries to the mail domain stay invisible. |
37A-DnsMailTlsRptAuditor-200 | SUCCESS | All rules passed: exactly one v=TLSRPTv1 record with a rua tag. Message names the record and its rua. | — | — |
37A-DnsMailTlsRptAuditor-500 | ERROR | The resolver could not answer the TXT lookup of _smtp._tls.<domain> (SERVFAIL, timeout). The record may well exist. | Check that the DNS zone answers TXT queries for "{fqdn}" (the resolver reported "{error}"), then run the audit again. | — |
37A-DnsMailTlsRptAuditor-501 | ERROR | The audited URL is null, blank, malformed or has no hostname, so there is no domain to look up. | Monitor a URL with a hostname, such as https://example.com/, instead of "{url}" ({reason}). | — |
| Status | Description | Test logic |
|---|---|---|
| SUCCESS | TLS-RPT is configured | Exactly one v=TLSRPTv1 record at _smtp._tls.<domain> with a non-empty rua tag (200). |
| WARNING | No reporting, or reporting is ignored | No TXT record at _smtp._tls.<domain> (300); more than one v=TLSRPTv1 record (301). |
| FAIL | The published record is unusable | A TXT record that does not start with v=TLSRPTv1 (400); a v=TLSRPTv1 record without a rua tag (401). |
| ERROR | The auditor could not look the record up | DNS lookup failure (500); URL without a hostname (501). |
| INFORMATION | Specification pin | Always emitted (100); does not change overall status. |
TLS-RPT is the feedback channel of MTA-STS and DANE: without it, a policy that blocks delivery because of an expired certificate or a wrong hostname produces silent bounces on the sender's side and nothing on yours.
Reports also reveal active downgrade attempts (STARTTLS stripping) against your mail domain.
It only reports; it does not enforce anything, so publishing a record carries no delivery risk.
The record lives at _smtp._tls.<domain>, not at the domain itself, and must start with v=TLSRPTv1.
rua takes one or more comma-separated URIs: mailto: addresses or https: endpoints that accept the JSON reports.
Publish exactly one record. RFC 8460 section 3 tells senders to treat more than one as "no record".
A record that does not start with v=TLSRPTv1 and a record without rua were WARNING; they are now FAIL (400, 401), because RFC 8460 requires rua.
A URL that is null, blank, malformed or has no hostname was FAIL; it is now ERROR (501): the site is not at fault.
A DNS resolver failure (SERVFAIL, timeout) was reported as "no record" (WARNING); it is now ERROR (500), so a resolver problem is not mistaken for a missing record.
More than one v=TLSRPTv1 record is a new WARNING (301); the old auditor read only the first record.
The rua tag is now parsed from the record's tag list instead of matched as a substring, so xrua= no longer counts.
The reporting URIs are not validated beyond being present: an unreachable https: endpoint or a mailbox that bounces is not detected.
The MTA-STS and DANE policies that TLS-RPT reports on are audited by their own auditors.
The domain is taken from the audited URL (minus one leading www.); mail for that domain may be handled by a different domain whose record is not checked.
This documentation is built and hosted on Mintlify, a developer documentation platform.
Add this auditor to your monitoring setup and start identifying issues on your websites today.