Skip to main content

TLS Reports

The TLS Reports page shows TLS-RPT data for inbound email delivered to your domain: how many delivery sessions negotiated TLS successfully, how many failed, and why. It is the feedback loop for Hosted MTA-STS — the evidence you use to decide whether it is safe to move a policy from Testing to Enforce.

Beta

TLS Reports is in beta. The page is available to anyone with domain read access, and carries a Beta badge in the app.

Where the Data Comes From​

TLS-RPT reports are not generated by Palisade. They are sent to you by the mail servers that deliver email to your domain — Google, Microsoft, and other large senders all report daily.

A sending server only reports if your domain tells it where to send reports. That happens when your domain publishes:

  • an MTA-STS policy, and
  • a TLS-RPT record — a TXT record at _smtp._tls.<yourdomain> naming the reporting address.

Palisade publishes and manages both when you enable Hosted MTA-STS. Reports then arrive on their own, and this page renders them.

note

Reports are aggregated daily by the sending server, not sent per message. After you first publish the records, expect 24 to 48 hours before anything appears here.

Getting There​

TLS Reports in the left-hand navigation opens the page. There is no organization-wide roll-up: the nav item drops you onto a single domain, choosing the one you last had selected elsewhere in the app, or the first domain in your list if you have not selected one. A domain picker at the top of the page switches between domains without leaving it.

If your organization has no domains yet, the page shows the Add or Import domains prompt instead.

What you cannot change

Everything on this page is fixed to the last 30 days. There is no date picker, no sorting, and no pagination — the Reports table always shows the 25 most recent reports, newest first.

Summary Cards​

Three cards across the top summarise the last 30 days:

  • Total Sessions — every reported delivery session, successful and failed combined.
  • Success Rate — successful sessions as a percentage of the total. This is the number to watch before enabling Enforce mode.
  • Failed Sessions — sessions where TLS could not be negotiated or validated. Shown in red whenever the count is above zero.

Large counts are abbreviated (1.2K, 45K, 1.3M).

Sessions Over Time​

A per-day bar for the last 30 days, each split green for successful sessions and red for failed ones, with the day's total on the right. Use it to tell a persistent problem from a one-off: a single red day is usually one misconfigured sender or a brief certificate lapse, while a red band that does not clear points at your own mail servers.

The panel is hidden when there is no data for the window.

Failure Breakdown​

A count of failed sessions grouped by the reason the sending server gave. The reasons Palisade labels:

Failure typeWhat it means
STARTTLS Not SupportedYour mail server did not offer STARTTLS, so the session fell back to plaintext.
Certificate Host MismatchThe certificate your server presented does not cover the MX hostname the sender connected to.
Certificate Not TrustedThe certificate chain does not resolve to a trusted root. Often a missing intermediate.
Certificate ExpiredThe certificate on your mail server is past its expiry date.
Validation FailureTLS validation failed for a reason the sender did not classify further.
STS Policy InvalidYour MTA-STS policy file could not be fetched or parsed.
STS WebPKI InvalidThe certificate on your mta-sts. policy host is not valid.
TLSA InvalidA DANE TLSA record did not match the presented certificate.
DNSSEC InvalidDNSSEC validation failed while resolving your domain.
DANE RequiredThe sender required DANE and your domain did not satisfy it.

Any failure type a sender reports that is not in this list is shown with its raw TLS-RPT name.

The panel is hidden when there are no failures, which is the healthy case.

Reports Table​

The 25 most recent reports, newest first:

ColumnDescription
DateThe day the report covers.
ReporterThe organization that sent the report, such as Google or Microsoft.
PolicyThe policy the sender applied: sts (your MTA-STS policy, shown green) or another type such as tlsa, shown neutral.
SuccessfulSessions that negotiated TLS successfully.
FailedSessions that failed, in red when above zero.

Empty States​

If the table is empty, the reason depends on the domain:

  • MTA-STS is configured, no reports yet. Nothing is wrong. Sending servers have not reported yet, which normally resolves within 24 to 48 hours of the records going live.
  • MTA-STS is not configured. No sender has been told to report on this domain, so no reports will ever arrive. The page links straight to Set up MTA-STS for the domain.

Using This Before Enforce Mode​

The safe rollout is:

  1. Enable Hosted MTA-STS in Testing mode.
  2. Wait for reports to appear here, then leave it running for at least a week.
  3. Confirm the success rate is at or near 100% and the Failure Breakdown panel is absent or explained.
  4. Only then switch the policy to Enforce.
warning

Switching to Enforce while failures are still showing here will cause those senders to stop delivering mail rather than fall back to plaintext. Testing mode exists precisely so this page can prove the switch is safe.