DNS-Sicherheit für E-Mail: DNSSEC, DANE und CAA richtig einordnen

Welche Schutzaufgabe gehört wohin?

SPF, DKIM und DMARC verwenden DNS-Daten. Falsche Antworten können ihre Auswertung beeinflussen. Auch das Empfangsziel aus dem MX-Record kommt aus DNS. Eine MTA-STS-Policy wird dagegen über HTTPS abgerufen und über DNS angekündigt; eine bereits bekannte gültige Enforce-Policy verschwindet nicht einfach durch eine manipulierte DNS-Antwort. RFC 4033 §§3–4, RFC 8461 §10

Registrar, DNS-Hoster, Resolver und Mailanbieter unterscheiden

Der Registrar verwaltet die Domainregistrierung und veranlasst unter anderem die Delegation und DNSSEC-Verankerung beim Parent. Der autoritative DNS-Hoster veröffentlicht Ihre Zone und signiert sie gegebenenfalls. Ein validierender Resolver prüft Antworten für seine Nutzer. Der Mailanbieter betreibt SMTP-Server und entscheidet, welche Authentifizierungs- und Transportverfahren er beim Senden oder Empfangen verwendet.

Diese Rollen können bei einem Anbieter liegen, müssen es aber nicht. DNSSEC am eigenen Domainnamen gibt Ihnen keine Kontrolle über TLSA-Records unter einem fremden MX-Hostnamen. Zeigt Ihr MX auf mx.provider.example, verwaltet dessen Betreiber die passende TLSA-Zone. Der SPF-Record muss Ihre tatsächlichen Versanddienste autorisieren, nicht pauschal den DNS-Hoster.

DNSSEC: Signaturen, Vertrauenskette und Fehlerzustände

DNSSEC signiert Datensatzgruppen gleichen Namens und Typs, sogenannte RRsets. Resolver prüfen die Signaturen mit DNSKEY-Daten und einer Vertrauenskette zu einem vorab vertraut bezogenen Schlüssel, dem Trust Anchor. Üblich ist der Root-Trust-Anchor; lokale Trust Anchors sind ebenfalls möglich. DS-Daten in der Elternzone verbinden die Delegation mit einem Schlüssel der Kindzone. RFC 4033 §§2, 5, RFC 4034

Die Rollen KSK (DNSKEY-RRset signieren) und ZSK (andere RRsets signieren) lassen sich trennen; ein gemeinsamer Schlüssel ist ebenfalls möglich. Rotationsfristen hängen vom Betrieb ab. Eine neue Schlüsseldatei allein ist kein erfolgreicher Schlüsselwechsel: DNSKEY, Signaturen, DS und Cachezeiten müssen zusammenpassen. RFC 6781 §§3–4

Ein fehlender DS kann eine signierte Zone ohne übergeordnete Absicherung lassen. Ein noch vorhandener DS zu einem nicht mehr verwendeten Schlüssel kann dagegen die Validierung brechen. Deshalb DNSSEC nicht durch Abschalten der Signierung „zurücknehmen“, solange die Delegation noch darauf verweist. RFC 4033 §5, RFC 6781 §4.3

Algorithmen und Nichtexistenzbeweise aktuell halten

RFC 9904 hat RFC 8624 abgelöst und die maßgeblichen Algorithmusempfehlungen in die IANA-Register verlagert. Im am 27. September 2026 gelesenen Register sind für DNSSEC-Signaturen unter anderem RSA/SHA-256 (8), ECDSA P-256/SHA-256 (13) und Ed25519 (15) empfohlen. Die Wahl muss zum Hoster und zu einem geplanten Wechsel passen; aus einer Algorithmusnummer folgt kein vollständig geprüftes DNSSEC-Setup. RFC 9904, IANA

