[ Transport security ]
MTA-STS for domains with multiple MX providers
Validate primary, backup and migration MX routes across providers, including hostname patterns, TLS evidence and cached-policy transitions.
By the EmailAuth research team · 8 min read
[ Key points ]
- The policy must cover every intended receiving candidate, including rarely used backups.
- MX pattern matching and SMTP certificate validation are separate checks.
- Coordinate provider migration with HTTPS publication, discovery updates and existing policy caches.
[ Takeaway ]
Own one complete receiving-route matrix across suppliers, verify each candidate and keep old policy expectations viable during a controlled transition.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Test the backup before it is needed
Routine successful delivery may never exercise a lower-priority candidate.
Next steps
- Inventory all authoritative MX targets and preferences.
- Match each hostname against the approved policy.
- Retain per-candidate STARTTLS and certificate evidence.
CISO / SecOps
Review exact accepted hosts
A broad wildcard can expand authority while still missing deeper names.
Next steps
- Validate one-label wildcard behavior.
- Separate policy-host and receiving-MTA certificates.
- Review enforcement and cached-policy failure handling.
Founder / Non-technical
Coordinate both provider owners
A backup route is a business dependency, not just another DNS value.
Next steps
- Assign primary and backup service owners.
- Approve migration overlap and route retirement.
- Require evidence before enforcement or provider removal.
[ FAQs ]
Frequently asked questions
Does adding an mx line create a new delivery route?
No. DNS MX records supply candidates; MTA-STS validates acceptable hostnames and transport. A policy entry does not create a DNS MX record or alter its preference.
Must each permitted MX pattern have its own line?
Yes. RFC 8461 requires a separate mx key/value line for each pattern. Use supported exact names or one-label wildcard patterns.
Does *.mail.example match mx.region.mail.example?
No. The wildcard matches the entire leftmost label only. It matches mx.mail.example, not the base mail.example or a name with two additional labels.
Does a policy hostname match prove the backup is ready?
No. The candidate must also support STARTTLS and present a valid trusted certificate matching its MX hostname under the specification’s rules.
Why can a broken backup remain unnoticed?
Normal candidate traversal may deliver successfully to the primary before a sender encounters the backup. Explicit approved backup checks are therefore useful.
Can I move MX before cached policies allow the new provider?
That can delay delivery from senders applying an older enforce policy. Plan overlap and account for discovery TTL and previously served policy lifetimes.
Does testing mode provide the same enforcement as enforce?
No. Testing mode can report policy failures through TLS-RPT where supported, while delivery may proceed as though the validation failure did not occur.
Do clean TLS reports prove every MX candidate works?
No. Reports reflect participating senders’ observed attempts. Low traffic and an unused backup can leave important routes unobserved.
[ 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
- MX candidate
- A receiving host considered during the sender’s normal SMTP delivery traversal.
- Policy pattern
- An exact hostname or supported leftmost-label wildcard used to validate an MX candidate.
- Migration overlap
- A planned period during which intended old and new routes remain compatible with policy history.
- TLS-RPT coverage
- The set of delivery observations actually represented by participating senders’ reports.
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