MTA-STS checker

The DNS record announces that the domain publishes a policy and carries an identifier that changes when the policy changes. Sending servers use that identifier to know whether their cached copy is stale.

The policy file is served over HTTPS from a fixed host and path under the domain. It lists the mail exchanger names the domain expects and states the enforcement mode.

The file must be served over a valid certificate. A sending server that cannot validate it does not fall back to fetching it insecurely — it treats the policy as unavailable.

So MTA-STS depends on a web server's TLS being correct in order for mail delivery to be protected, which is an unusual coupling and a real operational consideration.

Testing mode asks sending servers to report failures without changing delivery. This is the mode to publish first, and it is where TLS-RPT earns its place.

Enforce mode asks sending servers to refuse delivery to an exchanger that does not match the policy or does not present a valid certificate.

None is the mode used to withdraw a policy deliberately, so that servers holding a cached copy stop applying it rather than continuing until it expires.

Moving to enforce with an exchanger list that is wrong is the failure that matters: mail stops arriving from every sender that honours the policy, and those are the well-run ones.

The exchanger names in the policy file must cover the exchangers published in DNS. An MX not listed in the policy is refused under enforce mode.

The identifier in the DNS record must change whenever the file changes, otherwise servers keep serving themselves a cached policy that no longer reflects reality.

The policy's lifetime governs how long a cached copy is honoured, which is also how long a mistake takes to stop being applied.

This is the check's real value: the two halves are edited in different systems, by different people, at different times, and nothing warns when they drift.

TLS-RPT is a separate DNS record naming an address that receives reports about failed TLS connections to your mail exchangers.

It is what makes testing mode useful: without it, a testing policy produces no observable information and the rollout has nothing to be steered by.

The reports also catch problems MTA-STS itself does not cause — an expired certificate on an exchanger, a downgrade attempted on the path.

It is independent of MTA-STS and worth publishing on its own, which is why it is reported separately rather than as part of the policy.

`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.

`email.tls_rpt` retrieves the TLS reporting record. `email.mx.present` supplies the published exchangers the policy is compared against.

A record with no reachable policy file is reported as the specific defect it is, rather than as MTA-STS being absent.

The policy file is fetched as any sending server would fetch it. Whether a given sender honours it is outside a DNS and HTTPS query.

No SMTP connection is opened, so the certificates the exchangers themselves present are not validated here — that is what the TLS reports cover over time.

Whether the reporting address accepts reports is not tested.

A policy in testing mode is reported as testing. It is a correct configuration and not an enforcement, and the difference is the whole point of the mode.