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
ruacontains 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=TLSRPTv1record.
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: trueWithout 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) ornone(gray), read fromhttps://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-stsrecord), Policy not reachable (the policy file cannot be downloaded) or Invalid policy (the file has noversion: STSv1or nomode).
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.