What happens if the MTA-STS policy host does not resolve?

RFC 8461 section 3.3 says that if a valid TXT record is found but no policy can be fetched over HTTPS and no unexpired cached policy exists, senders MUST continue with delivery as though the domain has not implemented MTA-STS.

Is publishing the _mta-sts TXT record enough?

No. The TXT record only announces that a policy exists. Without the policy file served over HTTPS at the policy host, RFC 8461 has senders behave as though MTA-STS was never implemented.

What certificate does the MTA-STS policy host need?

RFC 8461 section 3.3 requires an X.509 certificate valid for the mta-sts DNS-ID, meaning the policy host name itself. A wildcard is allowed as the complete left-most label, so *.example.com covers it and a certificate for example.com alone does not.

How do I check MTA-STS end to end?

Query the TXT record at _mta-sts.example.com, resolve mta-sts.example.com, then fetch https://mta-sts.example.com/.well-known/mta-sts.txt and confirm it returns HTTP 200. Redirects do not count: RFC 8461 says 3xx MUST NOT be followed.

MTA-STS is published but the policy host does not exist

MTA-STS has two parts. A TXT record that says a policy exists, and an HTTPS file that holds it. Many domains publish the first and never build the second.

The TXT record lives at _mta-sts.example.com. The policy lives at https://mta-sts.example.com/.well-known/mta-sts.txt. A checker that reads only DNS marks the domain green.

What the standard says

RFC 8461, section 3.3:

If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.

So the TXT record on its own buys nothing.

If you also publish TLS-RPT (RFC 8460), a failed policy fetch is one of the result types a report can carry. The name is sts-policy-fetch-error, defined in RFC 8460 section 4.3, so the failure is visible to you if anyone reports.

Check it yourself

dig +short TXT _mta-sts.example.com
dig +short A   mta-sts.example.com
curl -sI https://mta-sts.example.com/.well-known/mta-sts.txt | head -1

If the first prints v=STSv1 and the second prints nothing, the policy host does not resolve. If the second prints an address but the third does not print a 200 status, the host exists but serves no policy.

The fix

Create an A or CNAME record for mta-sts.example.com pointing at a web host, serve the policy at /.well-known/mta-sts.txt as text/plain, then change the id= value in the TXT record so senders fetch the new policy.

The certificate matters. RFC 8461 section 3.3 says the policy host MUST present an X.509 certificate that is valid for the mta-sts DNS-ID, so the certificate has to cover mta-sts.example.com itself. The same section allows a wildcard as the complete left-most label, so *.example.com works and a certificate for example.com alone does not.

Two more constraints from the same section: the fetch is only valid on HTTP 200, and 3xx redirects MUST NOT be followed. A policy host that redirects to a CDN path will not work.

If you cannot host the file yet, remove the TXT record until you can. An announced policy that cannot be fetched is not a policy.

Run your domain audit at audit.humerly.com. No signup, no card.