SPF, DKIM und DMARC einfach erklärt: Einträge, Fehler und Einführung

SPF, DKIM und DMARC sind drei Einträge im DNS Ihrer Domain, an denen Empfänger erkennen, ob eine E-Mail wirklich von Ihnen stammt. Fehlen sie oder sind sie falsch gesetzt, landen Nachrichten im Spam-Ordner oder werden gar nicht erst angenommen – selbst wenn Inhalt und Empfängerliste völlig in Ordnung sind. Google, Yahoo und Microsoft verlangen von Absendern größerer Mengen inzwischen SPF und DKIM sowie einen DMARC-Eintrag.

Dieser Ratgeber erklärt die drei Verfahren ohne Fachchinesisch: was jedes einzelne prüft, wie die Einträge aussehen, welche Fehler in der Praxis immer wieder vorkommen und wie Sie DMARC schrittweise einführen, ohne eigene E-Mails zu verlieren. Die Beispiele verwenden die Platzhalter-Domain example.de; setzen Sie dort Ihre eigene Domain ein.

Zum Verständnis hilft eine Vorbemerkung: Eine E-Mail hat zwei Absender. Der eine steht im Umschlag der Nachricht (Envelope-From, später als Return-Path sichtbar) und bestimmt, wohin Rückläufer gehen. Der andere steht im Kopf der Nachricht (Header-From) und ist das, was Ihre Empfänger im Postfach sehen. SPF prüft den ersten, DKIM die Signatur einer Domain – und DMARC sorgt dafür, dass beides zum sichtbaren Absender passt.

SPF: die Liste der erlaubten Server

Das Sender Policy Framework (SPF, RFC 7208) beantwortet eine einfache Frage: Welche Server dürfen E-Mails für diese Domain einliefern? Der Empfänger vergleicht die IP-Adresse des einliefernden Servers mit einer Liste, die Sie als TXT-Eintrag direkt an der Domain veröffentlichen. Der Eintrag beginnt immer mit v=spf1, zählt dann die erlaubten Absender auf und endet mit einer Anweisung für alle übrigen Server.

Ein typisches Beispiel für eine Firma, die über den eigenen Mailserver, eine feste Adresse und einen externen Dienst versendet: example.de. TXT "v=spf1 mx ip4:192.0.2.25 include:spf.example.net ~all"

Gelesen wird von links nach rechts. mx erlaubt die Server aus dem MX-Eintrag der Domain, ip4 eine einzelne Adresse oder ein Netz, include übernimmt die Liste eines Dienstleisters. Der Abschluss ~all (Softfail) sagt: Alle anderen Server sind vermutlich nicht berechtigt. Mit -all (Fail) sagen Sie: Alle anderen sind sicher nicht berechtigt. ?all enthält keine Aussage, und +all erlaubt jedem Server der Welt, in Ihrem Namen zu senden – das ist schlechter als gar kein Eintrag.

Zwei Grenzen sollten Sie kennen. Erstens darf es pro Domain nur einen einzigen SPF-Eintrag geben; wer einen neuen Dienst ergänzt, erweitert den bestehenden Eintrag, statt einen zweiten anzulegen. Zweitens erlaubt RFC 7208 bei der Auswertung höchstens zehn DNS-Abfragen. Jedes include, a, mx, exists und redirect zählt mit, und zwar einschließlich der Abfragen, die in den eingebundenen Listen der Dienstleister stecken. ip4 und ip6 zählen nicht. Wird die Grenze überschritten, bricht der Empfänger mit einem dauerhaften Fehler ab – die Wirkung ist dieselbe wie ohne SPF.

Wichtig ist außerdem, was SPF nicht leistet: Es prüft nur den Umschlag-Absender, nicht die Adresse, die Ihre Empfänger sehen. Für sich allein verhindert SPF also nicht, dass jemand Ihre Domain im sichtbaren Absender verwendet. Dafür braucht es DMARC.

DKIM: die digitale Signatur jeder Nachricht

Bei DomainKeys Identified Mail (DKIM, RFC 6376) versieht der sendende Server jede Nachricht mit einer kryptografischen Signatur in der Kopfzeile DKIM-Signature. Darin stehen unter anderem die signierende Domain (d=example.de) und ein Selektor (s=mail2026). Der Empfänger setzt beides zu einem DNS-Namen zusammen, holt dort den öffentlichen Schlüssel und prüft, ob Signatur und Inhalt zusammenpassen. Wurde die Nachricht unterwegs verändert, schlägt die Prüfung fehl.

Der zugehörige Eintrag sieht so aus: mail2026._domainkey.example.de. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." Der Wert hinter p= ist der öffentliche Schlüssel, hier gekürzt; der passende private Schlüssel bleibt auf dem Mailserver oder beim Dienstleister. Viele Anbieter geben statt eines TXT-Eintrags einen CNAME vor, der auf ihren eigenen Schlüssel zeigt. So können sie Schlüssel austauschen, ohne dass Sie Ihr DNS anfassen müssen. Üblich sind heute RSA-Schlüssel mit 2048 Bit; 1024 Bit gelten als Untergrenze.

Der Selektor ist der Grund, warum DKIM schwerer zu prüfen ist als SPF und DMARC: Er lässt sich nicht aus dem DNS ablesen. Jeder Dienst, der für Sie versendet, nutzt einen eigenen Selektor, und mehrere Selektoren können gleichzeitig bestehen – etwa einer für das Firmenpostfach und einer für den Newsletter. Welcher gerade verwendet wird, sehen Sie in der Kopfzeile DKIM-Signature einer tatsächlich versendeten Nachricht hinter s=.

Ein Vorteil von DKIM gegenüber SPF: Die Signatur hängt an der Nachricht, nicht am Server. Sie übersteht deshalb auch Wege, auf denen SPF scheitert, zum Beispiel eine automatische Weiterleitung – solange niemand den Inhalt verändert.

DMARC: Richtlinie, Ausrichtung und Berichte

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) ist ein TXT-Eintrag unter dem Namen _dmarc Ihrer Domain. Er legt fest, wie Empfänger mit Nachrichten umgehen sollen, die im sichtbaren Absender Ihre Domain tragen, aber die Prüfung nicht bestehen, und wohin sie Berichte darüber schicken: _dmarc.example.de. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.de"

Eine Nachricht besteht DMARC, wenn SPF oder DKIM erfolgreich ist und die dabei geprüfte Domain zur Domain im sichtbaren Absender passt. Diese Übereinstimmung heißt Ausrichtung, englisch Alignment. Bei SPF wird die Domain des Umschlag-Absenders verglichen, bei DKIM die Domain aus d=. Standardmäßig genügt eine lockere Ausrichtung: news.example.de passt zu example.de, weil beide zur selben Organisationsdomain gehören. Mit aspf=s und adkim=s lässt sich eine strenge Ausrichtung verlangen, bei der die Namen exakt übereinstimmen müssen.

Genau an der Ausrichtung scheitern viele Einrichtungen. Ein Versanddienst verschickt etwa mit einem Umschlag-Absender unter seiner eigenen Domain und signiert auch mit dieser. SPF und DKIM bestehen dann zwar – aber für die falsche Domain. DMARC schlägt trotzdem fehl, weil keines der beiden Ergebnisse zu example.de passt.

Die wichtigsten Angaben im DMARC-Eintrag:

• p= die Richtlinie: none (nur beobachten), quarantine (als verdächtig behandeln, meist Spam-Ordner) oder reject (abweisen)
• rua= die Adresse für Sammelberichte, die Empfänger in der Regel täglich als XML-Datei schicken
• sp= eine abweichende Richtlinie für Subdomains
• pct= der Anteil der Nachrichten in Prozent, auf den die Richtlinie angewendet wird
• aspf= und adkim= lockere (r, Standard) oder strenge (s) Ausrichtung

Typische Fehler – und was dagegen hilft

