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.
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.
When you enable Hosted MTA-STS, Palisade hosts and manages the MTA-STS policy. The TLS-RPT record is yours to publish: the Hosted MTA-STS page shows it in its TLS Reporting (TLS-RPT) panel, and you add it at your DNS provider, by hand or with the page's automated setup. Once both are live, reports arrive on their own, and this page renders them.
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, which is available to anyone with domain read access. 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.
A date range picker sits opposite the domain picker. It defaults to the last 30 days ending yesterday, and offers presets (7, 14, 30 and 60 days, this month, last month), a calendar, start and end fields, and a free-text box that accepts relative ranges such as 7d or 3 months. Two limits apply: the range cannot start more than 61 days ago, and it cannot end later than yesterday, because a report covers a full day and today's has not been sent yet. The range is held in the page URL, so it survives a reload and can be shared as a link.
Nothing else is adjustable. The Reporters table has no sortable columns and no pager: it is always ordered by session count, busiest reporter first. Paging happens behind the scenes instead, with the page fetching every report in the range, up to a ceiling of 2,000. Beyond that a warning appears above the table and the figures cover only the reports that were fetched, which is the cue to narrow the range.
Summary Cards
Three cards across the top summarise the selected range:
- 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 selected range, 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 type | What it means |
|---|---|
| STARTTLS Not Supported | Your mail server did not offer STARTTLS, so the session fell back to plaintext. |
| Certificate Host Mismatch | The certificate your server presented does not cover the MX hostname the sender connected to. |
| Certificate Not Trusted | The certificate chain does not resolve to a trusted root. Often a missing intermediate. |
| Certificate Expired | The certificate on your mail server is past its expiry date. |
| Validation Failure | TLS validation failed for a reason the sender did not classify further. |
| STS Policy Invalid | Your MTA-STS policy file could not be fetched or parsed. |
| STS WebPKI Invalid | The certificate on your mta-sts. policy host is not valid. |
| TLSA Invalid | A DANE TLSA record did not match the presented certificate. |
| DNSSEC Invalid | DNSSEC validation failed while resolving your domain. |
| DANE Required | The 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.
Reporters Table
One row per reporting organization, covering the whole selected range, ordered by session count with the busiest reporter first:
| Column | Description |
|---|---|
| Reporter | The organization that sent the reports, such as Google or Microsoft. |
| Policy | The policy the sender applied: sts (your MTA-STS policy, shown green) or another type such as tlsa, shown neutral. |
| Sessions | Every session that reporter saw, successful and failed combined. |
| Failed | Sessions that failed, in red when above zero. |
| Success rate | Successful sessions as a percentage of that reporter's total. Shown as -- when the reporter logged no sessions at all. |
Individual daily reports are not listed. Each reporter's rows are rolled up into a single line, so a sender that reported every day for a month appears once.
Empty States
If the table is empty, the reason depends on the domain:
- MTA-STS is configured, no reports yet. Usually nothing is wrong: sending servers have not reported yet, which normally resolves within 24 to 48 hours of the records going live. If it has been longer, check on DNS Records that the
_smtp._tlsTXT record is live, because without it no sender knows where to report. - 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:
- Enable Hosted MTA-STS in Testing mode.
- Wait for reports to appear here, then leave it running for at least a week.
- Confirm the success rate is at or near 100% and the Failure Breakdown panel is absent or explained.
- Only then switch the policy to Enforce.
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.
Related
- Hosted MTA-STS — the hosted MTA-STS policy, and the TLS-RPT record to add at your DNS provider
- DNS Records — confirm the
_smtp._tlsTXT record is live - Domain Overview — the domain's overall authentication health