MTA-STS failures concern transport security for inbound mail. They are not repaired by changing SPF or DKIM. Diagnose the chain in order: policy discovery in DNS, policy retrieval over HTTPS, the permitted MX names, and the TLS behaviour of the receiving servers.
Identify the affected sending observation
Collect the sender's delivery error, time, destination domain and available TLS report. Separate a single sender's result from a universal outage. Senders may have cached different policy versions, and implementations differ in their support. Record the current policy identifier, body, mode and max_age alongside any previously active policy you can recover.
RFC 8461 defines discovery at _mta-sts for the receiving domain and HTTPS retrieval at https://mta-sts.<domain>/.well-known/mta-sts.txt. Check the published TXT record and the exact URL for the real domain. Ensure the HTTPS endpoint presents a trusted certificate for its hostname and serves a valid policy. RFC 8461 Section 3.3 requires HTTP 200 and forbids following HTTP 3xx redirects when fetching the policy. A successful browser visit to the home page does not establish that endpoint behavior.
Compare policy with actual MX routing
Inspect the destination domain's public MX records and compare their hostnames with the policy's mx patterns. Test every active receiving host, including a backup that normally gets little traffic. A newly added backup outside the permitted pattern can create intermittent failures rather than a clean total outage.
For each MX host, verify SMTP STARTTLS, certificate validity, trust chain and identity matching for the MX hostname. Keep the web policy certificate and the SMTP server certificates separate in the investigation: repairing one does not repair the other. Use a suitable TLS diagnostic tool from an authorised testing location and retain the connection details without transmitting real messages or credentials unnecessarily.
Interpret mode and caching correctly
Testing mode does not require rejection for an MTA-STS validation failure; other delivery controls may still refuse the message. Enforce mode applies its validation requirement when the sender has an applicable policy. An enforcing sender with an applicable cached policy can continue to require that policy even if the DNS discovery record is later removed. Removing a broken website is therefore not a reliable instant rollback.
When a policy changes, update the discovery identifier so supporting senders can detect the change. Plan changes around the published cache lifetime. For a planned withdrawal, use the RFC's mode none procedure and allow for cached policies rather than treating DNS deletion as immediate cancellation. Keep the policy endpoint available during transitions where senders still need it.
Work a failure through the chain
Illustrative case: example.org advertises primary.example.org and backup.example.net as MX hosts, but the MTA-STS policy permits only primary.example.org. Mail normally succeeds until the backup is selected. The first correction to investigate is the mismatch between the intended receiving route and the policy, not a sender SPF record. Verify that the backup is authorised and TLS-capable before adding it. This is a synthetic scenario, not a live domain test.
Build a diagnosis row containing observation time, sending source, policy version if known, selected MX, TLS error, intended change and verification result. TLS reports can reveal categories and patterns, but their coverage is not complete and absence of reports is not proof that every sender succeeds.
Restore service without hiding the cause
Prefer repairing the actual certificate, endpoint or routing mismatch. If a policy relaxation is necessary, obtain the relevant change approval, document the temporary exposure and account for caches. After repair, verify each MX path and examine subsequent sender observations and TLS reports. Keep expiry monitoring for both HTTPS and SMTP certificates and include the MTA-STS policy in every mail-provider migration checklist.
Keep cache history in the withdrawal decision
RFC 8461 Section 8.3 describes publishing mode none with a short lifetime and a changed discovery record, then retaining the endpoints until all previously served policies expire. Include older policies whose longer max_age can outlive the immediately preceding version. Deleting DNS does not erase those caches. Section 3.3 distinguishes a failed fresh fetch with no usable cache from a failed fetch with a valid cached policy. RFC 8460 Sections 4.2 and 4.3 describe reported sessions and failure types, not a complete per-message delivery ledger. No TLS connection, lookup or migration was executed for this teaching scenario.