[ Transport security ]

MTA-STS policy discovery and the DNS policy identifier

Use the DNS id to announce a policy revision, without treating it as the policy itself or a command that clears sender caches.

By the EmailAuth research team

[ Key points ]

  • Use the actual recipient or configured smart-host policy domain.
  • Keep one selected discovery TXT record and preserve its string boundaries.
  • Publish the HTTPS body before announcing a new id.
On this page

MTA-STS discovery starts at _mta-sts followed by the policy domain. For mail addressed to user@example.com, the ordinary discovery owner is _mta-sts.example.com. The TXT value advertises support and a revision identifier; the actual policy is fetched separately over HTTPS.

Follow the recipient domain precisely

References: RFC 8461 §3.1, RFC 8461 §3.4.

A message to user@mail.example.com uses mail.example.com as its policy domain rather than inheriting the parent example.com policy. RFC 8461 also gives special handling for administratively configured smart hosts: the smart-host domain becomes the policy domain. Record which routing situation you are testing before interpreting an absent record.

The TXT record must begin with v=STSv1 and include an id of 1–32 ASCII letters or digits. The identifier uniquely identifies an instance of a policy. It has no implied ordering: 20261107B is a convenient operational label, not a time protocol or an instruction to accept only larger numbers.

Count records rather than screen rows

References: RFC 8461 §3.1, RFC 8461 §8.2.

If multiple TXT records are returned, discovery discards records that do not begin with v=STSv1;. Exactly one applicable, syntactically valid record must remain. Two independent MTA-STS records are not a safe rollover mechanism. Multiple strings inside one TXT resource record are concatenated without adding spaces.

CNAME discovery is allowed and can follow a chain to the TXT record. Retain the owner and alias chain in the evidence. Discovery delegation does not remove the requirement for HTTPS policy retrieval under the receiving domain's policy hostname.

Reproduce discovery failures

In an isolated DNS fixture, return one record containing v=STSv1; id=A1 and an unrelated verification TXT record. The intended selection retains one MTA-STS candidate. Add a second independent v=STSv1; id=A2 record and the result is no available policy discovered through that answer. Then split the original record into two strings, v=STSv1; and a space followed by id=A1, and verify concatenation restores one valid value.

Query the absolute owner _mta-sts.example.test. with type TXT against each lab authority and a lab recursive resolver, saving status, record boundaries and TTLs. This procedure is specified, not an executed public DNS test. The supplied local fixture was rerun for this review and exercises candidate-count logic only; it is not a DNS resolver or a full discovery parser.

Update HTTPS before the announcement

References: RFC 8461 §3.3, RFC 8461 §5.1, RFC 8461 §8.1.

Publish and verify the new policy body first, then change the id. Otherwise a sender can observe the new id while still fetching the old body. Keep old routes usable during the transition. Missing or unusable discovery does not erase a valid non-expired cached policy, and an id change is not a guaranteed immediate fetch by every sender. Treat DNS and sender caches as separate parts of the change.

Retained historical evidence and remaining scope

The following is the retained 7 November 2026 lab record, inspected but not rerun as a network experiment for this review. New offline fixture execution is recorded separately.

A captured logical timeline begins with A1 published and fetched at epoch 1000000: enforce, old MX only, max_age 86400, sender expiry 1086400. A1 was modelled as last served at 1000300, so another sender fetching at that boundary could retain it until 1086700. B2 was published at 1000300 with old and new MX patterns and max_age 3600; its modelled last-served time 1000600 yields expiry 1004200. C3 at 1000600 permits only new, with last-served time 1000900 and expiry 1004500. These are explicit synthetic times, not observed internet events. The retained 7 November trace records that the lab changed its DNS response to B2 and fetched the dual-MX body over HTTPS. An assertion preserved the earlier A1 cache unchanged; old remained allowed and new remained disallowed there, while the fresh B2 body allowed new. Thus an identifier announcement and a successful new fetch do not by themselves mutate another cached snapshot.

[ Takeaway ]

Publish the HTTPS body before announcing a new id.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Inspect record boundaries

Duplicate policies differ from several string fragments in one record.

Next steps

  1. Query exact recipient domains.
  2. Inspect TXT record boundaries.
  3. Verify HTTPS before the id change.

CISO / SecOps

Track delegated influence

Discovery aliases create dependencies that need ownership.

Next steps

  1. Review delegated discovery ownership.
  2. Preserve previous policy lifetimes.
  3. Distinguish absent discovery from absent enforcement.

Founder / Non-technical

Own both halves of discovery

A revision announcement and the served policy must remain coordinated.

Next steps

  1. Own both publication endpoints.
  2. Keep revision history.
  3. Avoid an assumed instant rollback.

[ FAQs ]

Frequently asked questions

Is id the policy hash?

No. It is a short revision identifier chosen by the operator.

RFC 8461 §3.1

Must ids increase numerically?

No ordering is defined.

RFC 8461 §3.1

Can id contain a hyphen?

The specified id grammar permits only ASCII letters and digits.

RFC 8461 §3.1

Can two STS TXT records coexist?

Not as a valid discovery result; exactly one applicable record must remain.

RFC 8461 §3.1

Can discovery follow a CNAME?

Yes. RFC 8461 requires following the discovery alias chain.

RFC 8461 §3.1

Does a subdomain inherit the apex policy?

No. Discover policy for the actual recipient subdomain.

RFC 8461 §3.4

Which change comes first?

Publish the HTTPS body before changing the DNS id.

RFC 8461 §8.1

Does deleting id clear caches?

No. A valid cached policy can still apply.

RFC 8461 §3.3

[ Sources ]

Sources

  1. RFC 8461

    Sections §2 · §3.1 · §3.3 · §3.4 · §5.1 · §8.1 · §8.2

[ Glossary ]

Glossary

Policy domain
Domain used for the applicable transport-policy discovery.

RFC 8461 §2

Policy id
Short identifier announcing a particular MTA-STS policy instance.

RFC 8461 §3.1

TXT resource record
One DNS record that may contain multiple string fragments.

RFC 8461 §3.1

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base