TLS Reports (TLS-RPT)

TLS reports (TLS-RPT, RFC 8460) tell you whether other mail servers could deliver email to your domain over an encrypted connection. Every day, providers such as Google and Microsoft count the TLS sessions they opened to your mail servers and report how many succeeded and why the others failed.

DMARC reports show who sends email as your domain. TLS reports show what happens when others send email to your domain.

RUA, RUF and TLS-RPT

RUA (Aggregate) RUF (Forensic) TLS-RPT
Standard RFC 9990 RFC 6591 RFC 8460
Format XML attachment AFRF email JSON attachment
Direction Email sent as your domain Email sent as your domain Email delivered to your domain
Frequency Daily Per failing message Daily
DNS record _dmarc _dmarc _smtp._tls

All three report types arrive in the same reporting mailbox. DMARC Examiner classifies and processes each type separately.

Publish the TLS-RPT record

Senders only send TLS reports if your domain publishes a _smtp._tls TXT record. DMARC Examiner shows the exact record in the domain detail, in the DNS tab, under TLS-RPT record:

Name Type Value
_smtp._tls.example.com TXT v=TLSRPTv1; rua=mailto:<your-reporting-address>

The address is the same one that the rua tag of your DMARC record uses. Copy the host and the value with the copy buttons, and create the record at your DNS provider.

The card also shows the status of the record that is published now:

  • Published with your address — The record exists and its rua contains your reporting address. If the record lists several addresses, it is enough that one of them is yours.
  • Published with another address — The record exists, but the reports go to other addresses. The card shows the current rua. Add your reporting address to it.
  • Not published — The domain has no v=TLSRPTv1 record.

The record is available on every plan. DMARC Examiner stores the TLS reports of all plans, also on Free.

Publish it with the mta-sts Helm chart

If you run Kubernetes, the mta-sts Helm chart serves your MTA-STS policy and publishes the _mta-sts and _smtp._tls records through external-dns. Set your reporting address in tlsRpt.rua:

domains:
  - name: example.com

policy:
  mode: testing
  mx:
    - mx1.example.com

tlsRpt:
  rua:
    - mailto:<your-reporting-address>

externalDns:
  enabled: true

Without external-dns, helm install prints the records to create.

MTA-STS card

The Overview of each domain has an MTA-STS card. It shows:

  • Policy mode — enforce (green), testing (amber) or none (gray), read from https://mta-sts.<domain>/.well-known/mta-sts.txt.
  • TLS success, last 7 days — The share of successful TLS sessions in the TLS reports of the last 7 days. On the Free plan the card shows an upgrade notice instead.
  • Errors — Not configured (no _mta-sts record), Policy not reachable (the policy file cannot be downloaded) or Invalid policy (the file has no version: STSv1 or no mode).

DMARC Examiner checks the policy every 6 hours. Click the refresh button to check it now. You can check each domain once a minute. Click the card to open the TLS tab.

Plan availability

TLS reports are available on Basic plan and above.

On the Free plan, DMARC Examiner still receives and stores the TLS reports of your domains. The TLS tab shows how many reports you have received and from how many senders, with an upgrade button. After you upgrade, the tab shows the reports received before, within the data retention of your plan.

Reading the TLS tab

Open a domain and click the TLS tab.

Period

Select Last 7 days, Last 30 days (default) or Last 90 days. If your plan keeps fewer days of data, the tab shows only those days and tells you so.

Summary and chart

  • Success rate — Successful sessions divided by all sessions in the period. With no sessions, the tab shows No sessions instead of 0% or 100%.
  • Successful sessions and Failed sessions — The totals of the period.
  • TLS sessions per day — Stacked bars with the successful sessions in green and the failed ones in red, by UTC day.

Senders

One row per organization that sent TLS reports, such as Google Inc. or Microsoft Corporation, with its reports, successful and failed sessions, success rate and last report. The senders with the most sessions come first.

Failures

One row per result type and receiving MX, with the failed sessions, the senders that reported them, the receiving IPs and the last time they were seen. The rows with the most failed sessions come first. If the sender did not report the MX, the row shows Not reported.

Result types

Each failure shows a readable name and the original RFC 8460 value.

Value Meaning
starttls-not-supported Your MX does not offer STARTTLS.
certificate-host-mismatch The certificate of your MX does not match its host name.
certificate-expired The certificate of your MX has expired.
certificate-not-trusted The certificate is not signed by a trusted authority.
validation-failure Another certificate validation error.
tlsa-invalid The DANE TLSA record is invalid.
dnssec-invalid The DNSSEC validation of the TLSA record failed.
dane-required The sender requires DANE and your domain has no valid TLSA record.
sts-policy-fetch-error The sender could not download your MTA-STS policy.
sts-policy-invalid Your MTA-STS policy has errors.
sts-webpki-invalid The certificate of mta-sts.<domain> is not valid.

A value that is not in this list appears as it came in the report.

TLS failure alert

On Basic plan and above, DMARC Examiner creates a TLS Failure alert when a TLS report shows a problem. See Alert System for the rules.