MSPs should read TLS-RPT reports as dated evidence of SMTP transport-security results from participating senders, then investigate failures by policy, receiving host and reporting window. A failure count does not establish lost messages, a breach or a problem that remains unresolved; a clean report covers only the sessions its sender reported.
- TLS-RPT reports describe reported SMTP transport-security outcomes, not confirmed message delivery or compromise.
- Interpret tls rpt failures by reporting window, policy type, receiving host and failure details.
- MTA-STS and DANE provide policy context; TLS-RPT supplies reporting evidence.
- Keep missing reports unknown, assign an owner and verify changes against a dated baseline.
How should MSPs interpret TLS-RPT delivery reports?
Start with the scope of the report, then interpret the failure. RFC 8460 defines SMTP TLS reporting, including its JSON structure and failure categories. Its scope is transport-security reporting, rather than mailbox delivery confirmation.
For a 2026 prospect review, follow this sequence before turning a report into a recommendation. Keep the original evidence attached to your domain-scan evidence packet.
- Identify the reporting organization and policy domain. Confirm that the report concerns the domain you are reviewing.
- Read the
date-range, including its start and end timestamps. Record when you received the report separately. - Inspect each policy entry. Read
policy-type,policy-string,policy-domainand any listed MX hosts together. - Compare the 2 session counters:
total-successful-session-countandtotal-failure-session-count. These count reported sessions, not unique messages or people. - Group
failure-detailsbyresult-type, receiving endpoint and sending source where supplied. Preserve the associatedfailed-session-count. - Ask the mail-service owner to correlate the finding with logs and change history. Verify the outcome using subsequent comparable reports.
The JSON field names above come from RFC 8460. Preserve them in technical notes so another practitioner can trace your conclusion to the source.
Why this matters
A report can identify a transport-security problem without explaining its business impact. That distinction determines whether your next step is investigation, a configuration change or a documented decision to leave the configuration unchanged.
For MSP sales preparation in 2026, the useful output is a bounded conversation: which sender observed which condition, during which interval, and who can verify it. A frightening interpretation adds no evidence.
SMTP server-to-server transport commonly uses TCP port 25. An HTTPS certificate check against a website examines a different service and does not establish that the domain's receiving mail servers satisfy their SMTP transport policy.
Read the reporting window before the failure count
RFC 8460 recommends daily reporting, commonly covering a 24-hour period. Read the timestamps in each report rather than assuming every file represents the same duration.
A report received today can describe an earlier interval. If the mail-service owner changed a certificate after that interval ended, the report cannot establish the post-change condition.
Compare windows with compatible scope. A longer interval, different reporting sender or changed mail route makes a raw count comparison less informative.
Keep these dates separate in your 2026 evidence record:
- Observation interval: the report's start and end timestamps.
- Receipt time: when your reporting destination received the report.
- Investigation time: when the MSP reviewed the evidence.
- Change time: when the responsible owner altered the relevant configuration.
- Verification interval: the later reporting window used to evaluate the change.
A report date is part of the finding. Removing it turns a historical observation into an unsupported claim about current conditions.
Separate TLS-RPT, MTA-STS, DANE and DMARC
These mechanisms answer different questions. Treating them as interchangeable produces recommendations that do not address the observed failure.
| Mechanism | Best for | What it contributes | Boundary or limitation |
|---|---|---|---|
| TLS-RPT | Receiving transport-security feedback | Reports participating senders' TLS policy and connection results | Does not itself enforce encryption or confirm mailbox delivery |
| MTA-STS | Publishing an SMTP transport policy through HTTPS | Lets supporting senders discover expected MX hosts and TLS requirements | Depends on policy discovery, valid configuration and sender support |
| DANE for SMTP | Authenticating SMTP TLS through DNSSEC-backed TLSA records | Binds receiving-service TLS authentication to authenticated DNS data | Requires the relevant DNSSEC and TLSA configuration and sender support |
| DMARC | Evaluating domain alignment for email authentication | Expresses policy for messages failing aligned SPF and DKIM checks | Does not report SMTP TLS negotiation outcomes |
The relevant protocol references are RFC 8460 for TLS-RPT, RFC 8461 for MTA-STS and RFC 7672 for SMTP DANE. Their scopes remain distinct in a 2026 review.
A report's policy-type can be sts, tlsa or no-policy-found. Read the accompanying details before deciding whether the report concerns policy discovery, policy validation or an attempted TLS connection.
Interpret failure categories without overstating impact
Certificate failures
Results such as certificate-expired, certificate-host-mismatch and certificate-not-trusted describe the reporting sender's certificate-validation outcome. Inspect the receiving hostname and IP address where supplied, then ask the owner to check the endpoint and certificate chain relevant to that interval.
A certificate failure is not evidence that an attacker intercepted mail. It also does not establish that every receiving endpoint presented the same certificate.
STARTTLS failures
A starttls-not-supported result means the reporting sender recorded that condition for the relevant connection. Check the reported endpoint against the intended mail route and the provider's logs.
Do not translate the result directly into a claim that all messages traveled unencrypted. Sender policy, retry behavior and the eventual delivery outcome require separate evidence.
MTA-STS and DANE policy failures
MTA-STS results can identify policy-fetch, policy-validation or policy-content problems. DANE-related results can identify TLSA or DNSSEC validation problems.
Preserve the exact result-type; do not collapse every category into a generic certificate issue. A failed policy fetch and a hostname mismatch require different investigations.
Unclassified failures
A validation-failure result needs its accompanying detail, including failure-reason-code where provided. Keep an unclear result unresolved until the responsible provider or operator can explain it.
Unreadable attachments and unsupported report formats are processing limitations. Record them separately from successful transport observations.
Why TLS-RPT results vary
Failure totals reflect both the underlying condition and the reporting population. These factors explain why two reports can differ without proving improvement or deterioration:
- Reporting participation: each report covers its reporting sender's observations, rather than every organization sending mail to the domain.
- Reporting window: intervals can cover different traffic volumes or fall on different sides of a configuration change.
- Policy context:
sts,tlsaandno-policy-foundrepresent different policy circumstances. - Receiving endpoint: different MX hosts or IP addresses can present different configurations.
- Sending source: different sending systems can encounter different routes or validation results.
- Aggregation detail: reports summarize sessions and do not provide a complete message-by-message delivery history.
Use these factors to qualify comparisons. A lower failure total, without comparable scope and session totals, does not establish that a change fixed the condition.
Turn the report into evidence, insight and proof
Use a finding record that separates what happened from what you propose. The following structure works for discovery, an authorized assessment or a QBR without turning a technical observation into buying intent.
Observed
Record the reporting organization, policy domain, date range, policy type, exact failure category and affected endpoint where supplied. Retain the original report and identify any parsing or coverage limitations.
For a public-domain review, distinguish published DNS configuration from reports obtained through an authorized reporting destination. Finding a TLS-RPT DNS record does not mean you have read the reports sent to it.
Possible consequence
Explain the transport-security requirement that the observed condition failed to satisfy. Depending on the sender's policy, a failure can affect the ability to establish an acceptable TLS connection; message delay or nondelivery requires corroboration.
Keep that consequence conditional until you have supporting logs. Do not substitute a hypothetical breach cost or a claim of compromise.
Ask
Identify the person responsible for the receiving mail configuration, reporting destination and relevant provider relationship. Request the change history and logs needed to establish whether the condition persisted or affected delivery.
Offer a bounded next choice: inspect the endpoint, validate policy publication, involve the mail provider or document the intended configuration. The MSP chooses the service or process after the evidence supports it.
Verify
Pin the original report as the baseline. After an authorized change, compare subsequent reports for the same domain, policy and relevant receiving endpoints, while recording differences in sender coverage and traffic.
A missing later report is an evidence gap. Successful observations from a participating sender support a narrower conclusion about that sender's reported sessions.
Keep the technical record and owner-facing explanation connected. The business summary can be short, but it must preserve the source, interval, boundary and next decision.
Use the finding in an MSP conversation
SCOUTz is best for MSPs preparing sales conversations with dated cybersecurity evidence and prospect context. SCOUTz provides cybersecurity prospect intelligence; its role is preparation, with the relationship and sale remaining the MSP's responsibility.
For this use case, SCOUTz's evidence-first approach means preserving the report's origin and limits before explaining its relevance. A supplied TLS-RPT report should not be presented as evidence that a platform independently collected it unless that collection is established.
Keep public-domain observations separate from customer-authorized Microsoft 365 evidence. A public review cannot establish Conditional Access coverage, application permissions, license assignments or tenant sharing configuration.
In a 2026 proposal, scope the work around verification: inspect the reported condition, identify the responsible owner and establish whether action is needed. The trade-off is deliberate: dated evidence improves the basis for a discussion, but it does not establish buying intent or replace MSP judgment.
Does a TLS-RPT failure mean email was not delivered?
A TLS-RPT failure records a reported transport-security failure, not a final mailbox-delivery result. Establish delivery impact through authorized message tracing, queue information or provider logs.
SMTP retries and alternate receiving paths make session totals different from unique-message totals. Do not describe the failure count as lost emails.
Does no TLS-RPT report mean the domain is secure?
No TLS-RPT report means you lack that reporting evidence. Check publication, reporting-destination operation, sender participation and processing before drawing a conclusion.
Even a successfully processed report describes only its stated interval and reported sessions. Keep broader coverage unknown unless another source establishes it.
Should an MSP change MTA-STS after seeing failures?
An MSP should investigate the specific failure before changing MTA-STS. Confirm the intended policy, affected endpoint and responsible owner first.
Weakening enforcement can change the security requirement without correcting the underlying configuration. Record the proposed outcome and obtain authorization before making changes.
FAQ
What does TLS-RPT actually tell an MSP?
TLS-RPT tells an MSP how participating senders reported SMTP transport-security outcomes for a domain during a stated interval. It does not provide a complete message-delivery history or establish compromise.
How often should TLS-RPT reports arrive?
RFC 8460 recommends daily reporting, commonly covering a 24-hour interval. Read each report's date range and investigate missing reporting rather than treating absence as a successful result.
Are TLS-RPT failure counts the same as failed emails?
TLS-RPT failure counts are session counts, not counts of unique failed emails. Use authorized mail logs or message tracing to establish delivery impact.
Is TLS-RPT better than DMARC for checking email security?
TLS-RPT and DMARC address different evidence needs. TLS-RPT concerns SMTP transport security, while DMARC concerns domain alignment and email-authentication policy.
Can a public domain scan read a company's TLS-RPT reports?
A public domain scan can inspect published reporting configuration, but that does not grant access to reports delivered to the reporting destination. Obtain reports through an authorized source and record their provenance.
Should we disable enforcement when certificate failures appear?
Investigate the certificate failure before changing enforcement. Confirm the affected endpoint, intended policy and owner-approved corrective action rather than treating a weaker requirement as a repair.
How should SCOUTz users describe a TLS-RPT finding to a prospect?
SCOUTz users should describe the observed condition, source and reporting interval, then state the boundary and ask who owns verification. Do not turn the report into a claim of compromise, buying intent or a currently unresolved problem.
One last thing
Preserve the original report before writing the sales summary. A polished explanation without its source cannot support a later comparison.
Keep policy text, report interval, failure details and the owner's response together. That record lets a technician verify the condition and lets a business owner understand the next choice without accepting an unsupported claim.
