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, 5.7.323 tlsa-invalid | Publish the record under _25._tcp of the MX hostname, remove any spare record at the domain |
| 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
Once the TLSA record sits at the right name, a renewed certificate is the most common cause in day-to-day operation. 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 TLSA record at the wrong name: the record at your own domain
The second row of the table deserves a closer look, because it is the case that most often sits behind a delivery suddenly being refused without anyone having touched a certificate. The symptom is a rejection with 550 5.7.323 tlsa-invalid, or 451 4.7.323 for a transient failure, even though the mail server responsible serves a valid and unchanged certificate.
The cause sits in the name of the record: it is published under _25._tcp.<your-domain> instead of _25._tcp.<mx-hostname>. Usually it is a leftover from a mail server once run in house that stayed in the zone after the move to a service provider. As long as the zone was unsigned, no sender evaluated it. With DNSSEC signing it takes effect all at once: senders that take the recipient domain as the base compare the old fingerprint against the certificate of today's MX, find no match and stop delivering. Under RFC 7672 the base for the TLSA name is the hostname from the MX record, and the domain itself only applies if it has no MX record at all.
The fix is unspectacular: remove the record at the recipient domain. Nothing is created or changed at the MX hostname; if one already sits there, it stays as it is. These four commands show the situation:
dig +short MX <your-domain> dig +short TLSA _25._tcp.<your-domain> dig +short TLSA _25._tcp.<mx-hostname> openssl s_client -starttls smtp -connect <mx-hostname>:25 </dev/null | openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
The conclusion rests on the third query. If the second one returns a record and the third stays empty, the error is found: because no record sits at the MX hostname, senders such as Exchange Online fall back to the record at the recipient domain and compare it against the certificate of today's MX. If the third query returns a record as well, that one takes precedence: a sender evaluates it and never looks at the domain apex at all. The record there is then untidy, but harmless. This is how posteo.de runs undisturbed, its MX hostname carrying a TLSA record of its own. The last command prints the SHA-256 hash of the public key that a record with the parameters 3 1 1 has to contain. The two outputs are formatted differently: dig +short returns the fingerprint in upper case and split into two groups separated by a space, while openssl dgst -sha256 returns it in lower case in one piece and behind a prefix such as SHA2-256(stdin)=. So compare only after removing the spaces and matching the case. If the value still differs from the published one, the binding does not match the certificate being served.
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. Are both zones involved validly signed and is the chain of trust intact, that is the recipient domain's zone for the MX record and the zone of the MX hostname for the TLSA record? Without valid DNSSEC, every further check is pointless.
- Resolve the MX and check the TLSA record. Which hostname is in the recipient domain's MX record, and does a record exist under
_25._tcpin front of exactly that hostname? If there is also one under_25._tcpin front of the domain itself, it has to go. - 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 points with DANE are the record at the wrong name and key rollover. This is exactly where Conbool MailGuard comes in. Inbound DANE is offered for self-operated mail servers: Conbool derives the matching TLSA record from the certificate of the MX, displays it with its full name for publication and shows on every check whether a record already published still matches the certificate being served and whether it is DNSSEC-secured. Publishing and renewing the record happens in the DNS of the zone operator. Outbound, the service validates the DANE binding of recipients 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, that is _25._tcp in front of the hostname from the domain's MX record and not in front of the domain itself, 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, which starts at the MX record. 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 checks the binding of TLSA record and certificate.
Further reading:
