MSPs should review MTA-STS by checking the published policy, comparing its MX patterns with current mail routing, and recording the source, run date, and limits before discussing consequences with a client. A public review establishes what the domain publishes and what the reviewer can observe; it does not establish how every sender delivers mail, whether messages were intercepted, or whether the client needs a configuration change.
- An mta sts review should connect published email transport policy to current MX routing and dated evidence.
- SCOUTz supports MSP prospect intelligence; the MSP owns the interpretation and client conversation.
- Testing mode gathers evidence without requiring supporting senders to enforce the policy.
- An unreadable policy is unknown evidence, not proof that a control is absent.
Why this matters
MTA-STS concerns transport protection for incoming email. A finding about its publication belongs in a conversation about mail routing, ownership, and intended policy. It does not establish account compromise or reveal message contents.
SCOUTz is best for MSPs preparing prospect conversations with dated cybersecurity evidence and account context. The useful output is a bounded question with supporting evidence, rather than a verdict about the prospect's entire email environment.
For a 2026 review, use IETF RFC 8461 as the technical reference for MTA-STS and RFC 8460 for SMTP TLS reporting. Keep their scopes separate: one describes transport policy; the other describes reporting about transport-security outcomes.
How should MSPs review MTA-STS before a client conversation?
Use this sequence to turn public observations into a defensible meeting brief. Record the actual collection time, including its time zone, rather than treating the article's 2026 publication year as a scan date.
1. Identify the receiving domain
Start with the domain after the recipient's email address. Record its current MX records and the hosts they identify. A website hostname, brand name, and email domain are not interchangeable.
Preserve the resolver response and collection time. If the client uses a mail gateway before Microsoft 365, the externally published route matters to this review. Do not assume the final mailbox provider is the first receiving system.
2. Retrieve the discovery record
Query the TXT record at the domain's _mta-sts label. Record the returned version and policy identifier, along with DNS errors or conflicting responses.
The discovery record points supporting senders toward a policy; it does not contain the full policy. A returned TXT record alone does not establish that the policy endpoint is reachable, valid, or aligned with the current MX records.
3. Retrieve and inspect the policy
Fetch the policy from the domain's mta-sts HTTPS host at the standardized path /.well-known/mta-sts.txt. Record retrieval success, certificate validation, response details, and the policy text.
Inspect version, mode, max_age, and the mx entries required for the selected mode. Distinguish a missing record from a DNS lookup failure, and distinguish an HTTP error from a policy-format error. Those observations lead to different follow-up work.
4. Compare policy with mail routing
Compare each current MX hostname with the policy's allowed MX patterns. Check wildcard matching according to RFC 8461 rather than treating every wildcard as a match for every hostname.
SMTP delivery normally reaches receiving servers on TCP port 25; policy retrieval uses HTTPS on TCP port 443. A successful HTTPS fetch does not prove that the SMTP service presents an acceptable certificate or supports the required transport behavior.
If the review includes SMTP testing, document the authorization and method separately. Public DNS observation and active connections are different activities. Do not assume that a publicly reachable service creates blanket permission for every test.
5. Write the observation and its boundary
Keep the condition, affected domain, timestamp, evidence state, coverage, and proposed question together. State whether the review observed publication only or also included authorized transport testing.
MTA-STS requires supporting senders to use TLS version 1.2 or later for policy-compliant delivery. A published policy cannot prove that every sender supports MTA-STS or that every past delivery met its requirements.
Testing mode: observe before enforcement
A policy with mode: testing asks supporting senders to evaluate policy without withholding delivery solely because MTA-STS validation fails. It supports preparation for enforcement when paired with transport reporting and operational review.
Testing is not proof of a neglected deployment. It can reflect an intentional rollout or a routing transition. Ask who owns the rollout, who reviews reports, and what evidence will support the next decision.
Enforce mode: validate the route before recommending changes
A policy with mode: enforce directs supporting senders to apply its transport requirements. Policy failures can prevent those senders from delivering successfully until the failure is resolved or their delivery process expires.
Enforcement therefore needs operational ownership. An MX migration, certificate problem, or stale policy pattern deserves investigation before you recommend a change. Published enforcement is evidence of stated policy, not proof that the complete email environment is secure.
None mode: distinguish withdrawal from absence
A policy with mode: none tells supporting senders that the domain is not implementing MTA-STS policy enforcement. This differs from failing to retrieve a policy or finding no discovery record.
Previously cached policies complicate transitions. Preserve the current response and ask about the change history instead of assuming that every sender immediately sees the same state.
| Policy mode | Best for | Benefit | Limit or operational concern |
|---|---|---|---|
testing | Evaluating deployment behavior | Allows policy evaluation without MTA-STS-based enforcement | Does not require supporting senders to block policy failures |
enforce | Applying a validated transport policy | Requires supporting senders to follow published requirements | Routing or certificate mismatches can disrupt delivery |
none | Withdrawing MTA-STS policy use | Explicitly communicates that policy enforcement is not requested | Does not erase every sender's previously cached policy immediately |
These are policy choices, not a universal maturity ranking. The right recommendation depends on the intended mail route and the evidence available.
Why MTA-STS findings vary
The same headline finding can describe different operational situations. Keep these factors separate in a 2026 assessment:
- DNS resolution determines whether the reviewer receives a usable discovery response or an error.
- HTTPS reachability and certificate validation determine whether the policy can be retrieved securely.
- MX changes can leave published policy patterns out of step with the receiving route.
- Policy mode determines whether supporting senders evaluate or enforce the requirements.
- Sender support and cached policy affect behavior beyond the reviewer’s immediate observation.
- Reporting coverage determines which delivery outcomes the domain owner can inspect.
None of these factors establishes buying intent. A public configuration observation supports research and a specific question. The client still needs to explain ownership, intent, and recent changes.
What evidence belongs in the client brief?
Use a compact evidence record rather than a page of warning icons. Attach the original response or export so another practitioner can inspect the basis of the statement.
| Field | What to record | Boundary to preserve |
|---|---|---|
| Condition | The exact discovery or policy observation | Publication does not prove delivery history |
| Affected object | Recipient domain and relevant MX hosts | Website configuration is a separate scope |
| Source and date | DNS response, HTTPS response, collection time | A later change requires fresh evidence |
| Evidence state | Observed, Inferred, Unknown, or Unreadable as appropriate | These states are not a severity ladder |
| Coverage | Assessed, Partial, or another accurate coverage label | Untested SMTP behavior remains untested |
| Owner and outcome | Responsible team and intended transport behavior | The MSP chooses the next service or action |
For example, if the fetched policy states testing, the observation is that the domain published testing mode at collection time. The possible consequence is that supporting senders do not enforce MTA-STS failures under that policy. The ask is whether testing remains intentional and who reviews the transport reports.
Do not manufacture a scan date for this example. A client brief prepared in 2026 needs the actual run timestamp and retained evidence.
Does an MTA-STS finding mean email was intercepted?
An MTA-STS finding does not establish email interception. A missing policy, retrieval failure, or MX mismatch describes a configuration or observation boundary, not an incident.
Name the transport concern and stop there. Claims about intercepted messages require separate incident evidence, an appropriate investigation, and a defined scope.
Can a public review assess Microsoft 365 security?
A public MTA-STS review cannot establish Microsoft 365 Conditional Access coverage, application permissions, license assignments, device state, or tenant sharing configuration. Those questions require customer-authorized internal evidence.
Keep that distinction visible when preparing a security assessment without client network access. A consented read-only Microsoft 365 review concerns configuration and metadata; it does not require reading mail, files, chats, documents, or prompts.
How should MSPs present the next step?
Offer a choice tied to the evidence: confirm intent, investigate an unreadable source, validate a planned transition, or establish an authorized baseline. Do not jump from a public observation to a remediation proposal without identifying the owner.
For a 2026 proposal, separate the work into Evidence, Insight, and Proof:
- Evidence: preserve what ran, what returned, and what remained unread.
- Insight: explain the possible operational consequence and ask whether it matches the client's intent.
- Proof: agree on the desired outcome and rescan against the pinned baseline after approved work.
The proof is the observed change against that baseline. It is not a promise that future mail delivery cannot fail.
For MSPs evaluating SCOUTz for cybersecurity prospect intelligence, Join Open Beta is the next step. The platform prepares the conversation; the relationship and the sale stay with the MSP. Product selection does not replace authorization, technical validation, or client judgment.
FAQ
What should an MSP check first in an mta sts review?
An MSP should first identify the recipient domain and its current MX records. Then retrieve the MTA-STS discovery record and policy, preserving the collection timestamp and original responses.
Is MTA-STS testing mode a security incident?
MTA-STS testing mode is not evidence of a security incident. It indicates that supporting senders evaluate the published policy without enforcing MTA-STS failures; confirm whether that mode remains intentional.
Does MTA-STS replace SPF, DKIM, or DMARC?
MTA-STS does not replace SPF, DKIM, or DMARC. MTA-STS addresses transport requirements for supporting senders, while those mechanisms address sender authorization, message signatures, and domain-based authentication policy.
Does a valid MTA-STS policy prove every email is encrypted?
A valid MTA-STS policy does not prove every email is encrypted. Sender support, cached policy, the observed route, and the scope of transport testing all limit that conclusion.
Should an MSP recommend enforce mode immediately?
An MSP should recommend enforcement only after validating the intended receiving route and operational ownership. Review MX matching, certificate behavior, reporting, and planned routing changes before proposing the change.
What does an unreadable MTA-STS policy mean?
An unreadable MTA-STS policy means the reviewer could not inspect the policy through the attempted method. Preserve the error and mark the coverage accurately rather than reporting an absent control.
Can SCOUTz findings prove that a prospect wants to buy?
SCOUTz findings do not prove buying intent. They provide dated evidence and account context for an MSP to interpret, validate, and discuss with the prospect.
One last thing
A current policy fetch and a sender's cached policy can describe different moments. If a client changed MX routing or policy recently, ask for the change record before treating a mismatch as an unresolved problem.
Your closing recommendation should identify an owner and a verification condition. Preserve the baseline, agree on the intended state, and repeat the relevant checks after approved changes. That produces evidence of what changed without inventing a breach, urgency, or sales opportunity.
