Rotating an SMTP certificate is usually a routine maintenance task. Rotating a certificate on a DANE-protected MX is different because the certificate and the DNS TLSA record are two halves of the same authentication decision.
Change the service first and a sender with cached TLSA data can reject the new certificate. Change DNS first and a sender that learns the new association can reject a node that still serves the old certificate. If DNSSEC also becomes invalid during the change, DANE-aware senders may stop using the host and defer mail rather than silently downgrade.
The safe procedure is an overlap procedure:
This is a maintenance guide for inbound SMTP DANE. For the initial deployment, see How to deploy DANE for SMTP with DNSSEC and TLSA. For the choice between DANE and MTA-STS, see DANE vs MTA-STS for SMTP.
DANE for SMTP uses a DNSSEC-validated TLSA RRset below the actual MX hostname. For mx1.example.com, the normal owner name is:
_25._tcp.mx1.example.com.A DANE-aware sending MTA retrieves that RRset, validates the DNSSEC chain, and compares the certificate presented during the SMTP STARTTLS handshake with one or more TLSA associations. A usable, secure TLSA RRset commits the sender to TLS and authentication for that host. If no association matches, the sender skips the host or delays delivery rather than accepting a different certificate.
That decision is made from data that may have been cached at different times. Consider this sequence:
Publishing both associations does not retroactively update a cache that already contains only the old RRset. The new association must be published early enough for those old-only cache entries to expire before the server stops presenting the old certificate.
The reverse mistake is also possible. If the new certificate is deployed first and the new TLSA association is published afterward, senders with the old association fail until the new DNS data is learned. Both mistakes create a failure that may look like an ordinary TLS problem but is actually a DNS and certificate sequencing problem.
Do not start with the certificate inventory. Start with the MX inventory. List every MX target and every address that can reach the SMTP service:
For example:
example.com. IN MX 10 mx1.example.com.
example.com. IN MX 20 mx2.example.com.The corresponding TLSA records are normally separate RRsets:
_25._tcp.mx1.example.com. IN TLSA ...
_25._tcp.mx2.example.com. IN TLSA ...The certificate on mx1 does not authenticate mx2. A backup MX with a stale certificate can become the only available path when the primary is unavailable, so it belongs in the same change plan. Test IPv4 and IPv6 separately. A common operational failure is a correct certificate on the IPv4 listener and an older certificate on the IPv6 listener.
Also check whether an MX target is an alias or whether a provider publishes TLSA records in a different zone. RFC 7671 describes TLSA base-domain handling and the coordination required when a service provider operates the certificate while another party publishes DNS. A provider-managed certificate process must have a reliable way to publish the matching association before changing the live service.
A TLSA record has four fields:
certificate usage selector matching type association dataThe first three fields determine what the final value means. The association data must be generated from the selected certificate material in DER form, not from the text of a PEM file.
The four original usages defined by RFC 6698 are:
| Usage | Name | What it constrains |
|---|---|---|
0 | PKIX-TA | A PKIX chain must contain the published CA certificate or key. |
1 | PKIX-EE | The presented end-entity certificate must match and pass normal PKIX validation. |
2 | DANE-TA | The published certificate or key is the trust anchor for the chain. |
3 | DANE-EE | The presented end-entity certificate must match the published association. |
For ordinary opportunistic DANE SMTP, RFC 7671 recommends DANE-EE(3) or DANE-TA(2) rather than the PKIX usages. DANE-EE(3) is often the simplest operational choice because DNSSEC authenticates the association directly and the certificate does not need to chain to a public CA. With DANE-EE(3), the TLSA binding, rather than a certificate hostname check, supplies the identity association. Keeping the MX hostname in the certificate SAN is still sensible for interoperability, diagnostics, and non-DANE clients.
PKIX-EE(1) and PKIX-TA(0) add public-PKI requirements. They can be appropriate when that is deliberate, but a certificate renewal may fail because of an unexpected chain, name, expiry, or trust-store difference even though the TLSA digest itself is correct.
DANE-TA(2) can reduce the number of TLSA changes when many certificates are issued by one stable CA. It has its own chain requirements: when the TLSA record is a digest rather than a full CA certificate, the relevant trust-anchor certificate normally needs to be sent in the server's certificate chain. A CA rollover therefore needs both a chain plan and a TLSA overlap plan.
Do not change certificate usage as part of an ordinary certificate renewal unless there is a reason to change the trust model. A key rollover and a trust-model migration are separate changes with different compatibility risks.
The selector says what bytes are selected before matching:
| Selector | Meaning | Rotation consequence |
|---|---|---|
0 | The complete DER-encoded certificate | A new certificate normally requires a new association, even if the key is unchanged. |
1 | The DER-encoded SubjectPublicKeyInfo | A certificate renewal can reuse the association if it keeps the same public key. |
The word selector here has nothing to do with a DKIM selector. It identifies certificate material for TLSA matching.
The matching type says how the selected bytes are represented:
| Matching type | Meaning |
|---|---|
0 | Exact selected data |
1 | SHA-256 digest of the selected data |
2 | SHA-512 digest of the selected data |
3 1 1 means DANE-EE(3), SPKI(1), and SHA-256(1). That combination is commonly recommended because it survives certificate renewal when the public key is reused and SHA-256 is required for interoperability by DANE implementations. RFC 7671 says not to publish SHA-512 as the only digest because clients are not required to support it. Full, unhashed associations are also generally not recommended because they make records larger and can create interoperability problems.
The useful planning question is therefore not simply "is the certificate changing?" Ask instead:
With 3 1 1, a new certificate using the same key normally does not require a new TLSA record. A new key does. With 3 0 1, a new certificate requires a new record even when it contains the old key. With usage 2, a leaf certificate may change without changing the TLSA record when the trust anchor remains the same, but the chain and its deployment still need testing.
TTL is not a propagation command. It is the maximum time a compliant recursive resolver may reuse an answer without asking an authoritative server again. A sender's MTA may also cache the result internally.
Before the change, record:
Use the longest applicable cache interval, then add a safety margin. If the existing TLSA TTL is one hour, an operational schedule should not treat one hour as an exact boundary. Allow for the time at which the old answer was cached, authoritative propagation, signing, resolver behavior, and clock differences.
If lowering the TTL before a planned rotation, lower it and then wait for the old TTL to expire. A record changed from 86400 to 300 can still be held for up to the previous 86400 seconds by a resolver that fetched it just before the reduction. The lower value helps later steps; it cannot flush caches that already exist.
The timing rule for a new key is:
publish new association
wait at least the old association's effective TTL plus margin
change the certificate served by SMTP
observe for the rollback window
remove old association
wait for the old association's cache window before declaring rollback impossibleThe wait before the certificate change is the part most often omitted. It gives senders with an old-only cached RRset time to learn the RRset containing both associations. The wait after the service change allows senders with cached old-plus-new data to complete delivery while the old certificate is still available for rollback or for a node that has not yet been updated.
Do not assume that the new record's TTL is the relevant first wait. The old cached RRset controls how long a sender can remain unaware of the new association.
Generate the new key and certificate independently of the DNS change. Confirm that the certificate is suitable for every SMTP endpoint that will present it, including the expected SANs, chain, key algorithm, and validity period.
Install the new certificate in a staging location or on a canary endpoint. Do not switch the public service yet. Extract the association from the exact material the live server will present.
For an SPKI SHA-256 association, the important operation is to encode the SubjectPublicKeyInfo as DER and hash those bytes. A representative workflow is:
openssl s_client -starttls smtp \
-connect mx1.example.com:25 \
-servername mx1.example.com 2>/dev/null \
| openssl x509 -pubkey -noout > /tmp/mx1-new-public-key.pem
openssl pkey -pubin -in /tmp/mx1-new-public-key.pem -outform DER \
| openssl dgst -sha256For a full-certificate association, obtain the leaf certificate and hash its DER encoding instead:
openssl s_client -starttls smtp \
-connect mx1.example.com:25 \
-servername mx1.example.com 2>/dev/null \
| openssl x509 -outform DER > /tmp/mx1-new-certificate.der
openssl dgst -sha256 /tmp/mx1-new-certificate.derThe commands above inspect a live endpoint. For a not-yet-deployed certificate, run the equivalent extraction against the certificate file that the deployment will install. Use your MTA or DNS provider's documented TLSA generator when it has one, and independently compare the result. Never hash the PEM armor, whitespace, or a certificate chain when the selector calls for the leaf certificate or SPKI.
The following sequence assumes that the certificate changes to a new public key and that the current association is 3 1 1. Adapt the record content for the usage, selector, and matching type actually used by the service.
Capture the current MX, TLSA, certificate fingerprint, DNSSEC status, and service behavior. Save the current signed zone or provider version so that a known-good rollback is available.
Record the old association as OLD_TLSA and the new one as NEW_TLSA in the change ticket. Record the old TLSA TTL and calculate the earliest safe service-change time. Do not rely on memory or on a digest copied from a previous host.
Stage the new certificate and private key on every MX node, but leave the current certificate active. Check permissions, chain order, reload behavior, and the service's choice of certificate when SNI is present or absent.
If a provider cannot stage the certificate without activating it, coordinate a short activation window and do not publish the new TLSA association until the provider can guarantee the exact order. The DNS publisher and service provider must agree on timestamps and the cache budget.
Add the new record to the existing RRset. Do not replace the old record yet:
_25._tcp.mx1.example.com. IN TLSA 3 1 1 OLD_TLSA_DIGEST
_25._tcp.mx1.example.com. IN TLSA 3 1 1 NEW_TLSA_DIGESTThese are alternative associations. A DANE-aware sender succeeds when the presented certificate matches any usable association in the DNSSEC-secure RRset. They are not two pieces that a sender combines into one credential.
The values above are labels for the change procedure, not production digest values. Generate real hexadecimal association data from the exact certificate or SPKI that will be served.
Sign the changed RRset and confirm that all authoritative nameservers serve the same answer. If TLSA is delegated with a CNAME, validate the CNAME chain and the final TLSA RRset as well. A CNAME does not remove the need to validate the DNSSEC path.
Query independent validating resolvers and confirm that the answer contains both records and validates as secure:
dig +dnssec _25._tcp.mx1.example.com TLSA
delv _25._tcp.mx1.example.com TLSADo not treat an RRSIG in the response as proof that validation succeeded. Use a validating resolver and check its validation result. Test all authoritative nameservers directly if they are exposed, then test through recursive resolvers from more than one network.
At this stage the old certificate is still served, so a sender with the old-only RRset continues to work. A sender that has learned the dual RRset can also validate the old certificate. That is the safe state in which to wait.
Wait at least the old TLSA TTL plus the operational margin calculated earlier. If the old RRset had a one-day TTL, wait about a day, not five minutes because the new RRset has a five-minute TTL.
During this wait:
If the DNS provider or signer cannot state when the new signed RRset became visible, use an independent observation window rather than guessing. The goal is to let caches that were populated immediately before publication expire naturally.
After the cache wait, deploy and activate the new certificate and key on all MX nodes. A short, coordinated switch is safer than a long mixed state when the fleet has no way to select the old certificate for an old client.
If a rolling deployment is unavoidable, every node may present either certificate only while both associations are valid and the old-only cache window has elapsed. Keep the overlap RRset active throughout the rolling deployment. Test every node and address family after each batch. Never allow a node to present a certificate that is absent from the currently published TLSA RRset.
Verify the live result from outside the network:
openssl s_client \
-starttls smtp \
-connect mx1.example.com:25 \
-servername mx1.example.com \
-showcertsRepeat the check for every MX hostname, public IP, IPv4 and IPv6 path, load-balancer region, and relevant SNI behavior. Compare the resulting leaf certificate or SPKI with NEW_TLSA_DIGEST.
Do not remove the old TLSA association as soon as the first successful handshake is observed. Keep both associations while:
The right duration depends on the service's retry and incident-response requirements. It should be longer than the time needed to identify a regional or IPv6-only failure, not merely long enough for one local test message.
Once the old certificate is no longer served and the observation window is healthy, remove OLD_TLSA_DIGEST from the RRset. Sign the new RRset and verify it through independent validating resolvers.
Retain the old certificate and key in a protected, documented rollback location until the old association's cache window has passed and the change is accepted. Do not keep an unused private key on a live host indefinitely.
If the old association is removed and a rollback is later required, re-adding it does not instantly repair every sender's cache. Publish and sign it, wait for it to be observable through validating resolvers, then switch the service back. Keeping the old association longer makes rollback faster and safer.
TLSA is only useful when a sender can validate the DNSSEC chain. A valid-looking TLSA response from an unsigned or incorrectly validated path is not equivalent to a secure response.
For a routine TLSA update, the signer must:
Do not combine a TLSA rotation with a DNSSEC KSK or ZSK rollover unless the combined change is unavoidable and the signer has a tested procedure. DNSSEC key rollovers have their own pre-publication, parent DS, signature, and cache timing. A broken DS or expired RRSIG can make the TLSA lookup return bogus or SERVFAIL. Under RFC 7672, a DANE-aware sender must not treat that failure as proof that TLSA is absent and deliver insecurely to the same host.
That behavior is good for downgrade resistance but serious for availability. A DNSSEC failure can cause the sender to skip an MX or defer delivery. Monitor the zone's DS chain, DNSKEY and RRSIG status, signer clocks, authoritative reachability, and consistency across all nameservers. RFC 6781 provides broader operational guidance for keeping DNSSEC chains valid during key and signature changes.
Also distinguish these DNS outcomes:
SERVFAIL: the sender cannot safely determine the TLSA state and should skip the host or defer delivery.Deleting TLSA during an incident is not a universal fix. It can be cached, it changes the security posture, and it may not help a sender that is already holding the previous secure RRset. Repair the certificate, RRset, signer, or delegation that caused the failure whenever possible.
Define the rollback decision before the change. Useful triggers include:
If the dual RRset is wrong but the old certificate is still active, keep serving the old certificate. Correct the new association or remove it from the signed RRset. The old association remains usable, so this is normally the least risky rollback point.
If the old association is still published, restore the old certificate and key on every affected endpoint, verify the old association from outside, and continue serving the old certificate until the problem is understood. Do not remove the new association until the new certificate is no longer served and the incident is closed.
If the old association was already removed, re-add it and wait until the signed record is visible through validating resolvers before restoring the old certificate. A sender cannot match a record it has not yet learned, and a cached new-only RRset may continue to reject the old certificate until it expires.
Do not disable DNSSEC validation or configure a broad cleartext fallback merely to make a queue appear to drain. That can hide an authentication failure and create a different security incident. If a business-approved emergency policy allows temporary unauthenticated delivery, document the scope and expiry, and restore the DANE association as soon as the receiving path is correct.
Certificate-expiry monitoring catches only one failure mode. A DANE rotation needs monitoring across DNS, TLS, and SMTP delivery.
Run frequent external checks for:
Alert when the published association does not match the certificate currently observed on any MX endpoint. That check should run from more than one network and should record the MX hostname, address, certificate fingerprint, SPKI digest, and TLSA result.
Track:
STARTTLS availability on every MX endpointbogus, SERVFAIL, and TLSA lookup errorsA queue alarm is essential. Inbound delivery may not produce an immediate visible error at the receiving site because the sending MTA can queue and retry. A modest increase in queue age is often the first indication that one MX node or one certificate path is failing.
Publish an SMTP TLS Reporting policy if the domain can receive and process the reports:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"RFC 8460 defines aggregate reporting for DANE and MTA-STS results. During a rotation, inspect tlsa-invalid, dnssec-invalid, certificate-host-mismatch, certificate-expired, and general validation failures. A successful-session count is also useful as a heartbeat, but TLS-RPT is not universal telemetry. It depends on the sending MTA supporting the reporting mechanism, so keep local probes and MTA logs.
Use a test matrix rather than one successful message. For every MX host and address family, verify:
| Test | Expected result |
|---|---|
| MX lookup through a validating resolver | The expected MX RRset validates as secure. |
| TLSA lookup during overlap | Both old and new associations validate as secure. |
| TLS handshake before switch | The old certificate matches the old association. |
| TLS handshake after switch | The new certificate matches the new association. |
| Certificate chain and SAN check | The chain is complete for the chosen usage and the hostname is suitable for non-DANE clients. |
| IPv4 and IPv6 connection | Both paths present an allowed certificate. |
| Backup MX delivery | The backup presents its own allowed certificate and accepts queued mail. |
| Deliberately invalid association in a lab | A DANE-aware client rejects the mismatched certificate. |
| Temporary DNSSEC failure in a lab | The client skips or defers the host rather than silently accepting it. |
| Queue recovery | Deferred mail is retried and delivered after the service is repaired. |
| TLS-RPT and local metrics | No unexplained increase in policy or negotiation failures. |
Test the negative cases in a lab or staging environment. A successful handshake proves only that one path worked at one time. It does not prove that every sender sees the same DNS answer, that every node serves the same certificate, or that the sender will queue mail when validation fails.
These failures recur because they violate the sequence rather than because DANE is difficult to calculate:
SERVFAIL or bogus result as an authenticated absence of TLSAThe strongest protection against these mistakes is a change record that names the old association, new association, old TTL, cache-wait deadline, service-switch deadline, rollback deadline, and exact validation commands.
DANE certificate rotation is a coordinated DNS and SMTP change. The TLSA RRset tells a DANE-aware sender which certificate or key is acceptable, while DNSSEC tells that sender whether the assertion is authentic. DNS caches mean that different senders can temporarily hold different versions of the RRset.
For a new key, publish the new association alongside the old one, wait for old-only caches to expire, switch the certificate on every receiving path, observe queue and validation behavior, and remove the old association last. Keep the old certificate and association available for the full rollback window. Treat DNSSEC health, certificate presentation, TLSA contents, and inbound queue age as one operational system.
That sequence makes certificate maintenance deliberately boring, which is exactly what inbound mail infrastructure needs.