[ Transport security ]
MTA-STS explained through the receiving domain's mail route
Map receiving MX destinations, TLS requirements and cached policy before selecting an MTA-STS enforcement mode.
By the EmailAuth research team · 8 min read
[ Key points ]
- Inventory every legitimate receiving MX, including backups.
- Separate discovery, HTTPS policy and SMTP validation.
- Plan enforcement around cached policies and actual route evidence.
[ Takeaway ]
Map receiving MX destinations, TLS requirements and cached policy before selecting an MTA-STS enforcement mode.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Verify the full receiving route
A configuration screen is not end-to-end evidence.
Next steps
- Record exact DNS and policy artifacts.
- Check each relevant endpoint independently.
- Preserve timestamps and controlled acceptance results.
CISO / SecOps
Review enforcement and cached-policy risk
Transport policy changes need a compatible recovery plan.
Next steps
- Review certificates and permitted MX patterns.
- Account for prior cached policies.
- Separate transport results from message authentication.
Founder / Non-technical
Protect incoming-mail continuity
Publication must have accountable service ownership.
Next steps
- Assign DNS, mail and hosting owners.
- Include backup routes and renewal responsibility.
- Require acceptance evidence before enforcement.
[ FAQs ]
Frequently asked questions
Does MTA-STS select a different mailbox provider?
No. MX still supplies the receiving route. The policy constrains acceptable MX hosts and TLS behavior; it does not provision or redirect mailboxes.
Which domain determines discovery?
Use the receiving policy domain, ordinarily the recipient domain, not the visible From domain of an unrelated outgoing message.
Is the TXT id the entire policy?
No. It signals the policy revision. The policy content is retrieved through the prescribed HTTPS endpoint.
Does *.example.net match a.b.example.net?
No. The wildcard matches the complete leftmost label only; it does not authorize deeper names or the bare suffix.
Does a matching MX name prove TLS works?
No. The receiving server must also satisfy STARTTLS and certificate-validation requirements.
Is testing the same as enforce?
No. Testing supports observation without the policy-failure blocking behavior requested by enforce.
Does deleting the file instantly remove enforcement?
No. Senders may retain previously fetched policies for their cache lifetime. Plan the transition with prior max_age values.
Are TLS reports proof that every route works?
No. Reports are a separate mechanism and coverage depends on participating senders. Direct route acceptance remains necessary.
[ Sources ]
Sources
[ Glossary ]
Glossary
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.
SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption