Was SPF, DKIM und DMARC tatsächlich tun
Stellen Sie sich die drei als eine Kette mit drei Gliedern vor. SPF autorisiert die Server, die für Ihre Domain senden dürfen. DKIM hängt eine kryptografische Signatur an, damit ein Empfänger erkennen kann, dass die Nachricht unterwegs nicht verändert wurde. DMARC bindet beides an die Domain, die Empfänger tatsächlich in der From:-Zeile sehen, und veröffentlicht eine Richtlinie dafür, was bei einer fehlgeschlagenen Prüfung passieren soll. Einfach gesagt: SPF prüft den Umschlag, DKIM den Inhalt, und DMARC prüft, ob eines von beiden zum Namen passt, den Ihr Empfänger liest.
SPF: welche Server für Ihre Domain senden dürfen
Ein SPF-Eintrag ist ein einzelner DNS-TXT-Eintrag, der mit v=spf1 beginnt, die Hosts und Includes auflistet, die für die Domain senden dürfen, und mit einem all-Mechanismus endet. Zwei Regeln bringen viele ins Straucheln. Erstens darf eine Domain nur einen v=spf1-Eintrag veröffentlichen; ein zweiter führt bei der Auswertung zu permerror, und die Authentifizierung schlägt faktisch fehl (RFC 7208, Abschnitt 4.5). Zweitens darf SPF bei der Auswertung höchstens zehn Mechanismen mit DNS-Abfrage ausführen – include, a, mx, ptr, exists und den Modifikator redirect; bei mehr als zehn ist das Ergebnis wieder permerror (Abschnitt 4.6.4). Der abschließende Qualifier ist die Richtlinie: ~all ist ein Softfail (annehmen, aber markieren), -all ein Hardfail (nicht gelistete Absender ablehnen), und +all würde alles durchlassen, weshalb Sie es nie veröffentlichen. Eine strukturelle Grenze sollten Sie kennen: SPF authentifiziert die verborgene Return-Path-Domain, nicht die sichtbare From:-Adresse, und es versagt bei Weiterleitungen, weil die IP des weiterleitenden Servers nicht in Ihrem Eintrag steht – genau deshalb verlässt sich DMARC nicht allein auf SPF.
DKIM: eine Signatur, die niemand still verändern kann
DKIM signiert jede ausgehende Nachricht mit einem privaten Schlüssel, den Ihr Versandsystem hält, und veröffentlicht den passenden öffentlichen Schlüssel im DNS. Die Signatur umfasst ausgewählte Header und den Body; wird unterwegs etwas verändert, ist die Signatur nicht mehr gültig. Empfänger finden den Schlüssel über einen Selector: Ein DKIM-Signature-Header enthält s= (den Selector) und d= (Ihre Domain), und der Prüfer fragt selector._domainkey.yourdomain nach dem öffentlichen Schlüssel ab (RFC 6376, Abschnitt 3.6.2.1). Mit Selectors können Sie auch mehrere Schlüssel gleichzeitig betreiben, und genau das macht die Rotation sauber – einen neuen Selector veröffentlichen, die Signierung darauf umstellen, dann den alten stilllegen (ein leerer Schlüsselwert markiert ihn als widerrufen). Zur Schlüssellänge: RFC 6376 verlangt für den langfristigen Einsatz RSA-Schlüssel mit mindestens 1024 Bit, und Prüfer müssen Schlüssel bis 2048 Bit verarbeiten können; 2048 Bit ist der vernünftige moderne Standard, und regelmäßige Rotation begrenzt den Schaden, falls ein Schlüssel je durchsickert.
DMARC: die Richtlinie, die alles zusammenführt
DMARC ist der Eintrag, der SPF und DKIM für die Domain, die Ihr Empfänger liest, überhaupt erst Bedeutung gibt. Seine zentrale Idee ist das Alignment. Eine Nachricht besteht DMARC nur, wenn SPF oder DKIM besteht und dieses Ergebnis auf einer Kennung beruht, die an der sichtbaren From:-Domain ausgerichtet ist (RFC 7489, Abschnitt 4.2). Deshalb kann eine Nachricht SPF an sich bestehen und trotzdem an DMARC scheitern: Wenn Ihr ESP mit seiner eigenen Return-Path-Domain sendet, besteht SPF für den ESP, aber diese Domain ist nicht an Ihrer From:-Adresse ausgerichtet, also schlägt die SPF-Seite von DMARC fehl. Alignment gibt es in zwei Modi – relaxed, das eine passende Organisationsdomain akzeptiert (mail.yourco.com passt zu yourco.com), und strict, das eine exakte Übereinstimmung verlangt. Weil einer der beiden Mechanismen genügt, sofern er ausgerichtet ist, trägt das DKIM-Alignment meist die E-Mails, die SPF nicht tragen kann, etwa weitergeleitete Nachrichten. Der Eintrag selbst lautet v=DMARC1; p=none; rua=mailto:reports@yourco.com; das Tag p legt die Richtlinie fest (none, quarantine oder reject), rua nennt, wohin Sammelberichte gehen, und sp setzt eine eigene Richtlinie für Subdomains – fehlt sp, gilt standardmäßig Ihr p-Wert.
Warum das 2024 Pflicht wurde
Authentifizierung war früher freiwillige Hygiene. Im Februar 2024 wurde sie zur Schranke. Gmail und Yahoo verlangen heute von Massenversendern – Google zählt dazu jeden, der mehr als 5.000 Nachrichten pro Tag an Gmail schickt –, sich mit SPF und DKIM zu authentifizieren und einen DMARC-Eintrag zu veröffentlichen, der mit p=none beginnen darf. Marketing- und Abonnement-E-Mails müssen außerdem eine Abmeldung mit einem Klick bieten: den List-Unsubscribe-Header (RFC 2369) plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, den One-Click-Mechanismus aus RFC 8058, damit der Client eines Empfängers die Abmeldung mit einem einzigen HTTPS-POST auslösen kann. Die vollständigen Regeln von Gmail und Yahoo finden Sie im Überblick zur Zustellbarkeit. Zwei Punkte sind wichtig: Seit 2024 wird strenger durchgesetzt, richten Sie sich also auch unter 5.000 pro Tag nach der Regel, und niedrige Spambeschwerden sind neben der Authentifizierung eine Anforderung, keine Kür.
Häufige Fehler, die die Authentifizierung still aushebeln
- +all im SPF-Eintrag veröffentlichen, was dem gesamten Internet erlaubt, in Ihrem Namen zu senden – das Gegenteil des Zwecks.
- Mehr als einen v=spf1-Eintrag auf derselben Domain betreiben, was permerror liefert und SPF unwirksam macht.
- Beim Hinzufügen von Includes für Anbieter über das Limit von zehn DNS-Abfragen hinausschießen, was ebenfalls permerror liefert.
- Ein DKIM-Schlüssel, der zu kurz ist oder nie rotiert wird, sodass ein durchgesickerter oder per Brute Force geknackter Schlüssel unbegrenzt weiter signiert.
- Direkt auf p=reject springen, bevor Sie auch nur einen Sammelbericht gelesen haben, was legitime E-Mails blockiert, von denen Sie vergessen hatten, dass Sie sie senden.
- sp= für Subdomains vergessen, sodass eine laxe Subdomain-Richtlinie marketing.yourco.com für Spoofing offen lässt.
- Ein Drittanbieter – ein ESP, ein Rechnungstool, ein Helpdesk –, den Sie nie in SPF- und DKIM-Alignment gebracht haben, sodass dessen E-Mails an DMARC scheitern.
Wo Authentifizierung in Ihren Stack passt
Authentifizierung ist das Fundament, auf dem alles andere steht. Wenn Sie selbst hosten, gehören Ihnen DNS und Signaturschlüssel vollständig – die stärkste Form, Ihre eigene Absenderidentität zu kontrollieren. Eine Customer-Engagement-Plattform sollte den Status von Authentifizierung und Alignment für jede Versanddomain anzeigen, statt ihn zu verstecken, damit Sie auf einen Blick sehen, welche Quellen bestehen. Leiten Sie Transaktions- und Marketing-E-Mails über getrennte Streams und idealerweise getrennte Subdomains, damit eine Welle von Marketing-Beschwerden nie die Zustellung von Passwort-Resets gefährdet. Und gehen Sie in der richtigen Reihenfolge vor: Authentifizierung und Alignment kommen zuerst, vor dem Aufwärmen der Domain – wer eine nicht authentifizierte Domain aufwärmt, bringt den Anbietern nur schneller bei, Ihnen zu misstrauen.