RFC 9905 untersagt neue DNSSEC-Signierung mit den Algorithmen 5 und 7; der DS-Digesttyp 1 (SHA-1) darf laut Register nicht mehr für Delegationen verwendet werden. Signaturalgorithmus und DS-Digesttyp sind verschiedene Felder. §2 verlangt von Resolverbetreibern, die Signaturalgorithmen 5 und 7 als nicht unterstützt zu behandeln; ohne andere unterstützte Algorithmen werden die betroffenen Antworten damit insecure. Gleichzeitig müssen Implementierungen die Validierungsfähigkeit weiter bereitstellen. RFC 9905 §§2, 5

NSEC3 ist kein Vertraulichkeitsschutz: erratbare Namen bleiben über Wörterbuchangriffe auffindbar. RFC 9276 empfiehlt NSEC, wenn die besonderen NSEC3-Funktionen nicht benötigt werden. Bei NSEC3 verlangt er null zusätzliche Iterationen und empfiehlt keinen Salt; Opt-out empfiehlt er für kleine Zonen nicht. Alte Anleitungen mit 150 Iterationen und langem Salt sind dafür keine aktuelle Grundlage. RFC 9276 §3.1

Resolverbetreiber müssen ihre Trust Anchors pflegen. IANA plant den Wechsel auf den Root-Schlüssel KSK-2024 (Key Tag 38696) zum 11. Oktober 2026; am Quellenprüftag ist das ein geplanter Wechsel. Aktualisieren Sie nach den Vorgaben Ihrer Resolverdistribution, nicht anhand einer aus einem Artikel kopierten Schlüsseldatei. IANA: Root Trust Anchors

DANE: TLSA-Daten müssen zum tatsächlichen Mailserver passen

SMTP-DANE verbindet DNSSEC mit TLS. Für mx1.example.com auf SMTP-Port 25 liegt der TLSA-RRset unter _25._tcp.mx1.example.com. Ein verbreitetes Format ist:

_25._tcp.mx1.example.com.  IN TLSA 3 1 1 <SHA256-DER-SPKI-des-Serverzertifikats>

Der Platzhalter ist kein veröffentlichbarer Hash. Die drei Zahlen bedeuten:

RFC 7672 empfiehlt 3 1 1, alternativ 2 0 1 für eine Bindung an ein Trust-Anchor-Zertifikat. Usage 0/1 sind für opportunistisches SMTP-DANE nicht die empfohlenen Varianten. Bei Usage 2 sind die passende Zertifikatskette und die weiteren Regeln für den Trust Anchor zu beachten. RFC 7672 §3.1

Ein lokales Zertifikat lässt sich für 3 1 1 so auswerten; der Befehl baut keine SMTP-Verbindung auf:

openssl x509 -in server.pem -pubkey -noout |
  openssl pkey -pubin -outform DER |
  openssl dgst -sha256

server.pem muss das tatsächlich eingesetzte Endzertifikat enthalten. Eine korrekte Berechnung für eine falsche Datei hilft nicht. Der öffentliche Schlüssel kann bei einer Zertifikatserneuerung gleich bleiben oder wechseln; verlassen Sie sich nicht auf einen vermeintlichen Standardwert Ihres ACME-Werkzeugs.

Was der sendende MTA entscheidet

Für eine gegen manipulierte Empfangsziele abgesicherte DANE-Zustellung müssen auch die MX-Daten authentifiziert sein. Danach wird die TLSA-Antwort für jeden relevanten Zielhost bewertet. RFC 7672 §§2.1–2.2

DANE und MTA-STS können nebeneinander eingesetzt werden. MTA-STS ist kein Ausweg aus einer fehlgeschlagenen DANE-Validierung. Bei gehosteten Postfächern ist die aktuelle Unterstützung des Mailanbieters entscheidend; die frühere pauschale Aussage, Microsoft 365 veröffentliche keine TLSA-Daten, ist überholt. Microsoft dokumentiert eingehendes SMTP-DANE für Exchange Online mit entsprechend umgestellten MX-Namen. RFC 8461 §2, Microsoft: SMTP-DANE