Die meisten Probleme mit SPF, DKIM und DMARC sind keine Frage der Technik, sondern der Pflege: Ein Dienst kommt hinzu, ein anderer fällt weg, und der Eintrag im DNS wird nicht angepasst. Diese Fehler kommen in der Praxis am häufigsten vor:

• Mehrere SPF-Einträge: Zwei TXT-Einträge mit v=spf1 an derselben Domain führen zu einem dauerhaften Fehler, die Prüfung fällt aus. Die Einträge müssen zu einem einzigen zusammengeführt werden.
• Mehr als zehn DNS-Abfragen: Jeder Dienst bringt sein include mit, und dessen Liste enthält oft weitere. Abhilfe schafft, nicht mehr genutzte Dienste zu entfernen, Server mit festen Adressen über ip4 oder ip6 einzutragen oder den Massenversand auf eine Subdomain mit eigenem SPF-Eintrag zu legen.
• ~all oder -all ohne Plan: -all wirkt strenger, kann aber dazu führen, dass Empfänger weitergeleitete Nachrichten schon wegen des SPF-Fehlers abweisen, bevor DKIM und DMARC ausgewertet werden. Wer DMARC einsetzt, fährt mit ~all meist gut, weil die Entscheidung dann bei DMARC liegt. Entscheidend ist, dass überhaupt ein wirksamer Abschluss vorhanden ist.
• Fehlender DKIM-Selektor: Der Dienst signiert mit einem Selektor, unter dem im DNS kein Schlüssel liegt – oft nach einem Anbieterwechsel oder weil die Einrichtung beim Dienstleister nie abgeschlossen wurde. Die Signatur gilt dann als ungültig.
• DMARC ohne rua: Ohne Berichtsadresse erfahren Sie nie, welche Server in Ihrem Namen senden und wo die Prüfung scheitert. Liegt die Adresse unter einer fremden Domain, muss diese der Zustellung der Berichte per eigenem DNS-Eintrag zustimmen; fehlt diese Zustimmung, verwerfen Empfänger die Berichte.
• Fehlende Ausrichtung: SPF und DKIM bestehen, aber für die Domain des Dienstleisters statt für Ihre. Abhilfe: beim Dienstleister eine DKIM-Signatur mit Ihrer eigenen Domain einrichten und, wenn angeboten, einen eigenen Umschlag-Absender unter einer Subdomain.

DMARC schrittweise einführen: von none bis reject

Wer DMARC sofort mit p=reject veröffentlicht, riskiert, eigene Nachrichten abzuweisen: die Rechnungen aus der Buchhaltungssoftware, die Bestellbestätigungen des Onlineshops, den Newsletter. Bewährt hat sich ein Vorgehen in drei Schritten, bei dem die Berichte aus der rua-Adresse den Takt vorgeben.

Zuerst p=none. Mit Ihren Nachrichten passiert nichts, aber Sie bekommen Berichte und sehen, welche Server in Ihrem Namen senden – auch solche, an die niemand mehr gedacht hat. Lassen Sie diese Phase einige Wochen laufen, damit auch Absender auftauchen, die nur selten verschicken, etwa ein monatlicher Rechnungslauf. Richten Sie jeden legitimen Absender so ein, dass er SPF oder DKIM mit Ausrichtung besteht.

Dann p=quarantine. Nicht bestandene Nachrichten werden als verdächtig behandelt und landen meist im Spam-Ordner. Wer vorsichtig vorgehen will, wendet die Richtlinie mit pct= zunächst nur auf einen Teil der Nachrichten an und erhöht den Anteil schrittweise.

Zuletzt p=reject. Erst jetzt weisen Empfänger Nachrichten ab, die Ihre Domain im sichtbaren Absender missbrauchen. Behalten Sie die Berichte auch danach im Blick: Jeder neue Dienst, der in Ihrem Namen verschicken soll, muss vorher eingerichtet werden. Denken Sie außerdem an Domains, die gar keine E-Mails versenden, etwa reine Marken- oder Weiterleitungsdomains. Für sie genügen der SPF-Eintrag "v=spf1 -all" und ein DMARC-Eintrag mit p=reject, damit auch diese Namen nicht missbraucht werden können.

