[ Transport security ]

MTA-STS fetch failures and unexpected HTTP responses

Trace policy retrieval from the authenticated original URL through the first HTTP response and policy body, without relying on browser redirects or disabled validation.

By the EmailAuth research team · 6 min read

[ Key points ]

Distinguish network reachability, TLS authentication, HTTP status and policy parsing.
MTA-STS requires HTTP 200 and forbids following 3xx redirects.
A 200 HTML challenge or error page can still fail policy validation.
Describe recovery in terms of each sender cache and retry behavior, not one browser visit.

On this page

Key points
Treat the first response as evidence
Separate connection failure from HTTP failure
Interpret status codes without browser shortcuts
Verify the body after a successful response
Follow a fictional redirect incident
Explain why senders may diverge
Close the incident with the right evidence
Role perspectives
Glossary
Primary sources and evidence scope

Treat the first response as evidence

An MTA-STS policy can look available in a browser while a compliant sending server rejects its retrieval. Browsers commonly follow redirects, carry cookies and render application pages. Policy retrieval instead has a narrow contract: the prescribed HTTPS host and path, a valid certificate, a 200 response and a parseable policy. Diagnose the first failed layer before changing DNS or weakening transport protection.

No customer endpoint was contacted for this guide. The scenarios are fictional and the capture procedure is proposed. A real incident still needs a timestamped connection trace identifying the target, certificate validation result, HTTP response and returned body. Retain failures as well as successful retries so that a later improvement does not erase the cause.

Separate connection failure from HTTP failure

For example.com, the retrieval target is https://mta-sts.example.com/.well-known/mta-sts.txt. Name resolution and network connection precede TLS authentication; HTTP processing follows a successful handshake. An unreachable address, certificate error, HTTP 404 and invalid body are different observations. A tool that reports all of them as “fetch failed” needs its detailed output before the operator can assign the issue. RFC 8461 sections 3.2–3.3

Identify the hostname used for certificate validation, not merely the final address. A hosting CNAME does not replace the required policy-host identity with the provider's name. The presented chain must lead to a root trusted by the sender and the certificate must be unexpired. Never turn off certificate checks to produce a passing readiness result. A deliberately nonvalidating inspection, if separately approved, would be different evidence. RFC 8461 sections 3.3 and 8.2

Interpret status codes without browser shortcuts

RFC 8461 accepts a fetched policy only with HTTP 200 and prohibits following HTTP 3xx redirects. A 301 to a provider address, 302 to a login page or 307 added by a web framework is therefore not a successful policy fetch. A 304 is also outside the required 200 response, and sending MTAs must not use ordinary HTTP caching for this retrieval. Their MTA-STS policy cache is a separate mechanism. RFC 8461 section 3.3

HTTP status semantics help assign the repair: 404 indicates that the origin did not find a current representation or is unwilling to disclose one; 403 refuses fulfillment; 503 indicates temporary service unavailability. These statuses identify an HTTP outcome, not the exact web-server configuration responsible. Preserve response headers and the deployment revision, then ask the responsible hosting team to compare routing, access controls and upstream availability. RFC 9110 section 15

Verify the body after a successful response

A 200 response is necessary but insufficient. Inspect whether the body contains the MTA-STS fields and whether the media type is text/plain, which senders should validate. An application shell, anti-bot challenge or custom error page can carry status 200 while failing policy parsing. Record content type, byte length and an unchanged copy of the response; do not paste only the lines that look valid. RFC 8461 section 3.2

Policy fetchers may impose time and size limits. The specification suggests a one-minute timeout and a 64-kilobyte maximum body, rather than guaranteeing every implementation uses those exact thresholds. Slow application startup or an unexpectedly large response can therefore explain differing results between senders. A small, consistently served resource reduces those dependencies, but the actual service architecture remains an owner decision. RFC 8461 section 3.3

Follow a fictional redirect incident

Imagine a fictional hosting migration where the original policy URL returns 301 with a Location pointing to a provider-owned hostname. A desktop browser follows it and displays a correct testing policy. A supporting sender reports sts-policy-fetch-error. The redirect and report are invented for this example; neither is a customer observation.

The direct 301 is already sufficient to explain why the original retrieval fails the MTA-STS HTTP requirement, even if the destination text is correct. A proposed correction would serve the policy directly at the original URL, potentially through a properly configured reverse proxy. That original service must still authenticate as mta-sts.example.com. Do not replace the requirement with permission to follow redirects, and do not change a discovery ID merely to conceal a hosting fault. RFC 8461 sections 3.3 and 8.2

Explain why senders may diverge

A sender holding a valid cached enforce policy must continue applying it when refresh fails. A sender without a valid cached policy and unable to fetch one continues without MTA-STS protection. A hosting outage therefore does not imply that every sender immediately stops mail, nor that all senders remain protected. Diagnose cache state and other applicable policies separately from website availability. RFC 8461 section 3.3

