SPF vs. DKIM vs. DMARC: Was ist der Unterschied?

Was macht SPF?

SPF beantwortet eine Frage: Darf der Server, der diese Nachricht zugestellt hat, für die Domain senden? Der Domaininhaber veröffentlicht einen TXT-Record, der mit v=spf1 beginnt und die erlaubten Quellen auflistet, zum Beispiel include:_spf.protonmail.ch für Proton Mail. Ein Empfänger vergleicht die verbindende IP-Adresse mit der Liste und erhält ein Ergebnis: pass, fail, softfail oder neutral, je nach Qualifier am Ende (-all, ~all oder ?all).

SPF prüft den Envelope-Sender (das MAIL FROM) und den HELO-Namen, nicht die From-Adresse, die der Leser sieht. Diese Lücke ist der Grund, warum es DMARC gibt. SPF hat außerdem harte Grenzen: Eine Domain darf nur einen SPF-Record haben, und die Auswertung bricht nach 10 DNS-abfragenden Begriffen (include, a, mx, ptr, exists, redirect) mit einem permanenten Fehler ab. Die vollständige Methode steht im Leitfaden zum Erstellen eines SPF-Records.

Was macht DKIM?

DKIM beantwortet eine andere Frage: Wurde diese Nachricht von der Domain signiert, die sie angibt, und ist sie unverändert angekommen? Der sendende Server signiert ausgewählte Header und den Body mit einem privaten Schlüssel. Der Empfänger liest die signierende Domain (d=) und den Selektor (s=) aus dem Header DKIM-Signature, holt den öffentlichen Schlüssel bei selector._domainkey.domain im DNS und prüft die Signatur.

Weil die Signatur mit der Nachricht reist, übersteht DKIM eine Weiterleitung, welche die Nachricht intakt lässt, was SPF nicht tut, da ein Weiterleiter von seiner eigenen IP-Adresse sendet. RFC 6376 sagt, dass Signierer für langlebige Schlüssel RSA-Schlüssel von mindestens 1024 Bit verwenden müssen, und empfiehlt neue Selektoren, wenn sich Schlüssel ändern. Anbieter veröffentlichen die Schlüssel für Sie: drei CNAME-Records für Proton Mail und Fastmail, vier für Mailbox.org. Einzelheiten stehen im Leitfaden zum Einrichten von DKIM.

Was macht DMARC?

DMARC verbindet SPF und DKIM mit der sichtbaren From-Domain und sagt den Empfängern, was zu tun ist, wenn keine der Prüfungen übereinstimmt. Eine Nachricht besteht DMARC, wenn SPF oder DKIM besteht und die dabei authentifizierte Domain mit der From-Domain übereinstimmt. Das Alignment ist standardmäßig locker (dieselbe Organisationsdomain) und streng, wenn es mit aspf=s oder adkim=s gesetzt wird.

Der Record liegt bei _dmarc.yourdomain und enthält eine Policy: p=none (nur beobachten), p=quarantine (als verdächtig behandeln) oder p=reject (ablehnen). Eine rua-Adresse erhält aggregierte Berichte, die zeigen, wer in Ihrem Namen E-Mails sendet. RFC 9989, veröffentlicht im Mai 2026, ist die aktuelle Spezifikation; sie löst RFC 7489 ab, entfernt das Tag pct und fügt ein Test-Flag t hinzu. Den Weg von der Beobachtung zur Ablehnung beschreibt der Leitfaden zum Einrichten von DMARC.

Brauche ich alle drei?

Ja: Eine eigene Domain, die E-Mails sendet, sollte SPF, DKIM und DMARC veröffentlichen, weil große Empfänger sie verlangen. Die Absenderrichtlinien von Google verlangen SPF, DKIM und einen DMARC-Record (Policy none genügt) für Absender mit mehr als 5,000 Nachrichten am Tag an Gmail-Konten. Microsoft verlangt von Absendern an Outlook.com mit mehr als 5,000 am Tag dasselbe, ab dem 5 Mai 2025, und auch Yahoo verlangt SPF, DKIM und DMARC von Massenversendern.

Ein privates Postfach sendet weit weniger Nachrichten, die Schwellenwerte binden Sie also nicht. Die Records entscheiden dennoch, ob Ihre E-Mails im Posteingang ankommen, und sie hindern andere daran, Ihre Adresse zu fälschen. Laut der Zählung von Postelva vom 12 November 2026 aus den Hilfeseiten der Anbieter braucht eine vollständige Proton-Mail-Einrichtung 8 DNS-Records und eine vollständige Mailbox.org-Einrichtung 11, davon sind 3 und 4 DKIM-Schlüssel. Die MX-Records behandelt was ein MX-Record ist.

Welche Fehler brechen die drei Records?

Drei Fehler verursachen die meisten Ausfälle: ein zweiter SPF-Record, mehr als 10 Abfragen und eine zu früh zu streng gesetzte DMARC-Policy. Eine Domain mit zwei SPF-Records gibt einen permanenten Fehler zurück, fügen Sie das include des neuen Anbieters also dem bestehenden Record hinzu. Ein Stapel aus Mailhost, Newsletter-Tool und Helpdesk kann die Abfragezahl über 10 treiben, und der Record scheitert dann für jeden Absender. Mailbox.org und Proton raten beide, DMARC mit p=none zu beginnen, und Mailbox.org warnt, dass eine zu früh angewandte strenge Policy legitime E-Mails zurückweisen kann.

Ein vierter Fehler ist, die DKIM- und SPF-Einträge des früheren Anbieters monatelang zu behalten. Sie schaden der Zustellung nicht, erweitern aber die Liste der Server, die für Sie sprechen dürfen. Entfernen Sie sie, sobald der Umzug bestätigt ist.

Wie arbeiten die drei bei einer Nachricht zusammen?

Der Empfänger führt SPF und DKIM aus, dann kombiniert DMARC die Ergebnisse. Nehmen Sie eine Nachricht von [email protected], die über Proton Mail gesendet wird. SPF besteht, wenn der verbindende Server in der Liste von _spf.protonmail.ch steht. DKIM besteht, wenn die mit dem Schlüssel unter yourname.com erstellte Signatur verifiziert wird. DMARC fragt dann, ob mindestens eines der beiden mit yourname.com als ausgerichteter Kennung bestanden hat. Wenn ja, besteht die Nachricht; wenn nicht, wendet der Empfänger Ihre Policy an und legt das Ergebnis im nächsten aggregierten Bericht ab.

RFC 9989 hält fest, dass sich eine Domain mit p=reject nicht allein auf SPF verlassen darf und mit DKIM signieren sollte, weil SPF bei Weiterleitung bricht. ARC (RFC 8617), ein experimenteller Standard, lässt Weiterleiter die ursprünglichen Ergebnisse festhalten, gehört aber nicht zu Ihrer eigenen Einrichtung. Nach dem Veröffentlichen der Records prüfen Sie sie mit dig, bevor Sie irgendeine Policy verschärfen.

Eine zitierfähige Definition: SPF autorisiert Server, DKIM authentifiziert Nachrichten, und DMARC erzwingt die Übereinstimmung mit der From-Domain und meldet das Ergebnis.