SPF vs. DKIM: Was ist der Unterschied und braucht man beides?

Einführung

Viele SPF-Fehler werden nicht durch einen falsch konfigurierten Eintrag verursacht, sondern treten auf, weil die E-Mail weitergeleitet wurde.

Ein IT-Administrator richtet SPF korrekt ein, überprüft, ob die Überprüfung erfolgreich ist, und betrachtet die Aufgabe als erledigt. Dann leitet ein Benutzer eine Nachricht über einen Relay-Server eines Drittanbieters weiter. Der empfangende Server erkennt eine IP-Adresse, die nicht auf der Liste der autorisierten Adressen steht, die Überprüfung schlägt fehl, der Administrator überprüft den Eintrag und alles sieht in Ordnung aus. Das Problem liegt nicht im Eintrag, sondern in der Funktionsweise von SPF.

SPF allein reicht für die E-Mail-Authentifizierung nicht aus, und SPF und DKIM dienen nicht demselben Zweck. Jedes Protokoll schützt eine andere Ebene des E-Mail-Zustellungsprozesses. Entfernt man eines der beiden, entstehen Lücken, die sowohl Weiterleitungsinfrastrukturen als auch Angreifer auf unterschiedliche Weise und aus unterschiedlichen Gründen ausnutzen können.

In diesem Blog erfahren Sie, was SPF von DKIM unterscheidet, warum das Weiterleiten des einen, nicht aber des anderen funktioniert und warum beide erforderlich sind, damit DMARC funktioniert.

Was ist der Lichtschutzfaktor (LSF) und wie funktioniert er?

SPF (Sender Policy Framework) ist ein E-Mail-Authentifizierungsprotokoll, mit dem ein Domaininhaber festlegen kann, welche Mailserver berechtigt sind, E-Mails im Namen der Domain zu versenden.

Die Domain veröffentlicht einen SPF-Eintrag in ihrem DNS als TXT-Eintrag , in dem die zugelassenen IP-Adressen und Server aufgeführt sind. Wenn ein empfangender Mailserver eine Nachricht erhält, gleicht er die Domain des Absenders mit diesem veröffentlichten Eintrag ab, um zu überprüfen, ob der sendende Server zugelassen ist. 

Anhand des Ergebnisses entscheidet der Empfänger, ob er die Nachricht akzeptiert, markiert oder ablehnt. SPF dient dazu, Spammer und Angreifer daran zu hindern, die Absenderadresse zu fälschen, wodurch E-Mail-Spoofing und Phishing. Es arbeitet mit DKIM und DMARC zusammen, um die Legitimität von Nachrichten zu überprüfen. 

Was SPF überprüft

SPF prüft, ob der Server, der eine Nachricht sendet, berechtigt ist, E-Mails für die Domain zu versenden, von der er angeblich stammt. Dies geschieht in dem Moment, in dem ein empfangender Server die eingehende Verbindung akzeptiert, noch bevor er den Nachrichtentext verarbeitet.

SPF überprüft jedoch nicht die Absenderadresse, die Ihre Empfänger tatsächlich sehen. Es überprüft lediglich den „Envelope-Absender“, auch als „Return-Path“ oder „MAIL FROM“ bezeichnet, also die Adresse, die hinter den Kulissen während der SMTP-Transaktion verwendet wird. 

Ein Angreifer kann also die SPF-Prüfung für die Absenderdomain bestehen und dennoch eine gefälschte Absenderadresse im Posteingang anzeigen. DMARC hilft dabei, diese Lücke zu schließen, indem es das SPF-Ergebnis mit der sichtbaren Absenderdomain verknüpft.

Der empfangende Server benötigt zwei Eingaben: 

1. Die Absender-IP-Adresse
2. Die Domain des Absenders

Anschließend sucht es den SPF-Eintrag dieser Domain im DNS. Dabei durchläuft es die Mechanismen des Eintrags der Reihe nach, beispielsweise ip4, ip6, a, mxund include. Wenn die Absender-IP mit einer autorisierten Quelle übereinstimmt, besteht der SPF-Test. Wenn er bis zum abschließenden „all“-Mechanismus -Mechanismus ohne Übereinstimmung gelangt, hängt das Ergebnis davon ab, wie Sie diesen Mechanismus konfiguriert haben.

SPF gibt kein einfaches „Ja“ oder „Nein“ zurück. Es gibt eines der folgenden Ergebnisse zurück:

• Pass: Der Server ist autorisiert.
• Fehlschlag (-all): Nicht autorisiert. Sie möchten, dass diese E-Mail abgelehnt wird.
• SoftFail (~alle): Wahrscheinlich nicht autorisiert. Akzeptieren, aber als verdächtig markieren.
• Neutral (?alle): Du machst keinerlei Aussage in die eine oder andere Richtung.
• Keine: Für die Domain existiert kein SPF-Eintrag.
• PermError / TempError: Der Eintrag ist beschädigt oder ein DNS-Problem hat die Abfrage blockiert.