• Schritt 1: v=DMARC1; p=none; rua=mailto:dmarc@example.de
• Schritt 2: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.de
• Schritt 3: v=DMARC1; p=reject; rua=mailto:dmarc@example.de

Weiterleitungen, Verteiler und Newsletter-Dienste

Weiterleitungen sind der klassische Stolperstein für SPF. Leitet ein Postfach eine Nachricht automatisch weiter, stellt der weiterleitende Server sie mit seiner eigenen IP-Adresse zu, die in Ihrem SPF-Eintrag nicht steht. SPF schlägt fehl. DKIM übersteht die Weiterleitung dagegen, solange die Nachricht unverändert bleibt. Deshalb ist eine ausgerichtete DKIM-Signatur für DMARC die verlässlichere Säule. Weiterleitende Server können zusätzlich den Umschlag-Absender umschreiben (SRS) oder das ursprüngliche Prüfergebnis per ARC weitergeben; darauf haben Sie als Absender allerdings keinen Einfluss.

Mailinglisten und Verteiler verändern Nachrichten häufig: Sie ergänzen den Betreff um ein Kürzel oder hängen eine Fußzeile an. Damit bricht auch die DKIM-Signatur. Gut eingerichtete Listen setzen deshalb ihre eigene Adresse in den sichtbaren Absender, damit die Nachricht nicht an Ihrer DMARC-Richtlinie scheitert.

Bei Newsletter- und Versanddiensten kommt es auf die Ausrichtung an. Prüfen Sie in der Einrichtung des Dienstes, ob er mit Ihrer eigenen Domain signieren kann – meist über zwei oder drei CNAME-Einträge – und ob sich ein eigener Umschlag-Absender unter Ihrer Domain einrichten lässt. Viele Absender legen den Massenversand auf eine Subdomain wie news.example.de: Sie bekommt einen eigenen SPF-Eintrag und eigene DKIM-Schlüssel, und ein Problem beim Newsletter färbt nicht auf die normale Geschäftskorrespondenz ab. Was sonst noch vor dem ersten Versand stimmen sollte, steht in der Checkliste für den Newsletter-Versand.

So prüfen Sie Ihre Einträge

Ob die Einträge stimmen, lässt sich ohne Kommandozeile prüfen. Geben Sie im Domain-Check von Mailigator Ihre Domain ein: Der Werkzeugkasten zeigt Mailserver, SPF, DMARC, Verschlüsselung und Blocklisten zusammen und erklärt zu jedem Befund, was er bedeutet und was zu tun ist. Beim SPF-Eintrag zählt er die DNS-Abfragen mit und weist darauf hin, wenn die Grenze von zehn nahe ist oder überschritten wird; beim DMARC-Eintrag meldet er unter anderem eine fehlende rua-Adresse.

Für DKIM braucht jede Prüfung den Selektor, denn ohne ihn weiß niemand, wo der Schlüssel liegt. Mit der Schreibweise dkim: selektor@example.de prüft der Werkzeugkasten gezielt diesen einen Eintrag. Ebenso lassen sich mit den Vorsilben spf: und dmarc: einzelne Einträge abfragen.

Der Domain-Check sieht nur, was im DNS steht. Ob eine echte Nachricht SPF, DKIM und DMARC tatsächlich besteht – mit der IP-Adresse, von der sie wirklich verschickt wird, und mit der Signatur, die der Dienst wirklich setzt –, zeigt erst der Versand. Dafür schicken Sie eine ganz normale Nachricht an die Adresse auf der Seite Spam-Test und sehen, wie ein empfangender Mailserver sie bewertet. Testen Sie so jeden Weg, über den Ihre Domain verschickt: das Firmenpostfach, den Newsletter-Dienst, das Shop- oder Warenwirtschaftssystem.

Prüfen Sie nach jeder Änderung erneut. Neue oder geänderte DNS-Einträge sind je nach eingestellter Gültigkeitsdauer (TTL) erst nach einigen Minuten bis Stunden überall sichtbar.