MTA-STS policy unreachable

The DNS record is discovery: it tells a sending server that a policy exists and carries an identifier that changes when the policy does.

The policy file is the content: it lists the mail exchangers and states the enforcement mode.

A record without a file means the sending server looks, finds nothing, and continues without a policy.

A file without a record is never discovered, because nothing tells anyone to fetch it.

Neither half produces an error on its own, which is why a half-configured deployment survives.

The policy file is fetched over HTTPS from a fixed hostname under your domain, and the sending server validates the certificate.

A certificate that does not cover that hostname means the fetch fails and the policy is treated as unavailable.

There is no insecure fallback: a sending server will not fetch the policy over plain HTTP.

Which makes mail delivery protection depend on a web certificate covering a hostname nobody visits in a browser — an unusual coupling and the most common cause of this failure.

A wildcard certificate covering one subdomain level usually covers it; a certificate listing specific names usually does not unless it was added deliberately.

The hostname has no DNS record of its own, so nothing resolves before the certificate is even considered.

A redirect from that hostname to the main site, which changes what is served at the expected path.

The file served with the wrong content type, which some implementations reject.

A CDN or firewall rule that answers the path with a challenge page rather than the file.

A file served correctly and an identifier in the DNS record that was never updated, so sending servers keep a cached policy that no longer matches.

Publish a DNS record for the policy hostname and confirm it resolves.

Obtain or extend a certificate covering that hostname, and confirm it validates from outside rather than from your own network.

Serve the policy file at the fixed well-known path with the expected content type.

Confirm the exchanger list in the file matches the exchangers published in DNS — a missing one is refused under enforcement.

Publish a TLS reporting record alongside, which is what makes a testing-mode policy produce observable information.

Query the TXT record at the MTA-STS name for your domain and read its identifier.

Fetch the policy file over HTTPS from the policy hostname at the well-known path, and confirm a 200 with the file's content.

Do that from outside your network, since an internal certificate or a split DNS view can make it succeed where a sending server would fail.

Read the enforcement mode in the file: testing mode is a valid configuration and is not enforcement.

Compare the exchanger list in the file against the MX records published in DNS.

`email.mta_sts.record` retrieves the DNS record and reads its identifier.

`email.mta_sts.policy` fetches the policy file over HTTPS and reads the exchanger list, the mode and the lifetime — a record with no fetchable file is reported as that specific defect rather than as MTA-STS being absent.

`email.tls_rpt` reports the TLS reporting record, which is independent and worth publishing on its own.

`email.mx.present` supplies the published exchangers the policy's list is compared against.

`transport.certificate_coverage` is the neighbouring check, since the certificate covering the policy hostname is what most often decides whether the fetch succeeds.

The policy file declares how long a sending server may cache it, and that duration is how long a mistake keeps being applied.

A long lifetime with an enforce mode and a wrong exchanger list means mail is refused for that period by every sender holding the cached copy.

Shortening the lifetime after publishing does not help, for the same reason lowering a DNS record lifetime after a change does not: the cached copy carries the old value.

So a short lifetime during a rollout and a longer one once the configuration is proved is the order that works.

Withdrawing a policy is done by publishing one in none mode rather than by deleting the record, so servers holding a cached copy stop applying it.