TLSA und Schlüssel gemeinsam wechseln

1. Erfassen Sie alle betroffenen MX-Hosts, Zertifikate, TLSA-Parameter und Betreiber.
2. Veröffentlichen Sie neben der aktuellen auch die künftige passende TLSA-Bindung, bevor Sie den neuen Schlüssel einsetzen.
3. Warten Sie die erforderlichen Cachezeiten ab. RFC 7671 §8.1 nennt bei festen TLSA-Parametern mindestens zwei TTLs oder länger; berücksichtigen Sie den tatsächlichen vorherigen Zustand und Signaturen.
4. Stellen Sie die Server um und prüfen Sie mit einem DANE-fähigen Client gegen Ihre eigenen Systeme, dass die präsentierte Kette passt.
5. Entfernen Sie alte Bindungen erst nach erfolgreicher Umstellung und nachdem kein betroffener Server sie mehr braucht.

Bei einem Fehler bleibt der alte Server-/Schlüsselstand nur dann ein geeigneter Rückweg, wenn dessen Bindung weiterhin veröffentlicht und gültig ist. Verschiedene TLSA-Parameterkombinationen können die Auswertung beeinflussen; nicht nur irgendein Record muss passen, sondern die Rolloverregeln für jede verwendete Kombination. RFC 7672 §4, RFC 7671 §8

CAA: Zertifikatsausstellung begrenzen

CAA beschränkt die Ausstellung durch regelkonforme Zertifizierungsstellen. Die CA sucht für den beantragten Namen nach dem maßgeblichen CAA-RRset, verfolgt dabei Aliase und steigt bei fehlendem Ergebnis zu übergeordneten Namen auf. Kein CAA am exakt abgefragten Namen bedeutet deshalb nicht automatisch uneingeschränkte Ausstellung. RFC 8659 §3

example.com. IN CAA 0 issue "ca.example"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:pki@example.com"

ca.example ist ein erfundener Aussteller. Übernehmen Sie stattdessen den vom tatsächlich verwendeten Aussteller dokumentierten Wert. Die Beispielpolicy soll diesen Aussteller erlauben und Wildcard-Ausstellungen sperren. Prüfen Sie vor einer Änderung sämtliche betroffenen Web-, Mail- und MTA-STS-Zertifikate. Ein Ausschluss der genutzten CA kann deren nächste Erneuerung verhindern. CAA widerruft bestehende Zertifikate nicht und schützt nicht vor einer kompromittierten CA, die Regeln missachtet. RFC 8659 §§4–5

CAA für öffentliche TLS-Zertifikate ist nicht automatisch eine Regel für S/MIME oder BIMI-Markenzertifikate. Dafür bestehen eigene Tags und Ausstellungsregeln, etwa issuemail für S/MIME und issuevmc für Markenzertifikate. RFC 9495, BIMI

An einem CNAME-Namen können Sie nicht zusätzlich beliebige CAA-Daten veröffentlichen. Vor allem ist CAA kein allgemeiner Schutz gegen die Übernahme des CNAME-Ziels: Die maßgebliche Suche folgt dem Alias. RFC 2181 §10.1, RFC 8659 §3

Verwaiste Verweise und Zugänge bleiben ein eigenes Risiko

Wer einen Verwaltungszugang kontrolliert, kann falsche Daten gültig signieren lassen. Wer ein verwaistes Dienstziel übernimmt, kann unter Umständen weiterhin vorhandene Berechtigungen nutzen. Ein alter SPF-include kann neue fremde Versandadressen autorisieren; Kontrolle über SPF oder DKIM einer Subdomain kann bei relaxed Alignment einen DMARC-Pass unter derselben Organisationsdomain ermöglichen. Daraus folgt nicht, dass jede CNAME-Übernahme automatisch eine gültige DKIM-Signatur für die Hauptdomain ermöglicht. RFC 9989 §11.8