Der empfangende Server wertet dieses Ergebnis als einen weiteren Hinweis neben DKIM und DMARC aus, um die Legitimität der E-Mail zu prüfen, bevor Ihre Nachricht zugestellt, markiert oder abgelehnt wird. 

Was ist DKIM und wie funktioniert es?

DKIM (DomainKeys Identified Mail) ist ein E-Mail-Authentifizierungsprotokoll, das jeder von einer Domain versendeten Nachricht eine kryptografische Signatur hinzufügt. Der sendende Server signiert die Nachricht mit einem privaten Schlüssel und fügt die Signatur in den Header der E-Mail ein. Die Domain veröffentlicht den passenden öffentlichen Schlüssel in ihrem DNS als TXT-Eintrag. 

Wenn ein empfangender Server die Nachricht erhält, ruft er diesen öffentlichen Schlüssel ab und überprüft die Signatur. Eine gültige Signatur bestätigt zwei Dinge: 

1. Die Nachricht stammt tatsächlich von der angegebenen Domain
2. Der Inhalt wurde während des Transports nicht verändert. 

DKIM dient dazu, Manipulationen und Absenderfälschungen zu verhindern, und arbeitet zusammen mit SPF und DMARC daran, die Echtheit von Nachrichten zu überprüfen. 

Was DKIM signiert

DKIM signiert zwei Teile jeder Nachricht: eine ausgewählte Gruppe von Header-Feldern und den Nachrichtentext. Es signiert weder den Envelope noch die IP-Adresse des Absenders oder irgendetwas außerhalb dieser beiden Bereiche. Darin liegt der Unterschied zwischen den beiden Protokollen: SPF überprüft den Envelope und den sendenden Server, während DKIM die Nachricht selbst signiert.

Die Signatur wird nicht auf den Rohtext angewendet. Der sendende Server erstellt einen Hashwert aus dem Nachrichtentext und den ausgewählten Headern und verschlüsselt diesen Hashwert anschließend mit seinem privaten Schlüssel. Das Ergebnis wird in den DKIM-Signature-Header geschrieben, den der Server der Nachricht hinzufügt. Innerhalb dieses Headers geben einige Tags dem Empfänger genau an, was signiert wurde:

• h= listet die in der Signatur enthaltenen Kopfzeilenfelder auf, wie z. B. „Von“, „An“, „Betreff“ und „Datum“.
• bh= enthält den Hash des Nachrichtentextes.
• b= enthält die Signatur selbst, den verschlüsselten Hash der signierten Header.
• c= legt die Kanonisierung fest, die bestimmt, wie genau Leerzeichen und Formatierung übereinstimmen müssen.

Der „From“-Header ist immer signiert. DKIM schreibt dies vor, da es darum geht, die Signatur an die Domain zu binden, die der Empfänger tatsächlich sieht.

Alles, was nicht unter „h=“ aufgeführt ist, ist nicht geschützt. Befindet sich ein Header nicht in dieser Liste, kann er während der Übertragung geändert werden, ohne dass die Signatur ungültig wird. Der Hauptteil wird vollständig abgedeckt, es sei denn, das optionale „l=“-Tag beschränkt die Signatur auf den ersten Teil davon; aus diesem Grund wird von der Verwendung von „l=“ generell abgeraten. Jeder Inhalt, der nach der signierten Länge hinzugefügt wird, würde ungesigniert durchrutschen.

Wenn ein empfangender Server die DKIM-Signatur überprüft, berechnet er den Hash des Nachrichtentextes und den Hash des Headers neu, entschlüsselt b= mit Ihrem veröffentlichten öffentlichen Schlüssel und vergleicht die beiden Werte. Stimmen beide überein, ist die Signatur gültig und die signierten Teile der Nachricht sind unverändert angekommen.

SPF vs. DKIM

SPF und DKIM lösen zwei unterschiedliche Probleme. SPF legt fest, welche Server E-Mails im Namen Ihrer Domain versenden dürfen, während DKIM mithilfe einer kryptografischen Signatur nachweist, dass eine Nachricht nicht verändert wurde und tatsächlich von Ihrer Domain stammt. Hier finden Sie einen kurzen Überblick über die Unterschiede zwischen SPF und DKIM.

Keines der beiden Protokolle weiß, was das andere weiß.

SPF kann zwar bestätigen, dass eine Nachricht von einem autorisierten Server stammt, doch sobald diese Nachricht den Server verlassen hat, hat SPF keinen Einblick mehr darin, was damit geschehen ist. 

