Skip to main content
Security Auditor — looks up the TXT record at _smtp._tls.<domain> and checks that exactly one v=TLSRPTv1 record with a rua reporting address is published, as RFC 8460 requires.

Protection

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.

Standards

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.<domain> 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.<domain> 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 (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.

​
Output documentation

​
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.<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”.

​
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.