Repeated attempts may also be throttled. After an unsuccessful GET, implementers should limit additional attempts to intervals of five minutes or longer per version ID. A repair can consequently precede the next visible successful refresh. Avoid claiming instant recovery from one browser visit; retain sender-specific observations and the relevant collection times. RFC 8461 section 3.3

Close the incident with the right evidence

TLS-RPT separates policy retrieval errors, invalid policy content and policy Web PKI authentication failures. Use those categories to prioritize investigation while retaining the reporter's detail and recognizing that labels alone do not identify a server-side cause. Correlate a corrected first response with subsequent reporting and the sender's policy state. RFC 8460 section 4.3.2.2

The completion packet should show the authenticated original endpoint, direct 200 response, parseable body and reviewed MX scope. Original hosting evidence, customer certificate traces and sender recovery confirmation remain absent here. Current RFC errata were reviewed without converting reported proposals into normative fixes; independent review and publication authorization remain separate decisions. RFC 8461 errata

[ Takeaway ]

A correct policy at the end of a browser redirect is not a valid MTA-STS fetch. Preserve the first response and diagnose each retrieval layer separately.

[ By role ]

What this means for you

Choose your role for practical next steps.

Web platform owner

Keep the policy route simple and direct

General website middleware can introduce redirects, authentication and HTML responses that conflict with the policy retrieval contract.

Next steps

Inspect the original well-known route before following any Location header.
Review certificate selection and text response behavior together.
Retain the deployment revision and direct response evidence.

Email operations analyst

Correlate the report with sender state

Transport reports and website checks can cover different times and different cache states. A repair assessment needs that context.

Next steps

Separate fetch, policy syntax and Web PKI result types.
Record reporter, interval and cached-policy clues.
Avoid declaring all senders recovered from one successful fetch.

Incident lead

Repair the observed layer

A response label should narrow a hypothesis, not become an unsupported cause statement. Keep the approved repair tied to evidence.

Next steps

Assign network, TLS, HTTP or parser investigation to the correct owner.
Do not accept disabled validation as a passing test.
Close the incident only within the coverage of retained observations.

[ FAQs ]

Frequently asked questions

Can the policy URL redirect to a managed provider?

A sending MTA must not follow a 3xx redirect during policy retrieval. Delegated hosting can serve or proxy the policy at the original required URL, but that endpoint still needs the correct policy-host certificate and direct HTTP 200 response.

Does HTTP 200 prove the policy is usable?

No. The response body must still be a valid MTA-STS policy, and senders should validate the text/plain media type. An HTML login page or anti-bot challenge remains unsuitable even when the web server labels it 200.

Is an HTTP 304 response acceptable for a cached policy?

No. A fetched policy is valid only with response code 200, and senders must not use ordinary HTTP caching for retrieval. The sender MTA-STS policy cache is separate from HTTP conditional-response behavior.

Does an HTTP 404 identify the exact hosting mistake?

No. It identifies the HTTP outcome, not whether routing, deployment, access masking or an upstream configuration caused it. Retain the original URL and response, then compare them with the responsible hosting team's intended configuration.

Must every sender use a one-minute retrieval timeout?

No. RFC 8461 suggests one minute and a 64-kilobyte maximum policy body while allowing implementations to impose limits. Treat those numbers as recommendations rather than proof of an unknown sender's configuration.

Why might a sender still report failure after the endpoint is repaired?

Fetch retries can be rate-limited, and the report may describe an earlier interval. RFC 8461 recommends spacing failed GET retries by five minutes or longer per version ID. Correlate times before deciding the repair failed.

Does a fetch outage immediately remove enforce protection?

Not for a sender with a valid, unexpired cached enforce policy: it must continue applying that policy. A sender without a valid cached policy follows different acquisition-failure behavior. Neither state can be inferred from the website outage alone.

Which capture would support an endpoint repair claim?

Retain the exact original hostname and path, timestamp, address, validating TLS result, first HTTP status, headers and unchanged body. Correlate sender recovery where available. No such customer trace or hosting observation was collected for this draft.

[ Sources ]

Sources

[ Glossary ]

Glossary

First response: The response to the original policy request before any redirect is followed; the proposed capture preserves it for diagnosis.
HTTP redirect: A 3xx response directing a client toward another action or location; MTA-STS policy fetchers must not follow such redirects.
Policy fetch: HTTPS retrieval of the MTA-STS body from the prescribed policy-host path.
Web PKI validation: Certificate authentication using the public-key infrastructure and trust chain required for the policy HTTPS endpoint.
Fetch retry interval: The spacing between attempts to retrieve a policy after failure; RFC 8461 recommends at least five minutes per version ID.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base