Warum Ihr SPF-Eintrag immer wieder scheitert – und wie Sie es beheben

Was SPF tatsächlich prüft

SPF – Sender Policy Framework – ist ein TXT-Eintrag auf Ihrer Domain, der auflistet, welche Server in Ihrem Namen Mail senden dürfen. Ein empfangender Server liest diesen Eintrag, vergleicht ihn mit der IP-Adresse, die sich gerade verbunden hat, und entscheidet, ob die Verbindung autorisiert ist.

Zwei Details dazu, was verglichen wird, erklären die meiste Verwirrung um SPF:

• SPF prüft den Envelope-Absender, nicht die From:-Adresse, die Ihr Empfänger sieht. Der Envelope-Absender (das MAIL FROM im SMTP-Dialog, auch Return-Path genannt) ist im Mailprogramm unsichtbar. Eine Nachricht kann SPF passieren und dabei eine völlig andere, gefälschte From:-Adresse anzeigen – deshalb verhindert SPF allein kein Spoofing.
• SPF prüft die verbindende IP-Adresse und nichts anderes. Es sieht sich weder die Nachricht noch die Header noch den Inhalt an. Es ist eine einzige Frage: durfte diese IP sich in Ihrem Namen verbinden?

Ein SPF-Fehler bedeutet daher fast nie, dass Ihr Eintrag fehlerhaft formuliert ist. Meist bedeutet er, dass Mail von irgendwo losging, das der Eintrag nicht nennt, oder dass der Eintrag nicht vollständig ausgewertet werden konnte. Das sind unterschiedliche Probleme mit unterschiedlichen Lösungen, und der Rest dieses Leitfadens trennt sie.

Wie Sie Ihren eigenen SPF-Eintrag lesen

Ein SPF-Eintrag ist eine einzige Zeile TXT, und sie ist lesbar, sobald man die vier Teile kennt.

Mechanismen: wer darf

Jeder Ausdruck fügt erlaubte Absender hinzu. ip4: und ip6: nennen Adressen oder Bereiche direkt. a autorisiert, worauf der A-Record Ihrer Domain zeigt. mx autorisiert Ihre eigenen Mailserver. include: ist der praktisch wichtigste: er zieht den gesamten SPF-Eintrag einer anderen Domain herein, und so autorisieren Sie Google, Microsoft oder einen Massenversender, ohne dessen Adressen zu kennen.

include: ist eine Delegation, keine Kopie. Die andere Seite kann ihre Liste jederzeit ändern, und Ihr Eintrag folgt – das ist der Sinn, und auch der Grund, warum Ihr Eintrag brechen kann, ohne dass Sie ihn angefasst haben.

Qualifier: was bei einem Treffer passiert

Jeder Mechanismus kann ein Präfix tragen. + heißt Pass und ist die Vorgabe, ein nacktes mx bedeutet also +mx. - ist ein Hard Fail: abweisen. ~ ist ein Soft Fail: annehmen, aber markieren. ? ist neutral: keine Meinung, was praktisch gar keiner Richtlinie entspricht.

Das all am Ende

Der letzte Ausdruck ist fast immer ein all-Mechanismus, und er entscheidet, was mit allen Absendern passiert, die der Eintrag nicht genannt hat. -all heißt: alles andere abweisen. ~all heißt: annehmen, aber markieren. +all autorisiert das gesamte Internet und ist immer ein Fehler.

Beginnen Sie mit ~all, solange Sie noch herausfinden, wer legitim für Sie sendet, und ziehen Sie dann auf -all an, wenn Ihre DMARC-Berichte sauber sind. Direkt auf -all zu gehen, ohne diesen Nachweis, ist der Weg, auf dem ein vergessenes Rechnungssystem oder ein Helpdesk niemanden mehr erreicht.

Genau ein Eintrag, ohne Ausnahme

Eine Domain darf einen SPF-Eintrag veröffentlichen. Zwei TXT-Einträge, die beide mit v=spf1 beginnen, sind ein permerror, und ein Permerror bedeutet, dass die Prüfung überhaupt nicht ausgewertet werden kann – bei einem strengen Empfänger ist das schlimmer als ein einfacher Fehlschlag. Das passiert ständig: der Einrichtungsassistent eines neuen Anbieters legt seinen eigenen Eintrag an, statt Ihren zu bearbeiten. Zusammenführen heißt ein Eintrag mit beiden Mechanismus-Sätzen, nicht zwei Einträge.

Das Limit von zehn Abfragen, der stille Killer

Das ist die häufigste Ursache für einen SPF-Eintrag, der perfekt aussieht und doch scheitert.

Die Spezifikation begrenzt die SPF-Auswertung auf zehn DNS-Abfragen. Jedes include:, a, mx, ptr und exists: kostet eine – und die Abfragen innerhalb jedes eingebundenen Eintrags zählen mit. Ein include:, das selbst drei Includes enthält, kostet vier Ihrer zehn. Wird das Limit überschritten, lautet das Ergebnis permerror: kein Fehlschlag, sondern ein nicht auswertbarer Eintrag, den viele Empfänger wie unauthentifiziert behandeln.

