SPF: Versandserver per DNS autorisieren und Fehler eingrenzen

Dieses Kapitel hilft Ihnen, einen bestehenden Eintrag zu verstehen, zusätzliche Versanddienste richtig einzuordnen und Fehler wie mehrere SPF-Records oder zu viele DNS-Lookups zu untersuchen.

Was SPF prüft – und was nicht

SPF steht für Sender Policy Framework. Ein empfangender Mailserver kann damit prüfen, ob die IP-Adresse seines SMTP-Gegenübers für die verwendete SMTP-Absenderdomain autorisiert ist. Die maßgeblichen Identitäten sind MAIL FROM und HELO beziehungsweise EHLO. Das sichtbare From: im Nachrichtenkopf ist eine andere Identität. SPF allein bestätigt daher nicht die Adresse, die Ihr E-Mail-Programm als Absender anzeigt.

Bei einem leeren SMTP-Rückpfad, etwa MAIL FROM:<>, verwendet SPF eine aus der HELO-Domain gebildete Identität. Ein Domaincheck ohne die SMTP-Verbindung kennt diese konkrete Situation nicht. Die Unterscheidung ist in RFC 7208, Abschnitte 2.3–2.5 beschrieben.

Ein DNS-Check kann den veröffentlichten SPF-Record, erkennbare Verweise und bestimmte Konfigurationsfehler zeigen. Er weist ohne Versand-IP und SMTP-Absender nicht nach, dass eine bestimmte Nachricht SPF besteht. Ein fehlender Record ist außerdem von einer vorübergehend gescheiterten DNS-Abfrage zu unterscheiden.

SPF verschlüsselt keine Nachricht, prüft nicht ihren Inhalt und bestätigt keine persönliche Identität. Für die Verbindung einer erfolgreichen Authentifizierung mit der sichtbaren Absenderdomain kommt DMARC hinzu. DKIM liefert dafür einen zweiten möglichen Prüfpfad über eine Signatur.

Wie eine SPF-Prüfung abläuft

Der Empfänger bestimmt die Verbindungs-IP und SMTP-Identität und fragt den zugehörigen SPF-Record ab. Nach der Syntaxprüfung wertet er die Mechanismen von links nach rechts aus. Der erste passende Mechanismus bestimmt das Ergebnis. Auch ein Fehler kann die Auswertung vorher beenden. Wenn kein Mechanismus passt, entscheidet ein vorhandenes redirect; ohne diesen Verweis lautet das Standardergebnis Neutral.

Ohne SPF fehlt die veröffentlichte SPF-Autorisierung für diese Domain. Empfänger können Nachrichten trotzdem annehmen und mit DKIM, DMARC oder anderen Verfahren untersuchen. Mit SPF lässt sich dagegen ausdrücken, welche Server autorisiert sind und welche nicht. Das macht Versandwege nachvollziehbar; es garantiert weder eine gefahrlose Nachricht noch deren Annahme.

Diese Ergebnisse und ihre Grenzen sind in RFC 7208, Abschnitt 2.6 definiert. Ein Pass ist kein Versprechen, dass die Nachricht im Posteingang landet. Ein Fail ist für sich allein ebenfalls keine universelle Anweisung, sie abzulehnen.

SPF-Record lesen: Mechanismen, include und redirect

Ein SPF-Record beginnt mit v=spf1. Danach folgen Mechanismen und gegebenenfalls Modifikatoren. Die Syntax des gesamten Records wird vor der eigentlichen Auswertung geprüft. Ein Fehler in einem späteren Teil wird also nicht dadurch gültig, dass ein früherer Mechanismus passen könnte.

Die angegebenen IP-Netze sowie Domains mit example sind Dokumentationsbeispiele. Auch ein tatsächlich verwendeter Anbietername in der Tabelle ist keine Empfehlung, dessen include ungeprüft in Ihre Domain einzutragen. Verwenden Sie nur die vom zuständigen Versanddienst für Ihren Versandweg angegebenen Werte.

include ergänzt einen Auswertungspfad

Bei include, etwa include:sender.example, führt ein Pass der Zielrichtlinie zu einem Treffer dieses Mechanismus. Mit dem üblichen positiven Qualifier ergibt das auch im aufrufenden Record Pass. Liefert das Ziel dagegen Fail, Softfail oder Neutral, passt include nicht; die Auswertung geht im aufrufenden Record weiter. Ein Fehler im Ziel kann sie jedoch abbrechen. Ein Ziel ohne SPF-Record führt bei erreichtem include zu PermError.

Sie kopieren mit include also keine Textzeile in Ihren Record. Der Empfänger wertet eine weitere Richtlinie aus, und deren DNS-auslösende Terme zählen zum gemeinsamen Limit. Die genaue Ergebniszuordnung steht in RFC 7208, Abschnitt 5.2.

