The short answer
A TLSA record breaks on renewal when it pins something the renewal changes. A 3 0 1 record hashes the whole certificate, so it stops matching every time, while a 3 1 1 record hashes the public key and keeps matching as long as the key pair is reused. RFC 7672 recommends 3 1 1 for SMTP for exactly this reason. The trap is that most ACME clients generate a fresh private key on each renewal unless told otherwise, which turns the stable record back into a per-renewal outage — and under Ballot SC-081v3 that renewal happens roughly twice a year today and around eight times a year from March 2029.
Guides to DANE tend to stop at the moment the first record goes live, which is the easy part. The hard part arrives sixty days later, and the measurements show how badly it goes: the 2022 USENIX Security study of SMTP DANE found that more than 87% of the servers it tracked rolled their keys over incorrectly, and that more than 94% of the hosts publishing TLSA records were using CA-issued certificates — the ones that get reissued on a schedule nobody at the mail server is watching. This page is about that schedule, and about the one field in the record that decides whether you ever have to think about it again.
Why does DANE break when the certificate renews?
DANE breaks on renewal because it is a pinning mechanism and a renewal moves the thing being pinned. A sending mail server that finds a usable TLSA record for your MX host compares what the host presents in the TLS handshake against the hash in that record. If nothing matches, the sender does not warn and does not downgrade to cleartext: under RFC 7672 it refuses the delivery, so the message sits in the sender's queue until it bounces.
That is the correct behaviour, and it is the whole point of deploying DANE. Opportunistic SMTP TLS will happily accept any certificate at all, including one an attacker substituted, which leaves the encryption decorative. DANE closes the gap by making the DNS answer authoritative about which key is allowed. The cost of that guarantee is an ordering constraint: from the moment you publish a record, your DNS zone and your mail server have to agree about the key, and a renewal is an event that changes one of them.
The failure is also quiet from your side. Your own monitoring sees a mail server with a valid, freshly renewed certificate answering on port 25. Nothing is down. The only symptom is mail that stops arriving from the subset of senders that validate DANE, which is why these incidents are usually reported by a customer rather than by a dashboard.
How do you read a TLSA record?
A TLSA record has an owner name that encodes the port and transport, then three numeric fields and a hash. The owner name for SMTP is _25._tcp.<mx-hostname>, using the hostname from your MX record rather than the domain in your email addresses. The three numbers are certificate usage, selector and matching type, defined in RFC 6698, and the hash is a digest of whichever structure the selector names.
RFC 7672 narrows the field values that make sense for mail. Only the two DANE usages are useful: DANE-EE(3), which pins the end-entity certificate or its key directly, and DANE-TA(2), which pins a trust anchor the presented chain must reach. Usages PKIX-TA(0) and PKIX-EE(1) should not be published for SMTP, because mail servers share no common list of trusted roots, so a validating sender may treat such a record as unusable and you lose the protection without any warning.
Usage 3 carries one consequence worth stating plainly, because it surprises people who come to DANE from the web PKI. With DANE-EE(3), RFC 7672 says the expiration date of the server certificate must be ignored, since the lifetime of the key binding comes from the validity interval of the TLSA record's DNSSEC signature instead. The same section says the server must be considered authenticated even when none of the names in the certificate match. An expired, self-signed certificate with the wrong hostname in it satisfies a matching DANE-EE record.
Which TLSA combination should you publish?
Publish 3 1 1 — DANE-EE usage, SPKI selector, SHA-256 matching. RFC 7672 names it as the recommended combination for SMTP, with 2 0 1 as a second choice. The selector is what earns the recommendation: hashing the SubjectPublicKeyInfo ties the record to the key pair rather than to one issued certificate, so a reissuance that keeps the key leaves the published value untouched.
| Record | What is pinned | Survives a renewal? | Expiry and names checked? |
|---|---|---|---|
| 3 1 1 | SubjectPublicKeyInfo of the server certificate | Yes, if the key pair is reused | No |
| 3 0 1 | The full DER-encoded server certificate | Never | No |
| 2 0 1 | The issuing CA certificate, as a trust anchor | Yes, until the CA changes the intermediate | Yes |
| 0 x x / 1 x x | Public CA path, assuming a shared root store | Not applicable | Should not be published for SMTP |
The 2 0 1 row deserves a note, because it looks like a way to make the problem disappear. Pinning the issuing CA certificate does survive key rotation, so renewals stop mattering. In exchange you give up the part of DANE-EE that ignores the chain: with DANE-TA the presented certificate has to validate to the pinned anchor, hostname checks against the MX name apply, and an expired certificate fails. RFC 7672 also requires the server to include the trust anchor certificate in the chain it presents, even when it is a self-signed root. And public CAs do replace intermediates, which turns a once-a-year renewal problem into an unpredictable one.
Does your ACME client change the key on renewal?
Assume it does until you have checked. Certbot generates a new private key on every renewal by default, which means a new SubjectPublicKeyInfo and a new SPKI hash, which means a 3 1 1 record that was correct yesterday is wrong today. Adding --reuse-key keeps the key pair across renewals, and it can be set per-certificate in the renewal configuration under /etc/letsencrypt/renewal/ or globally in cli.ini.
This is the step that catches people who did everything else right. They read the RFC, published 3 1 1 because it is the stable one, and still lost mail two months later, because stability was a property of the key rather than of the record. Other ACME clients differ in both default and option name, so check yours against its own documentation rather than against Certbot's.
Worth knowing either way: reusing a key indefinitely is a trade, not a free win. Rotating keys limits what a leaked one is worth, and a key that never changes undoes some of what shorter certificate lifetimes were introduced to achieve. A reasonable middle position is to reuse the key across routine renewals and perform one deliberate, scheduled key rollover a year with the overlap procedure below, rather than an accidental one every renewal.
How do you roll over without losing mail?
Publish the new record before you install the new certificate, and wait out the TTL in between. A validating sender treats the TLSA record set as a list of acceptable alternatives, so a host matching any one record authenticates. That makes a clean rollover four ordered steps: add the record for the incoming key, wait longer than the record's TTL so cached copies of the old answer have expired, install the certificate and restart the services that present it, then remove the record for the retired key.
The wait is the step that gets shortened, and it is the one that cannot be. What matters is not when your DNS provider shows the new record but when every resolver that cached the previous answer stops serving it, which is governed by the TTL you published with — plus, in a DNSSEC-signed zone, the time your signing setup needs to produce signatures over the new record set. Lowering the TTL on the TLSA record a day or two before a planned rollover shortens the window you have to sit through.
Reversing the order is the version that breaks mail. Install first and there is a period, as long as the TTL, in which the published record describes a key the server no longer presents. During it, senders that validate DANE have exactly one correct behaviour available to them, which is to refuse the delivery. Nothing on your side looks wrong while it happens.
On the mail server side, remember which services actually hold the certificate. A renewal hook that reloads Postfix leaves Dovecot presenting the previous one, and submission on port 587 or IMAPS on 993 can lag behind port 25. Our Postfix and Dovecot installation guide covers which files each daemon reads and what has to be reloaded after a renewal.
What do 200-, 100- and 47-day certificates change?
They multiply the number of times a year the rollover has to go right. CA/Browser Forum Ballot SC-081v3 phases the maximum validity of public TLS certificates down on a fixed schedule: 200 days for certificates issued on or after March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Since a renewal is the event that moves the pin, each step is a step up in how often a DANE deployment is exposed to its weakest procedure.
| From | Maximum validity | Renewals per year, at least | What that means for a TLSA record |
|---|---|---|---|
| Before 15 Mar 2026 | 398 days | 1 | An annual manual update was survivable |
| 15 Mar 2026 | 200 days | 2 | Manual updates start getting missed |
| 15 Mar 2027 | 100 days | 4 | Key reuse or automation, pick one |
| 15 Mar 2029 | 47 days | 8 | A per-renewal procedure is not viable by hand |
The renewal counts are floors derived from the maximum validity. Real deployments renew earlier than the expiry date — a third of the lifetime remaining is a common trigger, and ACME clients often use a fixed window — so the true number is higher in every row. The detail of the schedule, including the parallel cuts to how long domain validation evidence can be reused, is in our guide to the 2026 certificate validity changes.
Read together with the USENIX finding, the arithmetic is uncomfortable. A procedure that already failed on more than 87% of measured servers when it ran once a year is about to run eight times a year. The answer is not a better calendar reminder. It is to remove the per-renewal step entirely by reusing the key, so that the only rollovers left are ones you chose to perform.
Does MTA-STS have the same problem?
No, because MTA-STS pins nothing. It publishes a policy saying which MX hosts are legitimate and that TLS is mandatory, and leaves the certificate check to the ordinary web PKI. A renewal therefore needs no coordination with DNS at all. What MTA-STS does instead is make the certificate a hard dependency of mail delivery in the other direction: RFC 8461 requires the MX host to present a certificate that is unexpired, chains to a root the sender trusts, and matches the host's DNS name, so under an enforced policy a renewal that fails to happen stops inbound mail.
The two mechanisms fail in opposite directions, which is the argument for running both. DANE tolerates an expired, name-mismatched certificate and fails when the key moves without the record. MTA-STS tolerates any key change and fails when the certificate lapses or stops matching the hostname. A host that satisfies both has no single renewal mistake that takes mail down.
Reachability settles the question in practice. Microsoft's Exchange Online has validated outbound SMTP DANE with DNSSEC since March 2022 and brought inbound support to general availability in 2024, with further admin control over DANE and MTA-STS validation on outbound connectors rolling out through early 2026. Google Workspace went the other way: it validates MTA-STS and does not validate DANE, so TLSA records buy nothing for mail arriving from Gmail. Publishing only one mechanism means choosing which half of your inbound mail goes unprotected.
MTA-STS also costs a second certificate, which is the detail most often missed at rollout. The policy file is fetched over HTTPS from mta-sts.<your-domain>, and that host needs its own valid, publicly trusted certificate before you publish the TXT record, on top of the one your MX host presents. Both are ordinary publicly trusted SSL/TLS certificates; which names they need to carry is covered in our guide to choosing a certificate for a mail server.
How do you tell a broken TLSA record from a working one?
Compute the hash from the certificate the server is actually serving and compare it to the record in DNS. Two commands settle it. The first prints the SPKI digest that a 3 1 1 record should contain, and the second prints what you published. If the strings differ, you have found the outage.
# what the server presents, as a 3 1 1 value openssl s_client -starttls smtp -connect mail.example.com:25 \ -servername mail.example.com </dev/null 2>/dev/null \ | openssl x509 -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256 -hex # what DNS says, and whether it is signed dig +dnssec TLSA _25._tcp.mail.example.com
Check three things in the dig output, in this order. The answer must carry an RRSIG and validate, because an unsigned or bogus TLSA record is ignored by compliant senders — the USENIX study found that over 30% of the records it measured failed on the DNSSEC chain rather than on the hash. The owner name must be the MX hostname, not the mail domain. And the hash must match the output of the first command for at least one record in the set.
Worth doing once in the other direction too: confirm what your MX host presents to the outside world, since multi-tenant platforms select certificates by SNI and the certificate you installed is not always the one being served. Our SSL checker reports the chain and expiry for a hostname, which is the quickest way to rule out a mismatch between what is on disk and what is on the wire.
Then make the comparison continuous. The single most useful piece of monitoring for a DANE deployment is a check that recomputes the hash from the live handshake and alerts when it stops matching the published record set. It catches the broken rollover, the hook that did not fire, the daemon that was not reloaded and the expired DNSSEC signature, all with one test.
The rollover decision, in one page
The decision is about your renewal client, not your mail server. If the client keeps the private key, publish one 3 1 1 record and you are done until you choose to rotate. If it does not and cannot be made to, you own a per-renewal rollover and it has to be automated. Those are the only two stable positions.
Whichever branch you land on, four things hold. The zone has to stay signed, because a lapsed signature takes DANE down as effectively as a wrong hash. The record belongs on the MX hostname. Monitoring has to compare the served key to the published one rather than merely checking that the record exists. And MTA-STS covers the senders that do not validate DANE, which includes the largest consumer mail provider there is.
If you are planning a deployment from scratch rather than repairing one, the order that causes the least pain is: sign the zone, enable key reuse in the renewal client, verify the served SPKI hash by hand, publish the record with a short TTL, then raise the TTL once a renewal has passed through without incident. Automation built on ACME renewal hooks is what makes the last step hold at 47 days.
Frequently Asked Questions
Answers to common questions about certificates and our services.
Why did my mail stop being delivered after I renewed my certificate?
If you publish TLSA records, the likely cause is that the record still describes the old certificate. DANE is a pinning mechanism: a sending server that validates DANE compares what your MX host presents against the hash in your TLSA record, and a mismatch is a hard failure rather than a warning. Under RFC 7672 the sender must not fall back to cleartext once it has found usable TLSA records, so mail queues instead of arriving. Check the record against the live certificate before looking anywhere else — a renewal that changed either the certificate bytes or the public key is the single most common trigger.
Does a TLSA record have to be updated every time the certificate renews?
Not if you publish the combination RFC 7672 recommends. A 3 1 1 record hashes the SubjectPublicKeyInfo, which is derived from the public key rather than from the certificate, so the value is unchanged by a renewal that keeps the same key pair. A 3 0 1 record hashes the whole certificate and therefore changes on every single renewal, with no exceptions. The practical rule is that the record follows the key, so you only have a rollover to manage when you rotate the key.
What is the difference between TLSA 3 1 1 and 3 0 1?
The middle field is the selector. Selector 1 means the hash covers the SubjectPublicKeyInfo; selector 0 means it covers the full DER-encoded certificate. Both are DANE-EE usage 3 with SHA-256 matching, so both pin the end-entity directly, but only selector 1 is stable across reissuance of the same key. RFC 7672 names DANE-EE(3) SPKI(1) SHA2-256(1) as its recommended combination for SMTP, with DANE-TA(2) Cert(0) SHA2-256(1) as a second choice.
Does DANE care whether my certificate has expired?
Not with DANE-EE(3). RFC 7672 states that the expiration date of the server certificate must be ignored, because the lifetime of the key binding is set by the validity interval of the TLSA record's DNSSEC signature rather than by the certificate. The same section says the server must be considered authenticated even when none of the names in the certificate match the client's reference identity. DANE-TA(2) behaves differently: the presented chain has to validate to the pinned trust anchor, and the ordinary expiry and hostname checks do apply.
Can I publish two TLSA records at the same time?
Yes, and that is how a key rollover is supposed to be done. A sending server treats the TLSA record set as a list of acceptable alternatives, so a host that matches any one record authenticates. Publish the record for the incoming key alongside the record for the current one, wait longer than the record's TTL so that cached copies of the old answer have expired, install the new certificate, then remove the record for the retired key once nothing serves it.
Does DANE work without DNSSEC?
No. A TLSA record that is not covered by a valid DNSSEC chain is not usable, and a compliant sender ignores it as though it were absent. This is the most common deployment failure in the wild: the 2022 USENIX study of SMTP DANE found that more than 30% of the TLSA records it measured could not be validated because of a broken DNSSEC chain. Signing the zone is a prerequisite, not an enhancement, and a lapsed signature takes DANE down as effectively as a wrong hash.
Do I still need a publicly trusted certificate if I deploy DANE?
For DANE alone, no — a DANE-EE record makes the TLSA value the trust anchor, so a self-signed certificate satisfies it. In practice you still want a publicly trusted one, because senders that do not validate DANE fall back to ordinary PKIX checks and because MTA-STS requires an unexpired certificate that chains to a public root and matches the MX hostname. Google Workspace validates MTA-STS and does not validate DANE, so a mail host that only satisfies DANE is unprotected against a large share of the mail sent to it.
Which providers actually validate DANE on outbound mail?
Microsoft is the significant one: Exchange Online has supported outbound SMTP DANE with DNSSEC since March 2022 and brought inbound support to general availability in 2024, with further admin controls over DANE and MTA-STS validation on outbound connectors rolling out through early 2026. Google Workspace takes the other route and validates MTA-STS rather than DANE, so TLSA records bring no benefit for mail arriving from Gmail. Publishing both mechanisms is the only way to cover both senders.
If you are not sure which record you are running
Send us the output of the two commands above and we will tell you whether your record survives your next renewal or breaks on it. If it turns out you need a certificate for the MX host or for the mta-sts policy host, we issue publicly trusted SSL/TLS certificates as a Certum partner, and we will tell you plainly when the answer is that your existing certificate already covers what you need.
Related reading
- SSL certificate for a mail server — which hostname the certificate has to carry, why an S/MIME certificate will not do the job, and what MTA-STS and DANE each demand of it.
- The 2026 certificate validity changes — the full SC-081v3 schedule down to 47 days, and the parallel cuts to how long domain validation evidence can be reused.
- Certbot and ACME automation — renewal hooks, key handling and the deploy steps that have to run after every issuance.