[ Transport security ]
MTA-STS for a large domain portfolio
Manage per-domain receiving routes, ownership, policy history and rollout evidence without treating shared hosting or templates as universal readiness.
By the EmailAuth research team · 8 min read
[ Key points ]
- Classify receiving domains and subdomains individually and assign accountable owners.
- Shared policy hosting still needs correct per-hostname certificates and content.
- Use evidence-based rollout waves and per-domain cache history for changes and retirement.
[ Takeaway ]
Centralize the workflow while preserving each domain’s policy boundary, approved route and evidence state.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Maintain the domain-to-policy map
Generated files do not prove deployed DNS and HTTPS state.
Next steps
- Track exact policy hosts, MX lists and content digests.
- Validate rendered output per domain.
- Keep historical modes, lifetimes and last-served times.
CISO / SecOps
Expose exceptions instead of averages
A portfolio success rate can hide a critical domain with unknown ownership.
Next steps
- Require explicit owners and exception decisions.
- Review wildcard scope and delegated-policy dependencies.
- Keep testing, reporting and enforcement status distinct.
Founder / Non-technical
Roll out by business readiness
Shared suppliers do not eliminate domain-specific consequences.
Next steps
- Classify active receiving services and unresolved names.
- Choose waves with accountable owners.
- Approve critical-domain transitions separately when needed.
[ FAQs ]
Frequently asked questions
Does example.com policy automatically cover mail.example.com?
No. Compliant senders delivering to a recipient subdomain do not use the parent’s policy as a fallback. Track each receiving policy domain separately.
Can every policy host redirect to one central URL?
Not as the MTA-STS fetch mechanism. RFC 8461 forbids following HTTP redirects. Each required endpoint must deliver the policy directly with valid HTTPS.
Can a shared service host different domain policies?
Yes as an architecture, provided each required hostname, certificate and served policy satisfy the protocol. The register must map each hostname to its approved content.
Should every registered domain be marked ready for enforcement?
No. First establish receiving function, routes and accountable ownership. An unresolved domain remains a hold in the proposed portfolio workflow.
What does a policy-file digest add?
It lets the proposed acceptance process compare served bytes with the approved domain-specific artifact rather than checking only endpoint status.
Does publishing TLS-RPT switch a domain to enforce?
No. Reporting is a separate policy and delivery mechanism. MTA-STS mode determines its validation-failure behavior.
Why retain older policy max_age values?
Previously served policies can remain cached, including older versions with longer lifetimes. Retirement planning must account for that history rather than only the current file.
Can I retire MTA-STS by deleting its TXT record and endpoint?
Not as a safe immediate opt-out. RFC 8461 describes signaling mode none and retaining publication until previously served policies have expired.
[ Sources ]
Sources
- RFC 8461: SMTP MTA Strict Transport Security
Sections §3. Policy Discovery · §3.2 MTA-STS Policies · §3.3 HTTPS Policy Fetching · §3.4 Policy Selection for Smart Hosts and Subdomains · §4.1 MX Host Validation · §4.2 Recipient MTA Certificate Validation · §5. Policy Application · §8.1 Policy Updates · §8.2 Policy Delegation · §8.3 Removing MTA-STS · §8.4 Preserving MX Candidate Traversal
- RFC 8460: SMTP TLS Reporting
Sections §3. Reporting Policy · §4. Reporting Schema · §5. Report Delivery
[ Glossary ]
Glossary
- Policy domain
- The domain used for MTA-STS discovery and policy application for the relevant delivery route.
- Portfolio register
- The proposed per-domain inventory of ownership, route, policy intent, evidence and lifecycle.
- Rollout wave
- A reviewed group of domains advanced together based on their readiness evidence.
- Policy history
- Previously served policy content and lifetime information retained to reason about sender caches.
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