Red Sift Leitfaden zur E-Mail-Protokollkonfiguration
Erfahren Sie mehr über DANE und DNSSEC
Was ist DANE?
DNS-Based Authentication of Named Entities, kurz DANE, ist eine Methode, ein Zertifikat einer Domain zuzuordnen, ohne sich auf externe Drittparteien verlassen zu müssen. DANE bietet einen sicheren Kommunikationskanal zwischen Sender und Empfänger und stellt sicher, dass der Sender tatsächlich mit dem richtigen Empfänger kommuniziert. Gleichzeitig wird verhindert, dass MITM die E-Mail während des Transports abfängt oder verändert.
Veröffentlicht unter RFC 7671, stellt es einen neuen Internet-Standard für die Einrichtung von TLS (Transport Layer Security) zwischen einem Client und einem Server dar – ohne dass vertrauenswürdige Certificate Authorities (CAs) erforderlich sind.
Das traditionelle CA-Modell, auf das TLS bisher angewiesen war, ermöglicht es jeder CA, ein Zertifikat für jede beliebige Domain auszustellen. DANE geht einen anderen Weg: Es setzt auf die DNSSEC-Infrastruktur (Domain Name System Security Extensions), um einen Domainnamen an ein Zertifikat zu binden.
Warum wurde DANE entwickelt?
Es gibt zwei Hauptgründe:
1) Unsachgemäßer Gebrauch vertrauenswürdiger Drittanbieter-CAs
Angreifer können sich manchmal erfolgreich als Person oder Service ausgeben und ein betrügerisches Zertifikat erhalten. Obwohl dieses Zertifikat gültig ist und von einer vertrauenswürdigen Drittpartei ausgestellt wurde, ist es nicht für die vorgesehene Person bestimmt.
2) Verhinderung von MITM-Angriffen (Man-In-The-Middle)
Beim MITM-Angriff schaltet sich ein Angreifer zwischen Client und Server, indem er die Kommunikation abfängt, und täuscht so beiden Parteien vor, sie würden miteinander kommunizieren. Dies kann zu einem TLS-Down-Grade oder Cache-Poisoning führen.
Kann DANE von jeder Anwendung genutzt werden?
Solange die Anwendung zum Verbindungsaufbau TLS nutzt und der Service über Domainnamen identifiziert wird, ist DANE universell einsetzbar. Es ist abwärtskompatibel: Falls ein Mailserver DANE nicht unterstützt, kann der Client auf STARTTLS oder sogar unverschlüsselte Übertragung zurückfallen. DANE wurde so konzipiert, dass es schrittweise eingeführt und gleichzeitig mit der bestehenden E-Mail-Infrastruktur genutzt werden kann. Eine zunehmende Verbreitung von DANE wird wiederum die Nutzung von DNSSEC fördern – und umgekehrt.
Was wird für die Einführung von DANE benötigt?
- Sicherheitsbewusster Resolver, der DNSSEC- und TLSA-Einträge abfragen und validieren kann
- DNSSEC-signierte Zone und RRsets
Wie erreicht DANE das?
DANE nutzt das bereits existierende DNSSEC-Protokoll, um sicherzustellen, dass die empfangenen Daten authentisch sind und nicht manipuliert wurden. Zusätzlich führt DANE einen neuen DNS-Resource-Record-Typ namens TLSA ein, damit der Client erkennen kann, dass ein Server TLS unterstützt.
Für jede Anwendung, die TLS nutzt, muss ein TLSA-Record eingerichtet werden. Diese Anwendungen laufen jeweils auf unterschiedlichen Ports und abhängig von der Portnummer kann ein TLSA-Record existieren.
Haben MTA-STS und DANE das gleiche Ziel? Welches Protokoll soll ich implementieren?
Die Empfehlung ist, sowohl MTA-STS als auch DANE zu implementieren. Viele Regierungen verlangen den Einsatz von DANE, sodass öffentliche Einrichtungen in der EU häufig zur Umsetzung verpflichtet sind.
DANE und MTA-STS helfen jeweils nur, wenn der Absender dies unterstützt; viele Absender nutzen jedoch nur eines der beiden Protokolle. Durch die Implementierung beider wird insgesamt ein größeres Maß an Sicherheit erreicht. Organisationen führen im Jahr 2026 oft zuerst MTA-STS für eine breitere Kompatibilität ein und ergänzen anschließend DANE für erhöhte Sicherheit, wo es erforderlich ist.
Was ist DNSSEC?
DNS ist standardmäßig nicht sicher. Ein rekursiver Resolver akzeptiert bei einer Abfrage einfach jede Antwort, ohne deren Echtheit zu überprüfen. Zudem werden Antworten zwischengespeichert, um die Geschwindigkeit zu erhöhen. Gelingt es einem Angreifer, gefälschte DNS-Daten in den Cache eines Resolvers einzuschleusen, wird jede Abfrage solange mit der manipulierten Antwort beantwortet, bis der Cache abläuft. Das nennt man DNS-Cache-Poisoning.
Beim E-Mail-Verkehr ist das Risiko direkt: Wenn Ihr Mailserver das MX-Record einer Ziel-Domain abfragt, vertraut er auf die Antwort. Sollte das MX-Record kompromittiert und auf einen Server des Angreifers umgeleitet sein, gelangt Ihre E-Mail in die falschen Hände – ohne dass der Absender davon erfährt.
DNSSEC (Domain Name System Security Extensions) löst dieses Problem durch den Einsatz kryptografischer Signaturen für DNS-Daten. Die Inhaber der Zonen signieren ihre Records mit einem privaten Schlüssel und veröffentlichen den zugehörigen öffentlichen Schlüssel im DNS. Wenn ein Resolver eine mit DNSSEC signierte Antwort erhält, prüft er die Signatur anhand des öffentlichen Schlüssels. Wurden die Daten auf dem Transportweg verändert, stimmt die Signatur nicht mehr überein und die Antwort wird verworfen.
Das System funktioniert über eine Vertrauenskette: Der öffentliche Schlüssel einer Zone wird jeweils mit dem privaten Schlüssel der übergeordneten Zone signiert. Zum Beispiel wird der öffentliche Schlüssel der redsift.io-Zone von der .io-Zone signiert, ihrerseits wiederum von der Root-Zone. Resolver haben einen Trust Anchor für die Root-Zone und können durch die Kette jede signierte Zone validieren. Solange jede Zone auf dem Pfad signiert ist, wird Vertrauen aufgebaut.
DNSSEC authentifiziert DNS-Daten mittels digitaler Signaturen. Es verschlüsselt keine Anfragen oder Antworten. Es bestätigt lediglich, dass die empfangenen Daten exakt von der Zoneninhaberin veröffentlicht wurden und sie nicht manipuliert wurden.
DNSSEC ist eine Voraussetzung für DANE (siehe oben). DANE nutzt die DNSSEC-Infrastruktur, um Zertifikate an Domainnamen zu binden. Ohne DNSSEC können TLSA-Records von DANE nicht vertraut werden, da ein Angreifer sie fälschen könnte.
Weitere Details zur Spezifikation finden Sie unter RFC 4033, RFC 4034 und RFC 4035. Die ursprüngliche DNSSEC-Spezifikation (RFC 2535) wurde wegen Skalierungsproblemen ersetzt. Lesen Sie mehr dazu und zur NIST DNS-Aktualisierung in unserem Blog.
Häufig gestellte Fragen: Leitfaden zur E-Mail-Protokollkonfiguration
In der Zeit vor DMARC wurde in SPF-Einträgen häufig der Mechanismus „-all“ verwendet, um Absender-Policies strikt durchzusetzen. Die aktuellen Branchenempfehlungen für das Jahr 2026 bevorzugen jedoch „~all“, um Sicherheit und Zustellbarkeit ausgewogen zu gestalten und das unnötige Ablehnen legitimer E-Mails, die bei SPF durchfallen, aber DKIM und DMARC bestehen, zu vermeiden.
Der Grund dafür ist, dass „~all“ in Kombination mit DMARC (bei p=reject) weiterhin die Nichtzustellung von nicht-authentifizierten E-Mails ermöglicht, wenn SPF und DKIM fehlschlagen, ohne legitime E-Mails zu blockieren – dadurch wird die Gesamtzustellbarkeit verbessert.
Die DMARC-Spezifikation (RFC 7489) gibt an, dass ein Präfix „-“ beim SPF-Mechanismus des Absenders – wie „-all“ – dazu führen kann, dass eine E-Mail vorab abgelehnt wird, d.h. noch bevor DMARC greift. Verwenden Sie „-all“ nur für inaktive Domains, die nie E-Mails versenden. DMARC unterscheidet nicht zwischen Soft Fail und Hard Fail im SPF – beide werden schlicht als SPF-Fehler gewertet.
DMARC verlangt nicht nur, dass SPF oder DKIM besteht, sondern auch, dass mindestens eine der mit SPF oder DKIM genutzten Domains mit der Domain im From-Header übereinstimmt. Eine korrekte Übereinstimmung ist 2026 entscheidend für die E-Mail-Zustellung, denn die wichtigsten E-Mail-Anbieter setzen nun diese Anforderungen voraus.
Für SPF bedeutet Identifikationsabgleich, dass die Überprüfung von MAIL FROM/Return-PATH erfolgreich ist und dass der Domain-Teil von MAIL FROM/Return-PATH mit der Domain der From-Adresse übereinstimmt. Im Strict-Alignment-Modus müssen die Domains identisch sein, während im Relaxed-Alignment-Modus auch Subdomains akzeptiert werden, sofern sie zur gleichen Organisationsdomain gehören.
Beispiel: Ist der MAIL-FROM/RETURN-PATH @ondmarc.com und der From-Header @knowledge.ondmarc.com, sind sie im Strict-Mode nicht aligned. Im Relaxed-Mode würde DMARC die E-Mail jedoch validieren.
Ein DMARC-Aggregatbericht enthält Informationen zum Authentifizierungsstatus von Nachrichten, die im Namen einer Domain gesendet wurden. Es handelt sich um einen XML-Bounce-Report, der einen Überblick darüber gibt, welche E-Mails SPF und DKIM bestanden oder nicht bestanden haben. So erhalten Domaininhaber genaue Einblicke, von welchen Quellen E-Mails im Namen ihrer Domain versendet werden und was mit diesen E-Mails geschieht (Policy des Empfängers).
Empfänger schauen hierzu auf den 'rua'-Tag Ihres DMARC-Eintrags, um die Berichte zu senden. Sie können das Aggregatbericht-Intervall mit dem Tag ri im DMARC-Eintrag festlegen (Standardwert: 86400 Sekunden, also 24h). Forensik-Berichte liefern deutlich detailliertere Informationen zu jedem Authentifizierungsfehler. Personenbezogene Daten werden entfernt, aber alle für die DMARC-Problembehebung nützlichen Informationen wie Header-Fehler für SPF/DKIM, vollständige Absenderadresse und Betreff werden übermittelt.
Die Empfangsadresse für DMARC-Forensik-Berichte wird per 'ruf'-Tag angegeben. Nicht alle Empfängersysteme unterstützen Forensik-Berichte. Red Sift OnDMARC ist eine der wenigen DMARC-Lösungen, die Forensik-Berichte empfangen kann – dank Partnerschaft mit Yahoo.
Ein SPF-Makro ist ein Mechanismus in SPF-Einträgen, mit dem wiederverwendbare Mengen von IP-Adressen festgelegt werden können. SPF-Makros bieten größere Flexibilität und Wartbarkeit, da Sie komplexe IP-Sets in einem Mechanismus definieren und in mehreren SPF-Einträgen referenzieren können. Beispiel: Statt jede zugelassene IP einzeln aufzulisten, können Sie ein Makro wie „%{i}“ verwenden, das auf die ausgehende IP des E-Mails verweist. So behalten Sie leichter die Kontrolle über große IP-Listen, ohne das SPF-Lookup-Limit zu überschreiten, und verschleiern beim DNS-Lookup autorisierte IPs.
Je nach Aufbau des SPF-Makro-Eintrags kann fehlende Makro-Entwicklung jedoch zu SPF-Fehlern oder zu einem neutralen Ergebnis (?all) führen. Falls SPF-Makros für die Erlaubnis legitimer Sende-Server entscheidend sind, können E-Mails leichter an SPF-Kontrollen scheitern oder von SPF-basierten Systemen als suspekt eingestuft werden.
Mail Transfer Agent Strict Transport Security (MTA-STS) ist ein Standard zur Verschlüsselung von Nachrichten zwischen zwei Mailservern. Er teilt sendenden Mailservern mit, dass E-Mails nur über eine sichere Verbindung mittels Transport Layer Security (TLS) übertragen werden dürfen und schützt so vor Abfangen durch Cyberkriminelle.
Die Einführung von MTA-STS hat deutlich zugenommen; Organisationen werden 2026 Transportsicherheit als unerlässlich für den Schutz von E-Mails im Transit betrachten. Zur Aktivierung von MTA-STS auf einer Empfängerdomain müssen Sie die Unterstützung per DNS bekannt machen und eine Policy-Datei auf Ihrer Website bereitstellen.
MTA-STS sollte vorsichtig aktiviert werden, um nicht unbeabsichtigt die E-Mail-Zustellung zu blockieren. Es empfiehlt sich, den Modus Test zuerst zu verwenden, damit Sie mit Hilfe von TLS-Berichten Fehler aufdecken und beheben können, bevor Sie den strikten Modus aktivieren. Dieses schrittweise Vorgehen wird 2026 voraussichtlich zum Standard für sichere E-Mail-Transportsicherheit.
SMTP TLS Reporting (TLS-RPT) dient laut RFC8460 dazu, TLS-Konnektivitätsprobleme von sendenden MTAs zu melden. Wie bei DMARC werden auch hier Berichte per E-Mail an den Domaininhaber gesendet, wenn TLS-Probleme die Zustellung verhindern. Die Berichte enthalten erkannte MTA-STS-Policies, Traffic-Statistiken, fehlgeschlagene Verbindungen und Fehlerursachen.
Mit der MTA-STS-Funktion in Red Sift OnDMARC müssen Sie sich nicht um komplexe Bereitstellungen kümmern. Sie fügen die von OnDMARC bereitgestellten MTA-STS Smart Records zu Ihrem DNS hinzu und Red Sift übernimmt das Hosting der MTA-STS-Policy-Datei, das SSL-Zertifikatmanagement und meldet gefundene Verstöße automatisiert per TLS-Bericht. 2026 gehört gehostetes MTA-STS bei modernen DMARC-Plattformen immer öfter zum Standard, was die Einführung der Transportverschlüsselung deutlich vereinfacht.
Gemäß RFC 7671 ist DANE (DNS-based Authentication of Named Entities) ein neuer Internetstandard zur Etablierung von TLS-Kommunikation zwischen Client und Server ohne Abhängigkeit von klassischen Certificate Authorities (CAs).
Im traditionellen Modell kann jede CA für jede Domain ein Zertifikat ausstellen. DANE verfolgt einen anderen Ansatz und nutzt die DNSSEC-Infrastruktur (Domain Name System Security Extensions), um einen Domainnamen kryptografisch mit einem Zertifikat zu verbinden. DANE nutzt das bestehende DNSSEC-Protokoll, um Empfangs-Authentizität und Integrität zu gewährleisten.
DANE führt außerdem einen neuen DNS Resource Record Typ TLSA ein, der dem Client signalisiert, dass der Server TLS unterstützt. Es wird empfohlen, sowohl MTA-STS als auch DANE einzurichten. DANE ist für zahlreiche Behörden verpflichtend, insbesondere in der EU für öffentliche Einrichtungen.
DANE und MTA-STS sind nur dann sinnvoll, wenn auch der Versandserver die Mechanismen unterstützt – viele implementieren jedoch nur einen der beiden Ansätze. Beide Standards zu aktivieren, erhöht daher die Gesamtsicherheit. 2026 setzen Organisationen häufig zuerst MTA-STS zur maximalen Kompatibilität ein und ergänzen anschließend DANE, wenn ein höheres Sicherheitsniveau gefordert wird.
Die Subdomain-Policy ermöglicht es Administratoren, verschiedene Domains und Subdomains je nach Stand der DMARC-Einführung individuell zu schützen. Wenn beispielsweise alle Ihre Versanddienste für die Hauptdomain richtig mit SPF und DKIM abgesichert sind, können Sie Ihre Hauptdomain mit einer DMARC-Policy p=reject schützen, für Subdomains aber p=none einsetzen – oder umgekehrt.
Wenn ein Versanddienst kein DMARC unterstützt (also kein SPF oder DKIM implementiert), können Sie diesem Dienst eine eigene Subdomain mit separater DMARC-Policy zuweisen, ohne den Schutz der übrigen Domains zu beeinträchtigen. Dadurch können Sie den Traffic auf verschiedene Subdomains verteilen und jede je nach Bedarf absichern.