Fies daran ist, dass es unsichtbar ist und von selbst wächst. Ihr Eintrag passte, als Sie ihn geschrieben haben. Monate später hat einer Ihrer Anbieter seinem eigenen Eintrag ein include: hinzugefügt, Ihre Summe überschritt zehn, und Ihre Mail wurde markiert, ohne dass sich bei Ihnen etwas geändert hätte. ip4: und ip6: kosten keine Abfrage – das ist Ihr wichtigster Hebel.

Zählen Sie Ihre, bevor Sie den Eintrag für in Ordnung halten. Fragen Sie den TXT-Eintrag Ihrer Domain ab, dann den Eintrag jeder eingebundenen Domain, und machen Sie weiter, bis nichts mehr zu expandieren ist. Ein DNS-Abfrage-Tool macht das schnell: TXT-Eintrag nachsehen, dann jedem include: einzeln folgen.

Warum Mail scheitert, obwohl der Eintrag richtig aussieht

Wenn der Eintrag syntaktisch gültig ist und unter dem Abfragelimit liegt, arbeiten Sie das der Reihe nach durch.

• Etwas sendet über einen nicht genannten Dienst. Die üblichen Verdächtigen sind ein CRM, ein Rechnungs- oder Ticketsystem, eine Marketingplattform, ein Monitoring-Werkzeug oder ein Anwendungsserver, der über seinen lokalen Mail-Agenten sendet. Jedes braucht ein include: oder seinen IP-Bereich.
• Der Envelope-Absender ist eine andere Domain. Eine Plattform, die „im Auftrag von“ Ihnen sendet, nutzt oft ihren eigenen Return-Path, SPF wird also gegen ihre Domain geprüft und besteht, während Ihre DMARC-Ausrichtung weiterhin scheitert. Die Nachricht kann gleichzeitig authentifiziert und nicht ausgerichtet sein.
• Eine Subdomain ohne eigenen Eintrag. SPF wird nicht geerbt. Mail von mail.example.com wird gegen genau diesen Namen geprüft, und ohne TXT-Eintrag lautet das Ergebnis none, nicht Ihre Apex-Richtlinie. Veröffentlichen Sie einen Eintrag pro sendender Subdomain und ein leeres v=spf1 -all auf Subdomains, die nie senden sollen.
• Der Eintrag wurde geändert und die Caches sind noch nicht nachgezogen. Ihr TXT-Eintrag trägt eine TTL wie jeder andere, eine Korrektur ist also nicht im Moment des Speicherns überall aktiv – wie TTL und Propagation funktionieren erklärt die Zeiten.
• Ein veraltetes include:. Ein Anbieter, den Sie nicht mehr nutzen und dessen Domain nicht mehr auflöst, kann einen Permerror erzeugen, und niemand hat ein Interesse daran, es Ihnen zu sagen.

Weiterleitung bricht SPF, von Entwurf an

Das ist nicht Ihre Schuld und lässt sich in Ihrem Eintrag nicht beheben – also lohnt es sich, das zu verstehen, bevor Sie einen Tag darauf verwenden.

Wenn ein Empfänger Ihre Nachricht weiterleitet – ein Uni-Alias, eine .forward-Regel, eine Mailingliste –, verbindet sich der weiterleitende Server mit dem Endziel über seine eigene IP-Adresse und behält Ihre Domain als Envelope-Absender. Der Empfänger prüft Ihren SPF-Eintrag gegen eine IP, von der Sie nie gehört haben, und es scheitert. Zu Recht: diese IP ist tatsächlich nicht von Ihnen autorisiert.

Es gibt zwei Abmilderungen, und keine ist eine SPF-Änderung. DKIM signiert die Nachricht kryptografisch und überlebt die Weiterleitung, eine weitergeleitete Nachricht, die SPF nicht besteht, kann also DKIM und damit DMARC bestehen – der Hauptgrund, beides zu betreiben. SRS (Sender Rewriting Scheme) ist Aufgabe des Weiterleitenden: er schreibt den Envelope-Absender auf seine eigene Domain um, damit SPF gegen ihn geprüft wird. Einen fremden Weiterleiter dazu zu bringen, liegt nicht in Ihrer Hand.

Praktische Folgerung: diagnostizieren Sie SPF nie an einer weitergeleiteten Kopie, und gehen Sie nicht auf -all in der Annahme, jeder sichtbare Fehlschlag sei ein Angreifer.

Ein SPF-Pass ist kein DMARC-Pass

Ein pass in den Headern, während DMARC trotzdem scheitert, verwirrt fast jeden, und der Grund heißt Ausrichtung.

SPF authentifiziert den Envelope-Absender. DMARC verlangt zusätzlich, dass die authentifizierte Domain zur sichtbaren From:-Domain passt. Eine Plattform, die mit ihrem eigenen Return-Path sendet, kann Ihnen einen einwandfreien SPF-Pass auf ihrer Domain liefern, was für Ihre From:-Domain nichts tut: die SPF-Prüfung bestand, die Ausrichtungsprüfung nicht, und DMARC scheitert auf dieser Grundlage.