redirect delegiert die verbleibende Auswertung

Ein gültiger SPF-Record darf nur aus Version und redirect bestehen:

v=spf1 redirect=policy.example

Wird der Verweis erreicht, übernimmt SPF das Ergebnis der Zielrichtlinie. Fehlt dort ein SPF-Record, entsteht PermError; ein vorübergehender DNS-Fehler ist als solcher zu behandeln. Ein lokales include ist keine Voraussetzung für diese Delegation.

redirect ist ein Modifikator und muss nicht am Textende stehen. Es darf nur einmal vorkommen. Enthält der Record einen all-Mechanismus, wird redirect unabhängig von seiner Position ignoriert. Ein früherer Treffer kann außerdem verhindern, dass ein ansonsten vorhandener Verweis überhaupt ausgewertet wird. RFC 7208, Abschnitte 5.1 und 6.1

Was -all, ~all, ?all und +all bedeuten

Der Qualifier vor einem Mechanismus bestimmt bei einem Treffer das SPF-Ergebnis. Fehlt er, gilt +. Da all immer passt, wird es üblicherweise als abschließender Mechanismus verwendet.

all ist nicht syntaktisch vorgeschrieben. Ohne passenden Mechanismus und ohne redirect ist das Ergebnis aber Neutral. Ob -all zu Ihrer vollständigen Senderliste passt oder zunächst ~all verwendet wird, muss zur tatsächlichen Konfiguration passen; keine der beiden Schreibweisen garantiert Annahme oder Ablehnung beim Empfänger.

Zu viele DNS-Lookups: was das Limit tatsächlich zählt

Die oft genannte Grenze von zehn betrifft DNS-auslösende SPF-Terme, nicht zehn sichtbare include-Wörter und nicht zehn DNS-Pakete. Gezählt werden die ausgewerteten include, a, mx, ptr, exists und redirect, einschließlich der verschachtelten Auswertung. ip4, ip6 und all zählen nicht dazu. Auch die Versionsangabe v=spf1 verbraucht keinen dieser Plätze. DNSSEC- und DANE-Abfragen gehören nicht zu diesem SPF-Termbudget.

Wird ein elfter solcher Term erforderlich, muss die SPF-Auswertung PermError ergeben. Trifft vorher ein Mechanismus, wird der übrige Auswertungspfad nicht mehr durchlaufen. Deshalb hängt die tatsächliche Belastung von der untersuchten IP und Identität ab. Ein statischer Überblick über alle Zweige ist hilfreich, aber noch kein vollständiger Beleg für jede denkbare Nachricht.

Zusätzlich gelten weitere Grenzen:

• MX-Auflösung: Für die nachgeschlagenen Adressen gelten zusätzliche Grenzen. Ein Überschreiten der in RFC 7208 beschriebenen MX-Adressgrenze führt zu PermError.
• PTR und %{p}: Auch hier werden die zu validierenden Adressen begrenzt. Weitere Ergebnisse werden nach der Grenze ignoriert; daraus folgt nicht dieselbe pauschale Fehlerregel wie bei MX. ptr sollte nach dem Standard nicht in neuen SPF-Records verwendet werden.
• Leere Antworten: Für void lookups – DNS-Abfragen ohne passende Antwort oder mit NXDOMAIN – empfiehlt der Standard ein Limit von zwei. Es darf konfigurierbar sein; wird das angewendete Limit überschritten, ist das Ergebnis PermError.

Die unterschiedlichen Regeln stehen in RFC 7208, Abschnitt 4.6.4. Sie sollten bei der Diagnose nicht zu einem einzigen pauschalen „DNS-Limit“ zusammengezogen werden.

Drei Wege, einen zu komplexen Record zu untersuchen

Senderliste bereinigen. Ordnen Sie jedem erlaubten Dienst einen tatsächlich genutzten Versandweg zu. Entfernen Sie Einträge erst, wenn ihre Nutzung geklärt ist. Ein vergessener Newsletterdienst und eine unbenutzte alte Freigabe sind unterschiedliche Fälle.

Versandwege auf Subdomains verteilen. Eine eigene Versand-Subdomain kann die Richtlinien trennen, wenn der Dienst diese Domain tatsächlich im MAIL FROM verwendet. Nur einen weiteren SPF-Record unter einem neuen Namen zu veröffentlichen, ändert den Versandweg nicht. Prüfen Sie anschließend das benötigte DMARC-Alignment zur sichtbaren From:-Domain.

