Transport security under BSI TR-03108

DANE and TLSATamper-proofemail transport

DANE binds the receiving mail server's certificate firmly in DNS via DNSSEC. This enforces TLS encryption between mail servers and protects it against downgrade as well as man-in-the-middle attacks, without any dependency on the public certificate world.

Check your domain for free View MailGuard

TLSA record in DNS

_25._tcp.mx.example.de.  IN TLSA (
  3 1 1  d2abef7c...  )

mx.example.de.  IN  RRSIG  (
  TLSA  ECDSAP256SHA256 ... )

DNSSEC validated

DNSSECTLSASTARTTLSRFC 7672

DANE closes the last major gap in email encryption during transport. SPF, DKIM and DMARC secure the authenticity of the sender. DANE and TLSA ensure that the path a message takes between mail servers is actually encrypted and that the receiving server is the genuine one.

Classic STARTTLS encrypts only opportunistically. An attacker on the transmission path can disable the encryption or substitute their own certificate without it being noticed. DANE ends this risk by publishing the fingerprint of the expected certificate in a TLSA record in DNS and signing it tamper-proof via DNSSEC.

DANE, TLSA and DNSSEC explained clearly

Three building blocks that together deliver verified transport encryption.

DANE

DNS-based Authentication of Named Entities

A method under RFC 7672 that tells the sending mail server via DNS which certificate the receiving server must present. If the binding does not match, delivery is refused rather than continued unencrypted.

TLSA record

the DNS entry behind DANE

The TLSA record holds the hash of the mail server certificate or of the public key. The sending server compares this hash with the certificate from the TLS handshake and detects any deviation immediately.

DNSSEC

the cryptographic protection of DNS

DANE strictly requires DNSSEC. Only the signature of the DNS zone ensures that the TLSA record itself has not been manipulated. Without DNSSEC there would be no trustworthy basis for the certificate binding.

STARTTLS

Why opportunistic STARTTLS is not enough

The standard encryption in SMTP transport can be undermined without sender or recipient noticing.

STARTTLS

encrypts only when both sides offer it, and otherwise falls back silently to plaintext

MITM

an attacker on the path can present their own certificate without being detected

Downgrade

the TLS negotiation can be actively removed so that the message travels in plaintext

With opportunistic encryption, the sending server does not check whether the remote party's certificate is genuine. This is exactly where stripping and downgrade attacks come in. They remove the TLS hint from the server response or substitute a forged certificate. The message is delivered, but the protection was an illusion. DANE prevents this because the expected certificate binding is already established before the connection is set up.

How certificate binding with DANE works

Four steps from the DNS lookup to enforced encryption.

1
DNSSEC lookup of the recipient domain
The sending mail server determines the responsible mail server and checks whether the DNS responses are validly signed. Only signed responses are accepted.
2
Retrieve the TLSA record
For the mail server, the TLSA record is queried under the MX name. It contains the expected certificate fingerprint.
3
Match the TLS handshake
In the handshake, the receiving server presents its certificate. The sending server compares it with the hash from the TLSA record.
4
Enforce or refuse
If the binding matches, the message flows encrypted. If it does not match, delivery is refused and not continued unencrypted.

DANE and MTA-STS compared

Both enforce TLS in transport, with a different trust anchor. In practice they complement each other.

Property	DANE and TLSA	MTA-STS
Trust anchor	DNSSEC-signed TLSA record	public certificate world and HTTPS policy
Protection on first contact	effective immediately	trust only after first contact
Prerequisite	DNSSEC required	no DNSSEC needed, but a web server for the policy
Downgrade protection	cryptographically enforced	policy-based enforcement
BSI TR-03108	mandatory	optionally recognized

Conbool supports both methods. DANE covers all senders that evaluate DNSSEC, MTA-STS complements it for senders without DNSSEC. The combination closes the first-contact gap completely.

DANE is mandatory under BSI TR-03108

The Technical Guideline BSI TR-03108 for secure email transport makes DANE binding for certified service providers.

The Federal Office for Information Security classifies DANE as effective and scalable protection against man-in-the-middle threats in encrypted email transport. MTA-STS is recognized in version 2.0 as an optional complement, but does not replace DANE. Anyone who wants to demonstrate transport security according to the current state of the art cannot avoid DANE.

Binding certificate association via the TLSA record
DNSSEC as a signed trust basis
Demonstrable protection against downgrade and manipulation
Compatible with NIS2 and industry-specific requirements

DANE inbound and outbound with Conbool MailGuard

Conbool MailGuard operates DANE in both directions, without any need to rebuild your own mail servers.

TLSA records published

For the protected domains, the certificate binding is provided in DNS so that external senders can enforce DANE.

Outbound validation

Outbound messages check the recipient's TLSA record and deliver only when the binding is correct.

DNSSEC-validating resolver

A dedicated validating resolver ensures that only signed DNS responses serve as the basis.

Safe fallback

Temporary DNS errors lead to a controlled deferral instead of unencrypted delivery. Protection is never silently switched off.

Key rotation without disruption

Certificate changes are accompanied by duplicate TLSA records so that no delivery outage occurs.

Complete logging

Every DANE decision is documented in a traceable way and is available for audits.

Frequently asked questions about DANE and TLSA

What is the difference between DANE and TLSA?

DANE is the method that enforces verified transport encryption in SMTP. The TLSA record is the specific DNS entry that holds the fingerprint of the expected certificate. DANE uses the TLSA record as the basis for the comparison.

Does DANE strictly require DNSSEC?

Yes. Without DNSSEC, the TLSA record itself could be manipulated. Only the signed DNS zone makes the certificate binding trustworthy. DNSSEC is therefore the fundamental prerequisite for DANE.

How does DANE differ from MTA-STS?

DANE anchors trust cryptographically in DNS via DNSSEC and protects from the very first contact. MTA-STS uses the public certificate world and a policy distributed over HTTPS, but initially trusts on first contact. Both methods can be combined.

Is DANE relevant for Microsoft 365 or Exchange?

Yes. Inbound, all domains benefit from published TLSA records. Outbound, DANE depends on whether the platform in use supports validation. Conbool MailGuard handles DANE validation independently of the underlying mailbox service.

What happens during a certificate change?

Before the change, a second TLSA record for the new certificate is published. This way a valid binding always remains in place during the transition and no delivery outage occurs.

Does DANE break delivery if a recipient has configured it incorrectly?

With an invalid binding, delivery is deliberately refused instead of continued unencrypted. Temporary DNS problems lead to a controlled deferral with retries, not to a silent loss.

How can you check whether a domain uses DANE?

The free mail check from Conbool evaluates the TLSA record at the mail server and shows whether the certificate binding is correct and DNSSEC-validated. The result comes back as a compact report.

Is DANE alone enough for secure email transport?

DANE secures the transport path and the identity of the receiving server. For the authenticity of the sender, SPF, DKIM and DMARC are additionally needed. TLS-RPT provides visibility into transport errors. Only together do they form complete protection.

Is DANE also possible when operated with your own provider?

Yes. In OnPrem operation from Conbool, the validating resolver runs locally, so that DANE also works in isolated environments without dependency on external resolvers.

Further building blocks of transport security

MTA-STS

Enforced TLS encryption for all senders, even without DNSSEC.

TLS-RPT

Reports on transport errors, so that no silent encryption gap goes undetected.

Directory harvesting protection

Defense against attacks that scrape valid email addresses at the server.

MailGuard

The email security gateway that bundles all transport and content protection functions.

Make transport security demonstrable

The free mail check shows within minutes whether DANE, DNSSEC and transport encryption of your own domain take effect correctly.

Check your domain for free Request a consultation