All help articles

SMTP TLS reports

Mail between servers is encrypted with TLS when both sides support it. When your domain asks senders to insist on TLS (with MTA-STS (see Set up DNS) or DANE), a problem on the receiving side, such as an expired certificate, means mail to you is delayed or bounced. SMTP TLS reporting (TLS-RPT, RFC 8460) lets senders tell you: providers such as Google and Microsoft send a daily report of how many deliveries to your domain worked over TLS, how many failed, and why.

Mailocity collects these reports for you, so a problem shows up in the panel before your correspondents notice it.

How it works

Collection is on for every domain by default (tlsRptCollect, the Collect SMTP TLS reports box in the domain's Mail settings).

1. Your DNS records include a TXT record at _smtp._tls.<your-domain>: v=TLSRPTv1; rua=mailto:tls-reports@<your-domain>. Domains on automatic DNS publish it at the next sync; add it by hand otherwise. It is optional: mail works without it.
2. Reports sent to tls-reports@<your-domain> (gzip or plain JSON) are read when they arrive and stored against your domain for 180 days. They are not delivered to a mailbox.
3. Only the parts of a report about your domain or its subdomains are kept. A report about any other domain is refused, so nobody can push reports into another customer's domain.
4. Each report records whether its own email passed DMARC (senderVerified). Treat an unverified report with suspicion, since anyone can send one.

The TLS reports card on the domain's page lists the reports with their success and failure counts. Choose one to see each policy and the failures by type, sending and receiving server.

If you would rather read the raw report emails, create a mailbox or alias called tls-reports on the domain: it then gets the mail like any other address, and nothing is stored. To stop collecting, untick the box (or set tlsRptCollect to false) and remove the _smtp._tls record.

Reading a report

• sts, tlsa or no-policy-found: the policy the sender applied: MTA-STS, DANE, or none.
• Common failures: certificate-expired, certificate-host-mismatch (the certificate does not name the MX host), starttls-not-supported (the sender could not start TLS: often a firewall or middlebox in between), sts-policy-fetch-error (the MTA-STS policy file could not be fetched), validation-failure.
• A few failures from one sending address are usually that sender's network. Failures from many senders mean something on the receiving side needs fixing.

API

• GET /v1/tenants/{tenantId}/domains/{domain}/tls-reports and .../tls-reports/{reportId} for a tenant's domain.
• GET /v1/shared-domains/{domain}/tls-reports and .../tls-reports/{reportId} for a shared domain.

See also DMARC reports, the daily reports about who sends mail as your domain.