SPF war also nie ein Schutz gegen Spoofing: ein Angreifer kann für seine eigene Domain vollkommen gültiges SPF veröffentlichen und trotzdem Ihren Namen ins From:-Feld setzen. DMARC ist das, was Authentifizierung an die Adresse bindet, die der Empfänger wirklich sieht, und es liefert auch die Berichte, die Ihnen zeigen, wer als Sie sendet. Der Leitfaden zu SPF, DKIM und DMARC erklärt, wie die drei zusammenspielen und wie eine Richtlinie einzuführen ist.

Wie Sie einen scheiternden Eintrag reparieren

In dieser Reihenfolge, weil jeder Schritt Ursachen ausschließt, die die späteren sonst verdecken.

• Bestätigen Sie, dass es genau einen Eintrag gibt. Fragen Sie Ihre TXT-Einträge ab und zählen Sie, wie viele mit v=spf1 beginnen. Mehr als einer ist ein Permerror – führen Sie die Mechanismen zu einem Eintrag zusammen, bevor Sie irgendetwas anderes untersuchen.
• Zählen Sie die Abfragen, auch die verschachtelten. Wenn Sie bei zehn oder in der Nähe sind, ersetzen Sie das schwerste include: durch die ip4:- Bereiche, auf die es auflöst, und entfernen Sie Includes für Anbieter, die Sie nicht mehr nutzen. Ein einziges verwaistes Include zu streichen bringt die Summe oft wieder unter das Limit.
• Erfassen Sie, wer tatsächlich für Sie sendet. DMARC-Sammelberichte sind hier die einzige verlässliche Quelle: sie listen jede IP, die als Ihre Domain sendet, auch die Systeme, an die sich niemand erinnert. Raten erzeugt einen unvollständigen Eintrag.
• Lassen Sie ptr ganz weg. Es ist veraltet, langsam, unzuverlässig, und manche Empfänger ignorieren Einträge, die es verwenden.
• Bleiben Sie bei ~all, bis die Berichte sauber sind, und gehen Sie dann auf -all. Ein Hard Fail auf einem unvollständigen Eintrag lässt Ihre eigene Mail abprallen.
• Senken Sie die TTL vor der Änderung und prüfen Sie von außen. Sehen Sie den live ausgelieferten TXT-Eintrag mit einem DNS-Abfrage-Tool an, statt Ihrem DNS-Panel zu vertrauen, und prüfen Sie erneut, nachdem die alte TTL abgelaufen ist.

Häufige Fehler

• Zwei SPF-Einträge, weil der Assistent eines Anbieters seinen eigenen angelegt hat. Permerror, und schlimmer als ein Fehlschlag.
• Zehn Abfragen überschreiten und es nie erfahren, weil der Fehler ein Permerror in den Logs anderer Leute ist.
• Auf -all springen, bevor Sie jeden legitimen Absender kennen. Das vergessene System ist meist das, das Ihre Kunden abrechnet.
• Erwarten, dass Subdomains erben. Tun sie nicht. Veröffentlichen Sie einen Eintrag pro sendender Subdomain.
• ptr verwenden – oder +all, das alle autorisiert.
• An einer weitergeleiteten Nachricht diagnostizieren. Weiterleitung scheitert bei SPF zu Recht und sagt nichts über Ihren Eintrag.
• Annehmen, ein SPF-Pass heiße DMARC-Pass. Ohne Ausrichtung auf die sichtbare From:-Domain heißt er das nicht.
• Den Eintrag ändern und sofort testen. Der alte TXT-Eintrag liegt noch für die Dauer seiner TTL im Cache.

Kurzfassung

SPF vergleicht die verbindende IP mit einem TXT-Eintrag und prüft den unsichtbaren Envelope-Absender, nicht die From:-Adresse, die Ihr Empfänger liest. Veröffentlichen Sie genau einen Eintrag, halten Sie die Summe der DNS-Abfragen – samt der in jedem include: verschachtelten – bei zehn oder darunter, nennen Sie jeden Dienst, der legitim für Sie sendet, geben Sie jeder sendenden Subdomain einen eigenen Eintrag, und bleiben Sie bei ~all, bis Ihre DMARC-Berichte belegen, dass die Liste vollständig ist. Weitergeleitete Mail wird SPF nicht bestehen, was Sie auch tun – deshalb gibt es DKIM und DMARC daneben. Lesen Sie den live ausgelieferten TXT-Eintrag jeder Domain, expandieren Sie jedes include: und sehen Sie die verbleibende TTL mit dem kostenlosen DNS-Lookup-Tool.

Verwandte Tools und Leitfäden:

• DNS-Abfrage – Fragen Sie A-, AAAA-, MX-, TXT-, NS- und weitere DNS-Einträge mit Werten und TTL sowie Reverse-DNS ab.
• Einen DMARC-Bericht lesen, ohne im XML zu ertrinken – Was in einem DMARC-Sammelbericht steht

Häufige Fragen