Führen Sie ein Inventar von CNAME-, NS-, MX- und SPF-Verweisen mit Verantwortlichen und Verwendungszweck. Bei einer Dienstkündigung gehört deren Entfernung zum Rückbau. Prüfen Sie zusätzlich Domainverlängerung, Wiederherstellungsmöglichkeiten, starke Anmeldung und Berechtigungen beim Registrar und DNS-Hoster. Wiederkehrende Prüfintervalle richten sich nach Änderungen und Risiko; eine pauschale Vierteljahresfrist folgt aus den hier genannten RFCs nicht. Mehr: Echospoofing und SubdoMailing.

DNS-Anbieter und Migration nach Fähigkeiten auswählen

Fragen Sie nach Signierung, unterstützten Algorithmen, DS-/DNSKEY-Verfahren mit Ihrem Registrar, Schlüsselrotation, Export, Störungsdiagnose und Übergabeverfahren. Eine Oberfläche mit einem DNSSEC-Schalter belegt nicht, dass die Delegation fertig und jeder Mailpfad validiert ist. Entscheidend für DANE ist zusätzlich der Betreiber der MX-Hostzone.

Ein unsignierter Secondary ist kein verlässlicher Ausweichweg für eine über DS abgesicherte Zone. Konkrete Providerkombinationen müssen die nötigen Transfers und Signiermodelle tatsächlich unterstützen. RFC 8901

Vor einem Wechsel: Export und Rückweg sichern, neue Zone vollständig vorbereiten, Delegation/DS-Verfahren mit beiden Betreibern festlegen, alte und neue Antworten einschließlich Signaturen prüfen, Cachezeiten einplanen. Ein kooperativer Wechsel kann die Kette erhalten; bei anderen Verfahren kann eine bewusst geplante vorübergehende unsignierte Phase nötig sein. Das ist kein universelles Klickrezept. Lassen Sie nie einen alten DS auf verschwundene Schlüssel zeigen. RFC 6781 §4.3.5

Prüfung: DNS-Antwort, TLS-Verbindung und Nachrichtenfluss trennen

Ein DNS-Werkzeug kann Records und Status zeigen; vollständige DNSSEC-Diagnose benötigt die Validierungskette. Ein DANE-fähiger SMTP-Client muss zusätzlich den tatsächlich präsentierten Schlüssel mit TLSA vergleichen. Erst ein abgestimmter eigener Nachrichtenversuch belegt den getesteten Versandweg. Veröffentlichen Sie Prüfdaten mit Name, Recordtyp, Zeitpunkt, Resolver und Ergebnis, ohne aus einer Einzelprobe eine Gesamtfreigabe abzuleiten.

Der E-Mail Security Check hat im hier geprüften Produktstand folgende Grenzen:

Der Scanner validiert DNSSEC-Signaturen nicht selbst. Das AD-Bit ist nur mit passender Resolververtrauensgrenze aussagekräftig; ein beliebiges gesetztes Bit reicht nicht. Authentifizierte Nichtexistenz belegt das Fehlen der angefragten Daten, keinen funktionierenden Maildienst. Antworten können aus Caches stammen. Mehr zum ausgewählten SMTP-Pfad: MX-Infrastruktur.

DNSSEC- und TLSA-Abfragen verbrauchen nicht das SPF-Limit von zehn DNS-auslösenden Termen. Das ist eine eigene Grenze innerhalb der SPF-Auswertung, kein gemeinsames Paketbudget für alle E-Mail-Sicherheitsverfahren. RFC 7208 §4.6.4

Technischer Befund und organisatorischer Nachweis

DNSSEC, DANE und CAA können Teil eines Sicherheitskonzepts sein. Ob eine Richtlinie oder gesetzliche Pflicht erfüllt ist, lässt sich daraus allein nicht ablesen. Die E-Mail-Compliance behandelt Geltungsbereiche und die nötige Dokumentation. Ein Außencheck ersetzt weder den Nachweis des tatsächlichen Betriebs noch eine Vorfallsanalyse.