mta-sts policy fetch failed and tls-rpt reports show starttls errors for inbound mail

TL;DR

Make the published policy fetchable and true: host the mta-sts.txt file at the exact well known address on the policy subdomain, confirm the _mta-sts DNS record version matches the file, and check that the MX hosts named in the file present valid certificates for their hostnames. TLS-RPT starttls errors usually mean senders could not fetch the policy, could not match the MX pattern, or hit a certificate they could not trust, and each cause has a different fix.

mta-sts policy fetch failed and tls-rpt reports show starttls errors for inbound mail

Use this when

• TLS-RPT aggregate reports show starttls errors or policy fetch failures for your domain.
• You publish MTA-STS in testing or enforce mode.
• Senders report opportunistic TLS falling back or failing to your MX hosts.

Not for this skill when

• One sending organisation cannot do TLS with anyone. That is their mail stack, not your policy.
• Your MX host certificate expired for all connections. Renew it as a mail outage first, then recheck MTA-STS.

Steps

1. Fetch the policy file yourself from outside your network using the exact HTTPS address senders will use, and save the response. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the file is reachable externally with a valid certificate and the expected content
2. Compare the file contents line by line with your live MX records: mode, max_age, and every mx pattern. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: every live MX host is covered by a pattern in the file
3. Check the _mta-sts TXT record id value and confirm you bump it whenever the file changes so senders refetch. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the DNS id differs from the previous published version after a file change
4. Connect to each MX host and verify the presented certificate matches the host name and is in date. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: each MX host presents a matching, in date certificate
5. Watch TLS-RPT reports over the following days for the error classes you fixed. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: new reports show successful TLS sessions and the starttls error counts fall

Why it happens

MTA-STS lets a domain publish how senders must encrypt to its MX hosts, but the policy only works if three separate systems agree: the HTTPS file, the DNS pointer, and the mail hosts themselves. HTTPS hosting faults, a stale cached policy after an MX change, or a certificate issued for the wrong name all surface in TLS-RPT as starttls failures. The reports are the sender telling you which leg broke, so read the failure type before changing anything.

Variants and edge cases

mta-sts policy fetch failed tls-rpt starttls errors inbound

The report wording pairing the fetch and the TLS error.

mta-sts txt file not fetched well known https hosting fix

The hosting variant for the policy file itself.

tls-rpt reports show starttls failure mx certificate mismatch

The certificate variant read from report details.

Compatibility: RFC 8461 MTA-STS, RFC 8460 TLS-RPT, major sender implementations including Gmail and Microsoft 365.

Edge cases to check:

• Senders cache policies up to max_age; a fix can take days to be seen by every sender, which is normal in enforce mode rollouts.
• Start in testing mode and read reports for at least a week before moving a domain to enforce.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4TEn97xE6iYGl4zFhTdtw