Ebenso kann DKIM bestätigen, dass der Inhalt unverändert angekommen ist und dass die signierende Domain über den privaten Schlüssel verfügte, sagt jedoch nichts darüber aus, ob dieser Server überhaupt die Berechtigung zum Versenden hatte.

Das bedeutet es, wenn ein empfangender Server beide Ergebnisse auswertet:

DMARC liest beide Ergebnisse und wendet Ihre veröffentlichte Richtlinie entsprechend der Übereinstimmung mit der Von -Domäne. Deshalb sind die beiden Protokolle so konzipiert, dass sie sich ergänzen und nicht miteinander konkurrieren.

Warum versagt SPF bei der Weiterleitung, DKIM jedoch nicht?

Das SPF-Weiterleitungsproblem

SPF bricht ab, wenn eine E-Mail weitergeleitet wird. Dies ist einer der häufigsten Gründe, warum eine legitime Nachricht die SPF-Prüfung nicht besteht, und es hängt direkt mit der Funktionsweise des Protokolls zusammen.

SPF gleicht die IP-Adresse des verbindenden Servers mit dem SPF-Eintrag der Domain des Absenders ab. Durch Weiterleitungen kommt es zu Abweichungen. Wenn ein Server eine Nachricht weiterleitet, geschehen drei Dinge:

1. Der Weiterleitungsserver wird zur neuen Verbindungs-IP.
2. Der Absender des Umschlags verweist weiterhin auf die Domain des ursprünglichen Absenders.
3. Der SPF-Eintrag der ursprünglichen Domain enthält den Weiterleitungsserver nicht, daher wird bei der Überprüfung der Status „Fail“ zurückgegeben.

Ein Beispiel: Eine Nachricht von Ihrer Domain besteht die SPF-Prüfung beim ersten Hop. Der Server des Empfängers leitet sie dann an eine zweite Adresse weiter, beispielsweise an ein Alumni-Konto oder eine Mailingliste. An diesem zweiten Ziel ist die verbindende IP-Adresse nun die des Weiterleitungsservers, doch im „Return-Path“ wird weiterhin Ihre Domain angezeigt. Da Ihr SPF-Eintrag diesen Server nie autorisiert hat, schlägt die SPF-Prüfung fehl, obwohl die Nachricht echt ist.

Dies tritt am häufigsten bei folgenden Fällen auf:

• Mailinglisten
• Regeln für die automatische Weiterleitung auf Kontoebene in Gmail oder Outlook
• Ehemalige Mitarbeiter oder rollenbasierte Weiterleitungsadressen
• Spamfilter und Gateways, die E-Mails weiterleiten

Zwei Dinge verhindern, dass weitergeleitete E-Mails abgelehnt werden:

1. SRS (Sender Rewriting Scheme): Der Weiterleitungsserver schreibt den Return-Path vor der Weiterleitung der Nachricht auf seine eigene Domain um. SPF prüft dann anhand der Domain des Weiterleiters, der diesen Server autorisiert, sodass die Prüfung erfolgreich ist. Die meisten seriösen Weiterleitungsdienste wenden SRS automatisch an.
2. DKIM und DMARC: Eine DKIM-Signatur bleibt bei der Weiterleitung erhalten, solange der Weiterleitende den signierten Inhalt nicht verändert. Selbst wenn SPF bei einer weitergeleiteten Nachricht versagt, kann DKIM also weiterhin bestehen, und DMARC benötigt nur, dass eines der beiden übereinstimmt. Dies ist der Hauptgrund, warum Sie sich nicht allein auf SPF verlassen sollten.

Warum DKIM bei der Weiterleitung funktioniert

DKIM bleibt auch bei der Weiterleitung erhalten, da es die Nachricht selbst signiert und nicht den Weg, den die Nachricht zurücklegt. Die Signatur befindet sich im DKIM-Signature-Header und wird somit bei jedem Schritt mit der E-Mail weitergeleitet. Unabhängig davon, wie viele Server die Nachricht weiterleiten, ist die Signatur noch vorhanden, wenn sie ihr endgültiges Ziel erreicht.

Die Überprüfung hängt auch nicht vom verbindenden Server ab. Der Empfänger ruft den öffentlichen Schlüssel der signierenden Domain aus dem DNS dieser Domain ab und verwendet ihn zur Überprüfung der Signatur. Die IP-Adresse, von der die Nachricht stammt, spielt dabei keine Rolle. Dies steht im Gegensatz zu SPF, das bei der Weiterleitung versagt, gerade weil es die IP-Adresse des Verbindenden überprüft und sich diese IP-Adresse bei der Weiterleitung ändert.

