[ Transport security ]
Publish and rotate TLSA records without breaking SMTP delivery
Plan fixed-parameter TLSA rollover with prepublication, cache-aware overlap, fleet verification and a recovery boundary before removing old associations.
By the EmailAuth research team · 8 min read
[ Key points ]
- Identify whether the change replaces a key, certificate, trust anchor or TLSA parameters.
- For fixed-parameter rollover, prepublish old and new associations at least two TTLs before deployment.
- Retire old associations only after active service and rollback dependencies are understood.
[ Takeaway ]
Coordinate DNS and SMTP operators around a verified overlap, then deploy and retire in stages without confusing a saved certificate with a safe rollback.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Verify each rollover stage
A successful deployment job does not prove every SMTP instance presents the intended key.
Next steps
- Capture the secure baseline and full TLSA tuple.
- Prepublish the expanded set and record timing.
- Verify each active instance before retiring old data.
CISO / SecOps
Keep public evidence separate from key custody
The DNS plan needs associations, not private keys.
Next steps
- Review usage and parameter changes explicitly.
- Maintain currently matching records for each published combination.
- Treat DNSSEC validation as an independent gate.
Founder / Non-technical
Coordinate the maintenance dependency
DNS caches and staggered server deployment can outlive a maintenance window.
Next steps
- Assign both publication and SMTP owners.
- Approve a justified overlap and recovery plan.
- Require evidence before the final retirement step.
[ FAQs ]
Frequently asked questions
Does every certificate renewal change a 3 1 1 record?
No. That association selects the public key, so renewal using the same key can preserve it. Verify the actual key rather than assuming automation reuses it.
How early should new fixed-parameter associations be published?
RFC 7671 specifies augmenting the old set at least two TTLs, or longer, before deploying the new chain. Preserve the current association during overlap.
Can lowering TTL immediately shorten old cached data?
No. Copies already cached under the previous TTL need their own timing consideration. Record the actual publication and cache history.
Can I publish only future data under one parameter combination?
The publisher guidance requires a currently matching association for each published usage/selector/matching-type combination. Future or retired records cannot be the only ones for that combination.
When can obsolete associations be removed?
After the new chain is deployed and verified and the old association no longer describes an active dependency. Review backups and rollback requirements before removal.
Is restoring the old certificate always a safe rollback?
No. Some clients may have a new-only TLSA set cached after retirement. Assess current published data and cache history before reverting the server.
Can I apply the same sequence when changing usage or selector?
Do not assume so. Parameter transitions require the corresponding RFC 7671 guidance and compatibility review, separate from fixed-parameter key rollover.
Does no TLS-RPT failure prove rollover succeeded?
No. Reporting is optional, aggregate and delayed. Retain direct authorized secure-DNS and SMTP evidence for the actual fleet.
[ Sources ]
Sources
- RFC 1035
Sections §3.2.1 Format · §3.3.13 SOA RDATA format
- RFC 8460
Sections §3. Reporting Policy · §4.1 Report Time Frame · §4.3 Result Types · §5.2 Compression · §5.3 Email Transport · §5.4 HTTPS Transport · §5.5 Delivery Retry · §5.6 Metadata Variances · §7. Security Considerations
- RFC 7672
Sections §2.1 DNS Considerations · §2.2 TLS Discovery · §2.2.1 MX Resolution · §2.2.3 TLSA Record Lookup · §3.1 TLSA Certificate Usages · §3.2 Certificate Matching · §4. Server Key Management
- RFC 7671
Sections §6. Service Provider and TLSA Publisher Synchronization · §7. TLSA Base Domain and CNAMEs · §8. TLSA Publisher Requirements · §8.1 Key Rollover with Fixed TLSA Parameters · §8.3 Switching to New TLSA Parameters
- RFC 6698
Sections §2.1 TLSA RDATA Wire Format · §3. Domain Names for TLSA Certificate Associations
[ Glossary ]
Glossary
- Prepublication
- Publishing associations for a future key while preserving the current associations before switching the service.
- Association overlap
- A TLSA set that supports the required current and transitional key material.
- Fixed parameters
- Unchanged certificate usage, selector and matching-type combinations during a key rollover.
- Rollback boundary
- The point at which published and cached new-only data can make a return to the old server key unsafe without further coordination.
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