Flattening nur mit laufender Pflege. Das Ersetzen von Anbieter-Verweisen durch IP-Netze kann DNS-auslösende Terme reduzieren. Eine einmal kopierte Liste kann aber veralten oder eine dynamische Richtlinie unvollständig abbilden. Wer diese Methode nutzt, übernimmt die Pflege der erlaubten Adressen. Makros benötigen zudem den jeweiligen Auswertungskontext; ein Domaincheck kann nicht jede mögliche Expansion abschließend prüfen. Sie umgehen das Limit nicht. Fehlen Senderdaten für die Expansion, lässt sich dieser Teil der Auswertung nicht abschließend beurteilen. Daraus folgt weder ein DNS-Ausfall noch eine vollständig bestandene SPF-Prüfung.

Einen bestehenden SPF-Eintrag prüfen

1. Versandweg bestimmen: Welche Anwendung versendet, welche IP verbindet sich mit dem Empfänger, und welche Domain steht im SMTP-MAIL FROM? Verwechseln Sie das nicht mit der sichtbaren Absenderadresse.
2. DNS-Eintrag nachsehen: Fragen Sie TXT für diese Domain ab. Der folgende Befehl ist ein Lese-Beispiel, keine hier ausgeführte Messung:

dig TXT example.com

3. Passende Records zählen: Es darf für diese Abfrage nur einen SPF-Record geben. Andere TXT-Records können daneben existieren. Zusammengehörige Zeichenketten eines einzelnen TXT-Records werden ohne zusätzliche Leerzeichen verbunden.
4. Syntax und Verweise untersuchen: Prüfen Sie Qualifier, Anbieterangaben, include-Ziele und redirect. Unterscheiden Sie einen fehlenden Eintrag von DNS-Fehlern und untersuchen Sie den für Ihren Versandweg relevanten Lookup-Pfad.
5. Nachricht getrennt beurteilen: Für ein tatsächliches SPF-Ergebnis benötigen Sie die Verbindungsdaten oder den Befund eines vertrauenswürdigen empfangenden Systems. Ein beliebiges Authentication-Results im Header ist ohne geklärte Herkunft kein verlässlicher Beleg. Der Abschnitt zu Headerbefunden erklärt diesen Diagnoseweg.

Mit dem E-Mail Security Check können Sie öffentlich erreichbare Konfigurationsmerkmale Ihrer Domain prüfen. Ein Befund kann für die erste Klärung genügen. Bei einer aufgelösten Delegation sind Ursprungsrecord und wirksame Zielrichtlinie auseinanderzuhalten. Der Domaincheck ersetzt keinen Nachweis, dass jeder Ihrer Versanddienste eine konkrete Nachricht korrekt authentifiziert.

SPF dokumentieren: technische Maßnahme und rechtlicher Kontext

Halten Sie fest, welche Versanddienste Sie autorisieren, wer ihre DNS-Einträge pflegt und was bei Änderungen geprüft werden muss. SPF kann so Teil einer nachvollziehbaren technischen Absicherung sein. Ein veröffentlichter Record belegt aber weder die vollständige Wirksamkeit Ihrer Schutzmaßnahmen noch die Einhaltung eines Gesetzes.

Die folgenden Bezüge betreffen den bestehenden deutschen und EU-Kontext dieses Ratgebers; daraus folgt keine allgemeine Vorgabe für andere Länder:

• Deutschland: § 30 BSIG verlangt von den erfassten Einrichtungen angemessene und verhältnismäßige Risikomanagementmaßnahmen. Daraus lässt sich keine pauschale SPF-Pflicht für jede Domain ableiten.
• Europäische Union: Artikel 32 DSGVO betrifft ein dem Risiko angemessenes Schutzniveau bei der Verarbeitung personenbezogener Daten. SPF verschlüsselt keine Inhalte und verhindert nicht den Missbrauch eines bereits kompromittierten, autorisierten Kontos.
• Technische Profile und Verträge: Anforderungen wie die BSI TR-03182 zur E-Mail-Authentifizierung sind gesondert zu betrachten. Ein bestimmtes SPF-Ergebnis oder -all ist kein Konformitätsnachweis. Zusätzliche Vertragsanforderungen sind ebenfalls von der SPF-Protokollsyntax zu trennen.

Für die Einordnung möglicher Angriffe lesen Sie die Abschnitte zu E-Mail-Spoofing und Phishing. SPF ist ein begrenzter Baustein gegen missbräuchliche Domainverwendung, kein allgemeiner Schutz vor allen gefälschten oder schädlichen E-Mails.

Anleitung für Ihren Versanddienst

Wählen Sie die vorhandene Anleitung passend zu dem Dienst, der tatsächlich für Ihre Domain versendet. Die Kapitel erläutern unterschiedliche Konfigurationswege; ihre Existenz bestätigt nicht die Konfiguration Ihrer Domain.