Solange der Weiterleiter die Nachricht weiterleitet, ohne den signierten Inhalt zu verändern, stimmen der Body-Hash und der Header-Hash weiterhin überein, und DKIM wird bestanden.

DKIM übersteht eine einfache Weiterleitung, ist aber nicht gegen alles gefeit. Die Signatur wird ungültig, wenn ein Zwischenglied den signierten Inhalt verändert. Die häufigsten Verursacher sind Mailinglisten, die oft:

• Füge eine Fußzeile oder einen Abmeldelink in den Text ein
• Füge der Betreffzeile ein Tag wie [list-name] hinzu
• Kopfzeilen, die in die Signatur fallen, neu schreiben oder einfügen

Jede dieser Änderungen verändert den Hash, und die Signatur ist nicht mehr gültig. ARC (Authenticated Received Chain) wurde genau für diesen Fall entwickelt, um die ursprünglichen Authentifizierungsergebnisse zu bewahren, während eine Nachricht Zwischenstellen durchläuft, die sie verändern.

Aus diesem Grund ist DKIM für weitergeleitete E-Mails im Rahmen von DMARC von Bedeutung. DMARC gilt als bestanden, wenn entweder SPF oder DKIM bestanden wird und mit der Absenderdomäne übereinstimmt. Bei weitergeleiteten Nachrichten scheitert SPF in der Regel, daher ist DKIM entscheidend die DMARC-Übereinstimmung zusammenhält. Die signierende Domain bleibt bei der Weiterleitung unverändert, sodass die Übereinstimmung erhalten bleibt. Wenn Sie sich allein auf SPF verlassen und E-Mails von Ihrer Domain weiterleiten, kann dies zu einem DMARC-Fehler führen und die E-Mails im Spam-Ordner landen.

Wie arbeiten SPF, DKIM und DMARC zusammen?

SPF und DKIM lösen jeweils ein anderes Problem, aber keines der beiden Verfahren sorgt für sich allein für die Durchsetzung. DMARC verknüpft ihre Ergebnisse mit einer Maßnahme und ordnet beide Prüfungen der Domain zu, die Ihre Empfänger tatsächlich sehen.

Folgendes geschieht, wenn ein empfangender Server eine eingehende Nachricht auswertet:

1. SPF wird zuerst ausgeführt: Der Server liest den Absender des Umschlags, die MAIL FROM -Adresse, die während der SMTP-Sitzung ausgetauscht wurde, nicht den „From“-Header, den der Empfänger sieht, und gleicht die Absender-IP mit Ihrem SPF-Eintrag ab. Ist die IP autorisiert, besteht die SPF-Prüfung. Ist dies nicht der Fall, scheitert sie.
2. Als Nächstes wird DKIM ausgeführt: Der Server liest die DKIM-Signature -Header, sucht Ihren öffentlichen Schlüssel im DNS anhand der Selektor- und Domain-Tags und vergleicht die kryptografische Signatur mit dem Inhalt der Nachricht. Eine gültige Signatur bestätigt, dass die Nachricht von einer Domain stammt, die den privaten Schlüssel kontrolliert, und dass sie während der Übertragung nicht verändert wurde.
3. DMARC wird zuletzt ausgewertet: Es ruft Ihren Richtlinien-Datensatz ab und überprüft die Übereinstimmung:
   1. Stimmt die Domain, die die SPF-Prüfung bestanden hat, mit Ihrer Absender-Domain überein? 
   2. Gilt das d= Tag in der DKIM-Signatur mit Ihrer Absender-Domain übereinstimmen? 

Wenn eine der beiden Bedingungen erfüllt ist, wird DMARC bestanden. Ihre veröffentlichte Richtlinie legt dann fest, was mit der Nachricht geschieht.

Was „Ausrichtung“ in der Praxis bedeutet

SPF lässt jede Domain zu, die im Absenderfeld des Umschlags aufgeführt ist. DKIM lässt jede Domain zu, für die ein gültiger Signaturschlüssel vorliegt. Keine dieser beiden Prüfungen allein bestätigt den „From“-Header, das Feld, das [email protected] im Posteingang des Empfängers, legitim ist. DMARC ergänzt diese Überprüfung, indem es die authentifizierte Domain mit der „From“-Domain vergleicht.

Die Ausrichtung erfolgt in zwei Modi:

1. Im Standardmodus (dem „Relaxed“-Modus) reicht eine Übereinstimmung der Unternehmensdomain aus, wobei mail.yourcompany.com mit yourcompany.com. 
2. Im strengen Modus müssen die Domänen exakt übereinstimmen. Die meisten Unternehmen verwenden eine lockere Übereinstimmung, da der strenge Modus zu Zustellungsproblemen bei Subdomänen führt, sofern nicht jede Absenderquelle genau konfiguriert ist.

