DANE & DNSSEC in Practice – Why My Mail Server Is Now Actually Secure
Over the past few days, I have hardened my mail server with one clear goal in mind:
cryptographically secured mail delivery without relying on third parties.
The result:
✅ DNSSEC enabled
✅ DANE (TLSA) correctly configured
✅ STARTTLS with TLS 1.3
✅ successful delivery with Google & Yahoo
✅ no fallbacks, no opportunistic TLS guesswork
This article is not a beginner tutorial.
It is an honest field report from practice, including real pitfalls.
Why DANE at All?
Most mail servers on the Internet use TLS only opportunistically:
If TLS works, fine.
If not, too bad.
That is better than plaintext, but it is not secure.
DANE changes the rules:
• The mail server’s certificate is published directly in DNS
• DNSSEC ensures this information cannot be manipulated
• A vulnerable CA trust store is no longer required
In short:
👉 DNS defines which certificate is valid, not some random CA.
My Architecture (Short Version)
• Own mail server (Postfix + Dovecot)
• Static business Internet connection
• DMZ segmentation with two OPNsense firewalls
• Split DNS (internal / external)
• Let’s Encrypt certificate for mail.kosifuchs.de
No cloud relay. No smarthost.
The Most Important Test: External & Independent
The decisive moment was not a local test, but this one:
dig +dnssec TLSA _25._tcp.mail.kosifuchs.de
Result:
• TLSA record present
• RRSIG present
• ad flag set
This means:
Any external resolver on the Internet can fully validate the TLSA information.
DANE is therefore practically usable, not just theoretically correct.
Why Internal Tests Often Confuse People
A very common pitfall:
• everything works internally
• external tools fail
• mail delivery still works
The reason is almost always:
• split DNS
• hairpin NAT / NAT reflection
• asymmetric routing in DMZ setups
This is not a DANE problem, it is a network design issue.
Only external verification counts.
What You Do Not Need
• no special client tools
• no mail client with DANE support
• no smartphone testing
DANE is MTA-to-MTA.
Clients are irrelevant.
Conclusion
My mail server is now:
• cryptographically verifiable
• resistant to TLS downgrade attacks
• independent of CA trust problems
• auditable using standard DNS tools
DANE is not a marketing buzzword.
It works, if you do it correctly.
If you operate your own mail server and truly want to know
whether TLS is enforced, not just “nice to have”,
there is no way around DNSSEC + DANE.