Fetched MTA-STS policy misses ShipReady's required fields
ShipReady received HTTP 200 from the fixed MTA-STS policy URL but found one or more required fields outside its bounded MTA-STS policy parser.
Why it matters
A policy that is present but fails basic field checks needs review. This finding reports the parser's result for one fetched response and is not a complete MTA-STS implementation or mail-transport assessment.
How ShipReady detects it
What it inspects
After observing a qualifying MTA-STS TXT record, ShipReady makes one bounded request to the fixed policy URL and evaluates only an HTTP 200 response.
What triggers a finding
The rule triggers when the line-based parser does not find version exactly STSv1, a mode of none, testing, or enforce, at least one mx field, or an integer max_age from 1 through 31557600. For repeated version, mode, and max_age fields it uses the last parsed value.
What the evidence shows
The fetched HTTP-200 policy response failed one or more of ShipReady's listed required-field checks.
Limits of this check
ShipReady does not validate every MTA-STS grammar rule, test mx-pattern matching, verify sender support, send SMTP, inspect TLS negotiation, or establish actual delivery behavior.
How to fix it
Inspect the exact policy response
Request the fixed policy URL and compare the deployed text with the intended MTA-STS configuration.
Correct the reported field conditions
Restore the intended version, mode, mx entries, and max_age value through the deployment source, then perform a complete MTA-STS validation separately.
How to verify the change
Validate the deployed policy
Request the policy URL after deployment and use MTA-STS-aware validation appropriate to the mail environment.
Expected: The policy contains the intended required fields and independent validation succeeds where applicable.