Das Ergebnis zum Vergleich zwischen legitimer und gefälschter E-Mail

Bei einer korrekt konfigurierten, legitimen Nachricht:

• Die Absender-IP stimmt mit Ihrem SPF-Eintrag überein → SPF-Prüfung bestanden
• DKIM-Signatur ist gültig, d= stimmt mit Ihrer Absender-Domain überein → DKIM-Prüfung bestanden
• Beide Ergebnisse stimmen mit Ihrer Absender-Domain überein → DMARC-Prüfung bestanden
• Dein p=ablehnen Richtlinie → Nachricht wird zugestellt

Bei einer gefälschten Nachricht, die von einem nicht autorisierten Server ohne gültigen Signaturschlüssel gesendet wurde:

• Nicht autorisierte IP-Adresse → SPF-Fehler
• Keine gültige Signatur → DKIM-Fehler
• Keines der beiden Ergebnisse stimmt mit Ihrer Absender-Domain überein → DMARC-Fehler
• Dein p=ablehnen Richtlinie → Die Nachricht wird abgelehnt, bevor sie einen Posteingang erreicht

Aus diesem Grund sind SPF und DKIM in Kombination unter DMARC wirksamer als jede der beiden Methoden für sich allein. DMARC kann beide Ergebnisse weiterleiten; wenn also SPF bei weitergeleiteten E-Mails fehlschlägt, sorgt die DKIM-Übereinstimmung dafür, dass DMARC legitime Nachrichten weiterhin zulässt. Wenn beide bei gefälschten E-Mails fehlschlagen, handelt DMARC gemäß Ihrer Richtlinie.

Sobald Ihre Domain p=quarantine oder p=reject erreicht hat und sowohl SPF als auch DKIM bestanden und aufeinander abgestimmt sind, haben Sie auch die Durchsetzungsvoraussetzung für BIMIerfüllt, dem Standard, der Ihr verifiziertes Markenlogo in unterstützenden Posteingängen wie Gmail und Apple Mail anzeigt.

Brauchen Sie sowohl SPF als auch DKIM?

Ja, Sie benötigen sowohl SPF als auch DKIM. 

Eine Domain, die SPF ohne DKIM einsetzt, verfügt über keine Integritätsprüfung auf Nachrichtenebene. Es gibt keine Möglichkeit zu überprüfen, ob der Inhalt während der Übertragung verändert wurde. Da keine DKIM-Abgleichung für DMARC vorliegt, bedeutet dies: Wenn SPF fehlschlägt (was bei jeder weitergeleiteten E-Mail der Fall sein wird), hat DMARC keine Ausweichlösung. Schon eine einzige Weiterleitungsregel zwischen dem beruflichen Posteingang eines Nutzers und seinem privaten Konto reicht aus, damit die Authentifizierung bei einer völlig legitimen E-Mail versagt.

Google und Yahoo haben beides im Februar 2024 zur Pflicht gemacht.

Google verlangt von allen Massenversendern, die täglich 5.000 oder mehr Nachrichten versenden, die Einrichtung von SPF, DKIM und einem DMARC-Eintrag. Yahoo verlangt mindestens entweder SPF oder DKIM sowie DMARC; wenn jedoch nur eine dieser Maßnahmen umgesetzt wird, werden gleichzeitig die Anforderungen von Google nicht erfüllt. Wenn Sie Nachrichten an Empfänger auf beiden Plattformen versenden, ist die Konfiguration beider Verfahren die einzige Möglichkeit, alle Anforderungen auf einmal zu erfüllen.

Selbst unterhalb der Schwelle von 5.000 Nachrichten sind diese Anforderungen bei den großen E-Mail-Anbietern praktisch zum Standard für die Zustellbarkeit geworden. 

Was das eine abdeckt, was das andere nicht abdeckt:

SPF-Prüfungen schlagen bei weitergeleiteten E-Mails gemäß RFC 7208 absichtlich fehl. Die IP-Adresse des Weiterleitungsservers ersetzt die ursprüngliche Adresse; da diese IP-Adresse nicht auf Ihrer Liste der autorisierten Adressen steht, schlägt die Prüfung fehl, obwohl eigentlich alles korrekt ist. DKIM berücksichtigt IP-Änderungen nicht. Die Signatur wird mit der Nachricht mitgesendet und gilt unabhängig davon, welche Server die Nachricht durchlaufen hat, solange der Inhalt nicht verändert wurde.

DKIM bestätigt, dass die Nachricht unverändert ist und dass die signierende Domain den privaten Schlüssel kontrolliert, sagt jedoch nichts darüber aus, ob der Server, der die Nachricht gesendet hat, über die erforderliche Berechtigung auf Netzwerkebene verfügte. Diese Überprüfung übernimmt SPF.

