Fixing DANE Errors: Why Email Gets Stuck (TLSA Validation Failed)
It is a familiar scenario: a domain has enabled DANE, and suddenly email to a particular partner gets stuck in the queue. The logs show a message like TLSA validation failed, no usable TLSA records or, on Microsoft 365, the status 4.7.323 tlsa-invalid. This is neither a coincidence nor a bug: DANE is working as intended and refusing delivery because something about the certificate binding does not match.
This guide assumes the basics from What Is DANE and focuses on practice: the four most common causes, a diagnostic checklist and the key rollover that avoids such errors in the first place.
Why a DANE error stops delivery
TL;DR: When DANE validation fails, the certificate presented does not match the published TLSA record, or the chain of trust through DNSSEC is broken. Almost always one of four causes is behind it: a DNSSEC or signature problem, a missing or misplaced TLSA record, a certificate that no longer matches after a renewal, or a mail server misconfiguration. Because DANE treats a mismatch as a potential attack, delivery is aborted instead of continuing unencrypted.
The core idea of DANE is that a mismatch between the expected and the actual certificate is a warning sign. That is exactly why DANE does not fall back to unencrypted delivery on a failure, it refuses delivery. This is correct from a security standpoint, but it makes any misconfiguration on your side immediately visible, in the form of undelivered email. The good news: the causes are limited and easy to narrow down.
The four most common causes at a glance
The vast majority of DANE errors fall into one of these four categories. This table helps you go from symptom to cause to fix quickly:
| Cause | Typical symptom | Fix |
|---|
| DNSSEC broken or signature expired | Record counts as unvalidatable, treated as missing | Check the DNSSEC chain and signature validity, re-sign expired signatures |
| TLSA record missing or at the wrong name | no usable TLSA records, record not found | Publish the record correctly under _25._tcp of the mail server hostname |
| Certificate renewed, no longer matches | TLSA validation failed, 4.7.323 tlsa-invalid | Update the TLSA record to the new certificate, both values during transition |
| Mail server presents the wrong certificate | Mismatch despite an existing record | Check the mail server configuration, serve the correct certificate |
DNSSEC is the basis of trust
Since DANE does not work without valid DNSSEC, a broken or expired signature is one of the most insidious causes. The TLSA record can be technically correct yet be discarded by a validating resolver as soon as the signature chain does not add up. To the sending server this looks as if there is no usable record. Expired signatures often arise unnoticed when automatic re-signing of the zone stalls.
The classic: the renewed certificate
By far the most common cause in day-to-day operation is a renewed certificate. If the key is swapped without adjusting the TLSA record in time, the mail server presents a certificate after renewal that no longer matches the stored fingerprint. This is exactly what Exchange Online reports as 4.7.323 tlsa-invalid. Because it is a transient error, the mail first remains in the queue and is retried later, which leaves some time for the fix.
The Let's Encrypt rollover trap
The certificate problem appears especially often with short-lived certificates, for example from Let's Encrypt, which are renewed every few weeks. Every renewal is a potential DANE break if the TLSA record does not follow. There are two proven ways to avoid this:
- Retain the key. If the TLSA record binds to the public key rather than the whole certificate, it stays valid as long as the key is retained on renewal. Many certificate tools offer an option to reuse the existing key.
- Roll over with overlap. If the key must change, publish the new TLSA record before the switch and leave the old and new values in parallel during the transition. Only once the new certificate is active and propagated do you remove the old record.
The mistake that leads to stuck mail in practice is almost always the same: swapping the certificate first and only then thinking about the TLSA record. With DANE the order is reversed.
Diagnosing step by step
If mail is already stuck, work through it systematically, from the outside in:
- Check DNSSEC. Is the mail server's zone validly signed and the chain of trust intact? Without valid DNSSEC, every further check is pointless.
- Check the TLSA record. Does a record exist at the correct name, that is
_25._tcp in front of the mail server hostname, and does it apply to exactly that host? - Compare the certificate. Does the certificate the mail server currently serves match the stored TLSA record? After a renewal this is the most common break point.
- Check the mail server configuration. Does the server really serve the expected certificate for the affected connection, or perhaps a different one from a default configuration?
This order mirrors DANE's chain of trust and almost always leads to the cause quickly.
Avoiding DANE errors with Conbool MailGuard
The recurring pain point with DANE is key rollover. This is exactly where Conbool MailGuard comes in: inbound, the TLSA records are published and rolled over with overlap on every certificate change, so there is never a window in which record and certificate drift apart. Outbound, the service checks the DANE binding of recipient domains and logs the result, which eases troubleshooting when the problem is on the other side.
You can check the current state of your domain, the interplay of DNSSEC, TLSA record and certificate, at any time with the free transport security check. Details of the managed solution are on the DANE and TLSA page.
Frequently asked questions
Why does DANE validation fail?
Almost always it comes down to one of four causes: DNSSEC is broken or a signature has expired, the TLSA record is missing or sits at the wrong name, the certificate was renewed and no longer matches the TLSA record, or a mail server presents the wrong certificate. Because DANE treats a mismatch as a potential attack, delivery is aborted instead of continuing unencrypted.
What does the Exchange status 4.7.323 tlsa-invalid mean?
Status 4.7.323 is a temporary error from Exchange Online and means the certificate presented by the destination server does not match the published TLSA record. Common triggers are a certificate swapped during renewal without an updated TLSA record, or a TLSA record pointing at the wrong link in the certificate chain. As a transient error, the sending server retries delivery later, which is why affected mail first remains in the queue.
How do I renew certificates without breaking DANE?
The safe way is to update the TLSA record before the switch and publish both values in parallel during the transition, the one for the old and the one for the new certificate. Only once the new certificate is active and the old TLSA record is no longer needed do you remove it. With a binding to the public key, the key can be retained on renewal, in which case the TLSA record even stays valid unchanged.
What should I do if the TLSA record is not found?
First check that the record sits at the correct name, usually _25._tcp in front of the mail server hostname, and that it applies to exactly that hostname. Then check that the DNS zone is signed with DNSSEC and the chain of trust is intact, because a record that cannot be validated is treated as missing. Only when both are correct can a sending server use the binding.
How do I check whether DANE works for my domain?
For each mail server of your domain, check that a valid, DNSSEC-signed TLSA record exists and that the certificate actually presented matches it. A transport security check presents this chain in one place and shows whether DNSSEC, TLSA record and certificate line up. That way you spot a problem before it leads to stuck email.
Conclusion
DANE errors feel alarming at first because they stop real email. In practice they are easy to narrow down: DNSSEC, the TLSA record, the certificate and the mail server configuration are the four places where it gets stuck, and the diagnosis always follows the same chain of trust. You avoid most errors by keeping key rollover under control and touching the TLSA record before the certificate, not after.
Check your domain with the transport security check and see how Conbool MailGuard handles key rollover without breaks.
Further reading:
