Voraussetzung: DNSSEC
DANE steht und fällt mit DNSSEC. Ohne signierte Zone kann ein sendender Server dem TLSA-Record nicht trauen, und das ganze Verfahren ist wirkungslos — nicht halb wirksam, sondern wirkungslos. Signiert werden muss die Zone, in der die MX-Hostnamen liegen; das ist nicht zwingend dieselbe wie die der Absenderdomain.
Prüfe das zuerst, bevor du irgendetwas anlegst:
Kommt dort 0 heraus, ist die Zone nicht signiert und DANE noch kein Thema. Dann ist MTA-STS das passende Verfahren, weil es ohne DNSSEC auskommt.
Der Record
Der TLSA-Record hängt am Port und am MX-Hostnamen, nicht an der Domain:
Die drei Zahlen sind Usage, Selector und Matching Type. Für SMTP ist 3 1 1 die richtige Wahl und praktisch die einzige, die man verwenden sollte:
- 3 — das Zertifikat selbst ist der Anker. Keine öffentliche CA muss ihm zustimmen; damit funktioniert DANE auch mit einem selbst ausgestellten Zertifikat.
- 1 — gebunden wird der öffentliche Schlüssel, nicht das ganze Zertifikat. Das ist der entscheidende Unterschied: Eine Erneuerung mit demselben Schlüssel lässt den Record gültig.
- 1 — SHA-256 als Prüfsumme.
Der Wert entsteht direkt aus dem Zertifikat:
Die Rotation — der eigentliche Knackpunkt
Ein TLSA-Record, der nicht mehr zum ausgelieferten Zertifikat passt, führt bei prüfenden Absendern zur vollständigen Zustellverweigerung. Genau deshalb verläuft jede Erneuerung nach diesem Muster:
- Neuen Record zusätzlich veröffentlichen, solange das alte Zertifikat noch aktiv ist. Zwei TLSA-Records am selben Namen sind erlaubt; ein Absender akzeptiert, was auf einen von beiden passt.
- Die TTL abwarten — mindestens eine volle TTL-Länge, damit auch Resolver mit alten Antworten den neuen Record kennen.
- Zertifikat austauschen und den Dienst neu laden.
- Alten Record entfernen, frühestens nach einer weiteren TTL.
Der einfachere Weg: bei der Erneuerung den Schlüssel behalten. Dann bleibt der Fingerabdruck gleich und der Record muss gar nicht angefasst werden. Bei Let's Encrypt geht das über eine feste Schlüsseldatei statt eines neuen Schlüssels je Erneuerung.
Was bei einem Fehler passiert
Ohne DANE fällt ein sendender Server bei einem Zertifikatsproblem auf eine unverschlüsselte Zustellung zurück — die Mail kommt an. Mit einem veröffentlichten TLSA-Record ist dieser Rückfall verboten: Die Gegenstelle bricht ab und stellt die Nachricht zurück, bis es wieder passt. Das ist der Zweck des Verfahrens und zugleich sein Risiko.
Deshalb gehört zu DANE zwingend eine Überwachung: Restlaufzeit des Zertifikats, Gültigkeit der DNSSEC-Signaturen und die Übereinstimmung von Record und Zertifikat. Der MX-Check liest TLSA-Records und Zertifikat in einem Durchgang und zeigt, ob beide zusammenpassen.
Zusammen mit MTA-STS
Beide Verfahren schließen sich nicht aus. Wer DNSSEC betreibt, richtet sinnvollerweise beides ein — sendende Server unterstützen unterschiedliche Verfahren, und was der eine kann, kann der andere nicht.