Keiner weiß, was der andere weiß. Wenn beide laufen, hat der empfangende Server, der Ihre E-Mail auswertet, den vollständigen Überblick, den autorisierten Pfad und den intakten Inhalt – und nicht nur die Hälfte davon.

So richten Sie SPF und DKIM ein: Eine Schritt-für-Schritt-Anleitung

Falls für Ihre Domain noch keine SPF- und DKIM-Einstellungen konfiguriert sind, ist die Einrichtung ganz einfach. Die folgenden Schritte beschreiben, was Sie tun müssen, um beide Protokolle zu konfigurieren und zu verifizieren. 

Schritt 1: Erstellen Sie Ihren SPF-Eintrag

Erstellen Sie zunächst eine Liste aller Dienste, die zum Versenden von E-Mails über Ihre Domain berechtigt sind, wie zum Beispiel:

1. Ihr primärer Mailserver
2. Marketingplattform
3. CRM
4. Helpdesk-Tool
5. Anbieter von Transaktions-E-Mails und alle anderen Dienste, die in Ihrem Namen E-Mails versenden.

Jeder autorisierte Dienst erhält eine einen Eintrag: Mechanismus in Ihrem SPF-Eintrag oder einen direkten IP-Bereich unter Verwendung von ip4: oder ip6:. Schließen Sie den Eintrag mit -all , um den empfangenden Servern mitzuteilen, dass alle IP-Adressen, die nicht auf der Liste stehen, nicht autorisiert sind.

Bevor Sie IP-Bereiche direkt mit ip4: oder ip6:hinzufügen, vergewissern Sie sich, dass die Bereiche zum richtigen Absendedienst gehören. Mit der WHOIS-IP-Abfrage von PowerDMARC können Sie die IP-Zugehörigkeit überprüfen, bevor sie in Ihren Datensatz aufgenommen wird. 

Ein einfacher SPF-Eintrag sieht wie folgt aus:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Behalten Sie die Anzahl der DNS-Abfragen im Auge, wenn Sie Dienste hinzufügen. RFC 7208 begrenzt die SPF-Auswertung auf 10 Abfragen. Zu diesen Einbindungsmechanismus verbraucht mindestens einen, und verschachtelte „include“-Anweisungen werden auf dasselbe Limit angerechnet. Die meisten Domains erreichen das Limit schneller als erwartet, sobald sie vier oder fünf Absender von Drittanbietern gleichzeitig betreiben.

Nutzen Sie den kostenlosen SPF-Generator , um Ihren Eintrag zu erstellen, ohne die Syntax manuell eingeben zu müssen, und PowerSPF , um ihn automatisch unter der Obergrenze von 10 Lookups zu halten, wenn sich Ihre Versandinfrastruktur ändert.

Schritt 2: Erstellen und veröffentlichen Sie Ihre DKIM-Schlüssel

Für jeden Dienst, der in Ihrem Namen E-Mails versendet, benötigen Sie ein DKIM-Schlüsselpaar: 

1. Ein privater Schlüssel, den der sendende Server zum Signieren ausgehender E-Mails verwendet
2. Ein entsprechender öffentlicher Schlüssel, der in Ihrem DNS veröffentlicht wurde, damit empfangende Server die Authentifizierung vornehmen können.

Wenn ein Dienst wie Google Workspace oder Microsoft 365 die DKIM-Signierung übernimmt, stellt er den öffentlichen Schlüssel und den Selektor-Namen bereit. Veröffentlichen Sie den Eintrag im DNS unter selector._domainkey.yourdomain.com und aktivieren Sie die Signierung in der Verwaltungskonsole des Dienstes.

In Umgebungen, in denen Sie Schlüssel selbst generieren, sollten Sie mindestens 2048-Bit-RSA verwenden; 1024-Bit gilt nicht mehr als ausreichend. Der kostenlose DKIM-Generator erzeugt einen veröffentlichungsfertigen DNS-Eintrag, ohne dass Befehlszeilentools erforderlich sind.

Wenn Sie DKIM über mehrere Versanddienste hinweg verwalten, übernimmt Hosted DKIM übernimmt die Schlüsselgenerierung, die DNS-Veröffentlichung und die Rotation von einem zentralen Ort aus, ohne dass jedes Mal, wenn ein Schlüssel geändert werden muss, manuelle DNS-Änderungen erforderlich sind.

Schritt 3: Einen DMARC-Eintrag hinzufügen

Sobald SPF und DKIM eingerichtet sind, fügen Sie einen DMARC-Eintrag zu Ihrem DNS hinzu. Beginnen Sie unter p=none , um aggregierte Berichtsdaten zu sammeln, ohne die E-Mail-Zustellung zu beeinträchtigen.

Ein minimaler Startdatensatz:

v=DMARC1; p=none; rua=mailto:[email protected];

p=none blockiert keine gefälschten Nachrichten. Es versetzt DMARC in den Überwachungsmodus, sodass Sie Sammelberichte erhalten, aus denen hervorgeht, welche Quellen die Authentifizierung bestehen und welche nicht, aber keine E-Mails werden unter Quarantäne gestellt oder abgelehnt. 

Nutzen Sie diese Daten, um Fehlkonfigurationen und Abweichungen zu erkennen, und fahren Sie dann fort mit p=Quarantäne und schließlich p=reject.

Eine Domain unter p=none , ist nicht vor Spoofing geschützt. Die Überwachungsphase benötigt einen definierten Endpunkt, keinen offenen Zeitrahmen.

Schritt 4: Überprüfen Sie Ihre Konfiguration

Überprüfen Sie nach der Veröffentlichung Ihrer Einträge, ob jeder einzelne korrekt aufgelöst wird, bevor Sie die Einrichtung als abgeschlossen betrachten.

Zwar ist es notwendig, dass die Einträge korrekt aufgelöst werden, doch reicht dies allein nicht aus. Führen Sie einen Live-Test durch, um sicherzustellen, dass die Authentifizierungsheader durchgehend durchkommen. Mit dem SMTP-Test-Tool von PowerDMARC ermöglicht es Ihnen, Ihre Mailserver-Verbindung zu testen und SPF, DKIM und DMARC nicht nur im DNS, sondern auch bei tatsächlich versendeten E-Mails durchlaufen. 

Häufige Fehler

Die beiden häufigsten Fehler, die in der Produktion zu Fehlern bei der Authentifizierung führen, sind: 

SPF 10 – Abfrage-Limit

SPF erlaubt maximal 10 DNS-Abfragen , wenn ein empfangender Server Ihren Eintrag auswertet – eine durch RFC 7208 festgelegte Grenze. Mechanismen wie „include“, „a“ und „mx“ lösen jeweils eine Abfrage aus und sind verschachtelt. 

Die meisten Domains überschreiten die Grenze von 10, indem sie Absender von Drittanbietern hinzufügen, da jeder Dienst, den Sie mit einem „include“ autorisieren, Lookups verbraucht. Sobald Sie das Limit überschreiten, gibt SPF einen PermErrorzurück, und empfangende Server behandeln dies als fehlerhafte Aufzeichnung, die Ihre E-Mails nicht mehr autorisiert. 

Abflachung behebt das Problem, indem es Ihre Include-Mechanismen durch die tatsächlichen IPv4- und IPv6-Bereiche ersetzt, zu denen sie aufgelöst werden, wodurch Ihre Lookup-Anzahl gegen Null sinkt.

DKIM-Schlüsselrotation

Die DKIM-Schlüsselrotation ist das Verfahren, bei dem das DKIM-Schlüsselpaar nach einem festgelegten Zeitplan ausgetauscht wird, wobei der alte private Signaturschlüssel außer Kraft gesetzt und an seiner Stelle ein neuer öffentlicher Schlüssel veröffentlicht wird. Durch die Rotation wird die Dauer begrenzt, in der ein einzelner Schlüssel zugänglich ist. Sollte ein Schlüssel jemals kompromittiert werden, bleibt der potenzielle Schaden somit gering. Die meisten Teams führen die Rotation vierteljährlich oder zweimal jährlich durch, und einige Anbieter rotieren ihre Schlüssel automatisch.

Die meisten Fehler bei der Rotation entstehen bei den Schritten rund um den Austausch. Hier sind die Punkte, die Administratoren am häufigsten übersehen.

Der alte öffentliche Schlüssel wird zu früh entfernt

Nachrichten, die sich bereits im Versand befinden, wurden mit dem alten Schlüssel signiert, und der Empfänger benötigt den passenden öffentlichen Schlüssel im DNS, um sie zu verifizieren. Löschen Sie den alten Eintrag sofort nach der Umstellung, da die noch im Versand befindlichen E-Mails sonst die DKIM-Prüfung nicht bestehen. Behalten Sie den alten Schlüssel während einer Übergangsphase im DNS, bis alle damit signierten E-Mails zugestellt wurden.

Derselbe Selektor erneut verwenden

Wechseln Sie die Selektoren ab, überschreiben Sie keinen. Veröffentlichen Sie den neuen Schlüssel unter einem neuen Selektor, verlagern Sie die Signierung dorthin und nehmen Sie den alten Selektor nach der Überlappungsphase außer Betrieb. Das Überschreiben des Datensatzes eines einzelnen Selektors führt zu einer Lücke, in der mit dem alten Schlüssel signierte E-Mails nicht mehr validiert werden können.

