Published MTA-STS policy URL returned a completed failure result
ShipReady found a qualifying MTA-STS TXT record and then observed a completed failure while requesting the fixed HTTPS policy URL.
Why it matters
A published MTA-STS record points to a policy deployment that should be reviewed when ShipReady receives a completed failure result. The observation is from one bounded request and does not establish sender behavior or mail-delivery impact.
How ShipReady detects it
What it inspects
After observing a TXT value beginning with v=STSv1, ShipReady makes one bounded 10-second request to the fixed HTTPS policy path on mta-sts for the organisational domain.
What triggers a finding
The rule triggers for a completed non-200 response, or for a request failure whose causal chain proves connection refusal, TLS certificate verification failure, or DNS nonexistence. Timeouts, scanner-side failures, response refusals such as 429/503, and other inconclusive errors suppress the finding.
What the evidence shows
ShipReady's bounded request to the fixed MTA-STS policy URL received the reported completed failure result.
Limits of this check
ShipReady does not establish whether all senders can reach the endpoint, whether any sender supports or applies MTA-STS, whether SMTP TLS succeeds, or whether any email delivery failed.
How to fix it
Inspect the exact MTA-STS policy URL
Request the fixed policy URL from an independent environment and review its DNS, TLS certificate, status response, and access controls.
Align the record and policy deployment
Repair the policy host or deployment only after identifying why the published policy URL produced the observed result.
How to verify the change
Recheck the policy endpoint
After the repair, request the same HTTPS policy URL and inspect the response.
Expected: The policy URL returns the intended policy response in your verification environment.