> ## Documentation Index
> Fetch the complete documentation index at: https://docs.37audits.com/llms.txt
> Use this file to discover all available pages before exploring further.
# DNS Mail TLS-RPT
> Checks the SMTP TLS Reporting record that tells sending servers where to report failed TLS connections to your mail domain.
**Security Auditor** — looks up the TXT record at `_smtp._tls.` and checks that exactly one `v=TLSRPTv1` record with a `rua` reporting address is published, as RFC 8460 requires.
Tells you when sending servers cannot deliver mail to your domain over TLS, so a broken certificate or a downgrade attempt does not go unnoticed.
Follows RFC 8460 SMTP TLS Reporting (September 2018), the companion of MTA-STS and DANE.
SMTP TLS Reporting (TLS-RPT) lets mail servers that send to your domain tell you when the TLS handshake failed or when your MTA-STS or DANE policy could not be honored. Without it, a misconfigured certificate on your mail server or an attacker stripping TLS stays invisible until mail starts bouncing. The record is a single TXT entry at `_smtp._tls.` that names the address reports go to.
## How it works
1. **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.
2. **Lookup** — resolves the TXT records of `_smtp._tls.` with the system resolvers. A resolver failure (SERVFAIL, timeout) ends the audit with `500`; a URL without a hostname ends it with `501`.
3. **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`).
4. **Aggregate** — FAIL wins over WARNING; when every rule passes the audit is `SUCCESS` (`200`) and the message names the record and its `rua`.
5. **Specification pin** — every run emits `37A-DnsMailTlsRptAuditor-100` (`INFORMATION`), naming [RFC 8460 SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460) (September 2018). It does not change the overall status.
## What it audits
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.` 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.` 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.`. | 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.` (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/](https://example.com/), instead of "`{url}`" (`{reason}`). | — |
## Output documentation
| Status | Description | Test logic |
| - | - | - |
| **SUCCESS** | TLS-RPT is configured | Exactly one `v=TLSRPTv1` record at `_smtp._tls.` with a non-empty `rua` tag (`200`). |
| **WARNING** | No reporting, or reporting is ignored | No TXT record at `_smtp._tls.` (`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. |
## Risks and considerations
### Why TLS-RPT matters
* 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.
### Record format
* The record lives at `_smtp._tls.`, 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".
### Changes from the previous version of this auditor
* 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.
### What this auditor does not check
* 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](https://mintlify.com), a developer documentation platform.