Wechsel, bevor die DNS-Änderungen wirksam werden

Wenn Sie den neuen Schlüssel vor der sich der neue öffentliche Schlüssel verbreitet hat, können Empfänger ihn nicht finden und DKIM schlägt fehl. Veröffentlichen Sie zuerst den neuen Eintrag, warten Sie die TTL des Eintrags ab und stellen Sie dann die Signatur um.

Das Vergessen von Absendern aus Drittanbietern

Jeder Versanddienst, wie beispielsweise Ihr ESP oder CRM, verwaltet seine eigenen DKIM-Schlüssel und Selektoren. Die Rotation Ihres primären Domänenschlüssels hat darauf keinen Einfluss. Führen Sie die Schlüsselrotation für jeden Dienst separat durch oder vergewissern Sie sich, dass der Anbieter dies für Sie übernimmt.

Falsche Aufteilung eines 2048-Bit-Datensatzes

Ein 2048-Bit-öffentlicher Schlüssel – der aktuelle Standard, auf den Sie umsteigen sollten, falls Sie noch bei 1024 Bit sind – überschreitet häufig die Begrenzung von 255 Zeichen für einen einzelnen DNS-TXT-String und muss daher in mehrere durch Anführungszeichen getrennte Strings aufgeteilt werden. Eine fehlerhafte Aufteilung führt zu einem fehlerhaften Datensatz, und der Schlüssel wird nicht als gültig erkannt, obwohl er scheinbar vorhanden ist.

Drehen ohne Überwachung

Anhand der DMARC-Gesamtberichte können Sie überprüfen, ob der neue Schlüssel validiert wird. Ohne diese Berichte wird eine fehlgeschlagene Rotation nicht als Warnmeldung, sondern als sinkende Zustellbarkeit angezeigt. Überprüfen Sie Ihre Berichte nach jeder Rotation.

Beide Fehler sind auf Datensätze zurückzuführen, die sich schneller ändern, als Sie sie manuell pflegen können. PowerDMARC sorgt dafür, dass Ihr SPF unter dem Limit von 10 Lookups und sorgt für eine reibungslose Rotation Ihrer DKIM-Schlüssel. Sobald etwas nicht mehr funktioniert, werden Sie benachrichtigt, noch bevor es Ihre Zustellbarkeit beeinträchtigt.

Starten Sie Ihre kostenlose Testphase und sehen Sie, wo Ihre Domain heute steht.

FAQs

Ersetzt DKIM SPF?

Nein. DKIM überprüft die Integrität der Nachricht anhand einer kryptografischen Signatur, bestätigt jedoch nicht, dass der Absenderserver autorisiert war. Diese Überprüfung übernimmt SPF, sodass beide Verfahren für einen umfassenden Schutz erforderlich sind. 

Warum scheitert meine E-Mail nach dem Weiterleiten an der SPF-Prüfung?

SPF gleicht die IP-Adresse des sendenden Servers mit Ihrer Liste autorisierter Adressen ab, und bei der Weiterleitung wird die ursprüngliche IP-Adresse durch die des Weiterleiters ersetzt, die nicht in Ihrer Liste enthalten ist. Dies ist gemäß RFC 7208 ein erwartetes Verhalten, und DKIM ist so konzipiert, dass es dies übersteht, da es den Inhalt und nicht den Übertragungsweg validiert. 

Was ist wichtiger: SPF oder DKIM?

Weder noch. SPF führt die Autorisierung auf Serverebene durch, DKIM die Überprüfung auf Nachrichtenebene, und beide sind für eine zuverlässige DMARC-Ausrichtung erforderlich. Wenn beide vorhanden sind, werden Ihre E-Mails auch dann weitergeleitet, wenn eine der beiden Methoden versagt. 

Wie viele DKIM-Selektoren kann ich haben?

Es gibt keine Begrenzung. Veröffentlichen Sie so viele, wie Sie benötigen – in der Regel einen pro Versanddienst oder Schlüsselrotationszyklus. Jeder Eintrag wird als separater DNS-TXT-Eintrag unter selector._domainkey.yourdomain.com gespeichert. 

Was passiert, wenn ich nur SPF, aber kein DKIM habe?

Sie verlieren die Integrität auf Nachrichtenebene und verfügen über keinen DKIM-Fallback; daher kann DMARC bei legitimen weitergeleiteten E-Mails fehlschlagen, wenn SPF nicht funktioniert. Auch die Regeln für Massenversender von Google schreiben DKIM vor, wodurch Versender mit hohem Versandvolumen die Compliance-Anforderungen nicht mehr erfüllen.