Locate the missing step before adding records
A warning that an MTA-STS policy is missing describes a discovery outcome, not a diagnosis. The receiving domain may lack its discovery record, publish several competing records, serve the wrong HTTPS resource, or already have a policy that one sender cannot retrieve. Creating another TXT record before separating these cases can make a recoverable problem worse. Start with the exact domain and the evidence behind the warning.
This is a documentary investigation plan. No DNS lookup, policy download from a customer host, SMTP connection or provider change was performed. The worked case below is fictional. An operational conclusion requires timestamped observations from the relevant infrastructure and, where available, the reporting sender's policy state.
Establish the policy domain
For ordinary delivery to a mailbox at example.com, discovery begins at _mta-sts.example.com. The policy is fetched from https://mta-sts.example.com/.well-known/mta-sts.txt. A mailbox at a subdomain requires discovery for that subdomain; compliant senders must not fall back to the parent's policy. An administratively configured smart host introduces a different policy-domain choice, so record whether the investigation concerns direct delivery or a relay. RFC 8461 sections 3.1–3.4
Ask the owner of the warning for its timestamp, queried name, record type and complete result. A screenshot saying “missing” cannot distinguish a nonexistent name, a successful answer containing no usable record, or a timeout. Retain both authoritative and recursive observations when later authorized. DNS negative caching can preserve an earlier absence, so the current control-panel display does not explain every resolver's answer. RFC 2308
Evaluate the complete discovery answer
The discovery record begins with v=STSv1; and includes an id identifying a policy instance. The identifier signals a change; it does not contain the policy or impose a chronological ordering. After records without the required version prefix are discarded, exactly one usable record must remain. Multiple matching TXT records are therefore a possible cause of failed discovery, not a reason to add a third. RFC 8461 section 3.1
Preserve record boundaries. Several quoted character strings within one TXT record are concatenated without inserted spaces; several TXT records remain separate records. Follow any discovery CNAME chain and retain the target answer. RFC 8461 permits that delegation. A DNS provider's editing interface may display these cases similarly, so compare the actual response with the intended configuration before proposing a write. RFC 8461 section 3.1
Trace HTTPS retrieval separately
A valid discovery record leads to the fixed HTTPS policy location. The service must present a trusted, unexpired certificate valid for the policy host. A valid fetch requires HTTP 200; redirects must not be followed. A browser that silently follows a redirect can therefore make a broken endpoint appear healthy. Capture the first response status and original URL rather than only the page eventually displayed. RFC 8461 section 3.3
Inspect the returned body as policy text. Check the version, mode, maximum age and required MX entries against the grammar. Senders should validate the text/plain media type. A login page or branded error document returned with status 200 has not become a usable policy. The syntax permits repeated MX fields; duplicate singleton fields are handled differently, so retain the original bytes instead of silently normalizing them. RFC 8461 section 3.2
Keep discovery separate from delivery validation
Once a policy has been obtained, compare its MX patterns with the actual candidate hostnames. The permitted wildcard covers one complete leftmost label, not arbitrary levels. Then evaluate STARTTLS and the receiving server's certificate for the selected MX host. Those are different checks from validating the certificate on the HTTPS policy service. A successful policy download does not certify the mail servers. RFC 8461 sections 4.1–4.2
Also record sender cache state. Failure to discover or fetch a live policy does not erase a valid, unexpired cached policy. Conversely, a sender with no usable cached policy and an unsuccessful HTTPS fetch proceeds as though the domain has not implemented MTA-STS. That statement concerns MTA-STS only; another applicable transport policy can still constrain delivery. RFC 8461 section 3.3
Work through a fictional duplicate record case
Suppose a fictional example.com operator sees a “policy missing” warning after changing hosting providers. The proposed evidence packet contains two separate discovery TXT records, one with id=old1 and one with id=new2, both beginning with the valid version prefix. The HTTPS endpoint is assumed to serve a correct testing policy. These are invented observations, not results collected here.
Under the discovery rule, the two surviving records prevent selection of an available policy. The plausible repair is to identify the intended current record and review removal of the obsolete duplicate, not recreate the HTTPS service. That proposal still needs ownership and change approval. A subsequent trace would verify one discovery record, the intended HTTPS body and MX coverage. An old sender cache could produce different behavior until its policy state changes.
Finish with a bounded rollout decision
If the investigation supports a new deployment, prepare a controlled testing-to-enforce plan. Identify all intended MX hosts, including backups, establish HTTPS availability and arrange TLS-RPT collection. In testing mode, MTA-STS validation failures may be reported without requiring the sender to block delivery. A quiet reporting mailbox is not sufficient readiness evidence. RFC 8461 sections 5–6
When a policy body changes, publish the HTTPS body before changing the discovery identifier and account for DNS TTLs and existing caches. Keep the original trace, proposed difference and rollback owner together. Current RFC 8461 errata were checked separately; reported proposals have not been treated as approved replacements. The missing DNS-to-HTTPS-to-MX trace and controlled rollout evidence remain explicit release gates. RFC 8461 section 8.1 Current errata