Eine Domain wird für E-Mail genutzt, doch Nachrichten landen im Spamordner. Oder ein Mailanbieter meldet, dass SPF fehlt, ungültig ist oder nicht zum verwendeten Versanddienst passt. In solchen Fällen liegt das Problem nicht zwingend am Postfach selbst. Moderne E-Mail-Zustellung hängt auch davon ab, ob empfangende Systeme nachvollziehen können, welche Server eine Domain für den Versand autorisiert.
SPF steht für Sender Policy Framework. Der DNS-Eintrag autorisiert Server für die Verwendung einer Domain in den SMTP-Absenderidentitäten MAIL FROM und HELO. Bei normalen Nachrichten ist für die SPF-Prüfung meist die Domain aus MAIL FROM relevant, die später häufig als Return-Path sichtbar wird. Die für Menschen sichtbare Adresse im From:-Feld ist davon technisch zu unterscheiden. Genau diese Trennung ist wichtig, wenn Sie SPF-Fehler oder einen bestandenen SPF-Test richtig einordnen möchten.
SPF direkt prüfen, analysieren und zusammensetzen
Nutzen Sie das kostenlose Werkzeug direkt im Beitrag, um den veröffentlichten SPF-Record einer Domain abzurufen, einzelne Mechanismen einzuordnen, einen vorhandenen Record anzupassen, mehrere SPF-Angaben zu konsolidieren oder relevante Angaben aus einem Mail-Header herauszulesen. Änderungen an Ihrer DNS-Zone nimmt das Werkzeug nicht vor.
1. Domain prüfen veröffentlichten SPF-Record aus dem DNS abrufen
Geben Sie einen Domainnamen ein. Das Werkzeug sucht dessen TXT-Datensätze und wertet vorhandene SPF-v1-Records aus.
2. SPF-Record analysieren Mechanismen, Qualifier und DNS-Lookups einordnen
Fügen Sie einen vollständigen SPF-Record ein. Die Analyse erfolgt ausschließlich lokal in Ihrem Browser.
3. SPF-Record erstellen oder anpassen Versanddienste, IP-Adressen und Policy zusammensetzen
@ erzeugt a.
@ erzeugt mx.
-all erst ein, wenn sämtliche legitimen Versandwege erfasst sind.
4. Mehrere SPF-Records zusammenführen Dubletten entfernen und einen Konsolidierungsentwurf erzeugen
5. Mail-Header prüfen SPF-Ergebnis, MAIL FROM und sichtbare From-Domain erkennen
Fügen Sie den vollständigen Nachrichtenkopf ein. Die Auswertung erfolgt lokal im Browser.
SPF verstehen: Welche Absenderidentität tatsächlich geprüft wird
Eine E-Mail enthält mehrere Absenderangaben. Im Postfach sehen Sie beispielsweise einen Namen und die Adresse im From:-Feld. Beim SMTP-Transport gibt es zusätzlich den sogenannten Envelope-Sender aus MAIL FROM. Diese Identitäten können dieselbe Domain verwenden, müssen es technisch aber nicht.
SPF setzt bei den SMTP-Identitäten an. Der Domaininhaber veröffentlicht im DNS, welche Server beziehungsweise IP-Adressen die betreffende Domain dort verwenden dürfen. Der empfangende Mailserver vergleicht die einliefernde IP-Adresse mit dieser Policy. Passt die Versandquelle zur Regel, kann SPF ein pass liefern. Passt sie nicht, kommen je nach Record und Situation unter anderem fail, softfail, neutral oder ein Fehlerergebnis infrage.
Für die Diagnose sollten Sie deshalb zuerst herausfinden, welche Domain im technischen MAIL FROM verwendet wurde und von welcher IP-Adresse die Nachricht beim Empfänger ankam. Ist MAIL FROM leer, wie es beispielsweise bei bestimmten Unzustellbarkeitsnachrichten vorkommt, erhält die HELO-Identität zusätzliche Bedeutung.
Wichtig ist die Grenze des Verfahrens: SPF bestätigt weder den Inhalt einer Nachricht noch automatisch die sichtbare From-Adresse. Ein bestandener SPF-Check ist deshalb kein Beweis dafür, dass eine E-Mail erwünscht oder ungefährlich ist. Für die Verbindung zur sichtbaren Absenderdomain spielt insbesondere DMARC eine zusätzliche Rolle.
SPF im DNS: Aufbau, Mechanismen und technische Grenzen
SPF wird als TXT-Datensatz am jeweils relevanten Domainnamen veröffentlicht. Andere Mailserver können diesen DNS-Eintrag abfragen. Der Text ist keine Beschreibung für Menschen, sondern eine strukturierte Regel, aus der SPF-Prüfer die erlaubten Versandquellen und die gewünschte Bewertung übriger Server ableiten.
Ein SPF-v1-Record beginnt mit v=spf1. Danach folgen Mechanismen und gegebenenfalls Modifier. Häufig steht am Ende ein all-Mechanismus. Er passt immer, sobald die Auswertung ihn erreicht, und legt über seinen Qualifier fest, welches SPF-Ergebnis für die bis dahin nicht erfassten Server entsteht.
Übernehmen Sie Include-Domains, IP-Netze oder andere Werte nicht aus beliebigen Beispielen. Entscheidend sind die aktuelle Dokumentation Ihres Mail- oder Versanddienstes und Ihre tatsächlich eingesetzte Infrastruktur. Ein syntaktisch sauberer SPF-Record kann fachlich trotzdem falsch sein, wenn er alte oder fehlende Versandwege enthält.
v=spf1kennzeichnet den Datensatz als SPF-Version 1.include:lässt die SPF-Regeln einer anderen Domain rekursiv auswerten. Das ist bei externen Mail-, Newsletter- oder Transaktionsdiensten verbreitet.ip4:autorisiert eine IPv4-Adresse oder ein IPv4-Netz direkt.ip6:autorisiert eine IPv6-Adresse oder ein IPv6-Netz direkt.avergleicht die einliefernde IP mit den A- beziehungsweise AAAA-Adressen des ausgewerteten Zielnamens. Mita:hostnamekann ausdrücklich ein anderer Name angegeben werden.mxermittelt die MX-Hosts des Zielnamens und vergleicht die Absender-IP mit deren Adressen. Verwenden Sie den Mechanismus nur, wenn diese Systeme tatsächlich auch ausgehend autorisiert sein sollen.exists:kann anhand eines Domain-Ausdrucks eine A-Abfrage auslösen und wird vor allem in komplexeren Policies eingesetzt.redirect=verweist nach erfolgloser Mechanismenprüfung auf die SPF-Policy einer anderen Domain. Ist im eigenen Record einallvorhanden, wirdredirectnicht verwendet.ptrbasiert auf Reverse-DNS. Der Mechanismus ist zwar Teil von SPF v1, soll nach dem SPF-Standard aber nicht neu veröffentlicht werden.allbeschreibt die Bewertung aller bis dahin nicht erfassten Server.-allerzeugt Fail,~allSoftfail und?allNeutral. Ein unqualifiziertesallentspricht+allund lässt damit grundsätzlich jeden Server bestehen.
Bei komplexen Records zählt nicht nur deren sichtbare Länge. SPF begrenzt die während einer Auswertung verwendeten DNS-abfragenden Terme auf zehn. Dazu gehören include, a, mx, ptr, exists und redirect; rekursive Includes zählen in dieselbe Gesamtgrenze hinein. ip4, ip6 und all gehören dagegen nicht zu dieser Zehn-Terme-Grenze. Wird sie im tatsächlichen Auswertungspfad überschritten, entsteht ein permerror.
SPF ist deshalb kein einfacher Ein/Aus-Schalter. Ihr Record muss die reale Versandlandschaft abbilden: klassischer Mailprovider, Newsletterdienst, Shop, CRM, Helpdesk, Buchhaltung oder eigene Server können jeweils beteiligt sein. Prüfen Sie außerdem den konkreten Domainnamen. Ein SPF-Record für example.de wird nicht automatisch als SPF-Policy für news.example.de geerbt.
SPF-Fehler systematisch prüfen: Domain, Versandweg und DNS-Grenzen
SPF-Probleme zeigen sich selten als ein einziges eindeutiges Symptom. Häufig beginnt die Suche mit einer Provider-Meldung, einem Zustellungsbericht, auffälligen Spam-Einstufungen oder der Beobachtung, dass nur ein bestimmter Versanddienst betroffen ist. Ändern Sie den DNS-Eintrag nicht sofort. Ermitteln Sie zuerst die geprüfte Domain, den tatsächlichen Versandweg und möglichst das SPF-Ergebnis aus Authentication-Results.
Trennen Sie dabei Beobachtung und Ursache. Eine Nachricht kann trotz SPF-Pass im Spam landen, weil Reputation, Inhalt, Versandhistorie, DKIM, DMARC und Empfängerregeln zusätzlich einfließen. Umgekehrt kann ein formal kleiner SPF-Fehler legitime Nachrichten treffen. Die folgende Übersicht ordnet typische Fälle nach Diagnosewert statt nach bloßer Fehlermeldung.
| Symptom | Mögliche Ursache | Prüfen Sie zuerst | Sinnvoller nächster Schritt |
|---|---|---|---|
| Ein Provider oder Prüfwerkzeug findet mehrere SPF-Records für denselben Domainnamen. | Werden bei der SPF-Auswahl mehrere passende v=spf1-Records gefunden, ist die Policy nicht eindeutig und die SPF-Auswertung endet mit permerror. Andere, nicht zu SPF gehörende TXT-Datensätze dürfen parallel existieren. |
Suchen Sie am tatsächlich verwendeten MAIL-FROM- beziehungsweise HELO-Domainnamen nach allen TXT-Datensätzen, die mit v=spf1 beginnen. |
Konsolidieren Sie die benötigten Versandquellen fachlich in einem SPF-Record. Ergänzen Sie nicht einfach einen weiteren separaten SPF-Datensatz. |
| Probleme beginnen nach einem Wechsel des Mailanbieters, Hosters oder Versanddienstes. | Ein früher korrektes include oder eine alte IP-Freigabe kann noch auf die vorherige Infrastruktur zeigen. |
Ordnen Sie jeden SPF-Bestandteil einem heute aktiven Versandweg zu und vergleichen Sie Include-Werte mit der aktuellen Dokumentation des Dienstes. | Entfernen oder ersetzen Sie Altbestand erst, wenn sicher ist, dass darüber keine legitimen Nachrichten mehr gesendet werden. |
| Ein externer Versanddienst meldet, dass sein SPF-Teil fehlt oder falsch eingebunden ist. | Der include-Wert kann falsch geschrieben, veraltet oder für ein anderes Produkt beziehungsweise eine andere Versandart vorgesehen sein. |
Vergleichen Sie den konkreten Wert Zeichen für Zeichen mit den aktuellen Vorgaben des betreffenden Dienstes. | Übernehmen Sie den Anbieterwert gezielt in die bestehende SPF-Policy. Kopieren Sie keine vollständigen fremden SPF-Records aus Foren oder anderen Domains. |
| Der SPF-Test scheitert bei einer Domain mit vielen externen Versanddiensten. | Die SPF-Auswertung darf höchstens zehn DNS-abfragende Terme verwenden. include, a, mx, ptr, exists und redirect zählen dazu; rekursive Includes können weitere Terme beitragen. |
Prüfen Sie die vollständigen Include-Ketten und nicht nur die Zahl der Begriffe im sichtbaren Record. ip4, ip6 und all zählen nicht zu dieser Zehn-Terme-Grenze. |
Entfernen Sie nicht mehr benötigte Versandwege und vereinfachen Sie die Policy fachlich. Ein weiteres Include kann ein ohnehin knappes Setup zum permerror bringen. |
| Mails eines Webservers, Shops oder internen Systems werden abgewiesen oder auffällig bewertet. | Die tatsächlich sendende IP kann fehlen. Ebenso kann das System eine andere MAIL-FROM-Domain verwenden als erwartet, sodass eine andere SPF-Policy geprüft wird. | Lesen Sie aus den Mail-Headern die einliefernde IP, smtp.mailfrom beziehungsweise den Return-Path und das SPF-Ergebnis aus. |
Autorisierten Versandweg und tatsächlich verwendete Absenderidentität zusammenführen. Ergänzen Sie eine IP nur, wenn sie dauerhaft und ausdrücklich für diesen Versand vorgesehen ist. |
Der SPF-Record enthält keine erkennbare all-Abschlussregel. |
Das ist nicht automatisch ungültig. Ohne all und ohne redirect ergibt ein vollständig erfolgloser Mechanismenlauf standardmäßig Neutral. Die beabsichtigte Policy ist dadurch allerdings weniger ausdrücklich. |
Prüfen Sie, ob das Fehlen bewusst ist und ob alle legitimen Versandquellen bekannt sind. Achten Sie besonders darauf, nicht vorschnell -all einzusetzen. |
Legen Sie die Abschlussregel bewusst fest. -all, ~all, ?all und +all haben unterschiedliche SPF-Ergebnisse und sollten nicht nach vermeintlicher „Strenge“ gewählt werden. |
Mails von name@example.de funktionieren, ein Versand über service.example.de oder news.example.de dagegen nicht. |
SPF-Policies werden am konkret geprüften Domainnamen gesucht. Ein SPF-Record der Hauptdomain wird nicht automatisch auf eine Subdomain vererbt. | Ermitteln Sie die Domain aus MAIL FROM beziehungsweise smtp.mailfrom bei der betroffenen Nachricht. |
Prüfen Sie genau diesen Domainnamen im DNS. Wird eine Subdomain eigenständig als Envelope-Sender genutzt, benötigt sie eine dazu passende Policy. |
| Normale Postfachmails funktionieren, Newsletter, CRM-, Helpdesk- oder Transaktionsmails dagegen nicht zuverlässig. | Der Haupt-Mailprovider ist im SPF erfasst, ein zusätzlicher Drittversender aber nicht oder er verwendet eine eigene Bounce- beziehungsweise MAIL-FROM-Domain. | Listen Sie alle Systeme auf, die tatsächlich E-Mails versenden, und prüfen Sie für jeden Dienst die technische Absenderdomain. | Ergänzen Sie nur die Versandquellen, die für Ihre Domain tatsächlich autorisiert werden müssen. Ein Dienst mit eigener, korrekt authentifizierter Envelope-Domain benötigt nicht zwangsläufig einen Include in Ihrer sichtbaren Hauptdomain. |
| Nach einer Migration funktionieren einige alte Anwendungen weiter, neue Versandwege aber nur teilweise. | Alte und neue Anbieterangaben können vermischt worden sein. Ein umfangreicher SPF-Record ist nicht automatisch ein vollständiger oder aktueller Record. | Dokumentieren Sie, welchem aktiven System jedes include, jede IP und jeder weitere Mechanismus zugeordnet ist. |
Bereinigen Sie unbekannte Altbestandteile erst nach einer Bestandsaufnahme. Nicht nachvollziehbare Einträge sind weder automatisch falsch noch eine sinnvolle Dauerlösung. |
| Probleme treten vor allem bei automatisch weitergeleiteten Nachrichten auf. | Bei klassischer Weiterleitung liefert ein anderer Server die Nachricht beim endgültigen Empfänger ein, während der ursprüngliche Envelope-Sender bestehen bleiben kann. Diese neue Server-IP ist üblicherweise nicht im SPF der ursprünglichen Domain autorisiert. | Prüfen Sie, ob die Nachricht direkt zugestellt oder weitergeleitet wurde und welcher Server sie zuletzt übergeben hat. | Bewerten Sie die Weiterleitung getrennt von einer vermeintlich falschen SPF-Policy. Verfahren wie Sender Rewriting Scheme können den Envelope-Sender bei Weiterleitungen anpassen; zusätzlich kann eine intakte, ausgerichtete DKIM-Signatur für DMARC entscheidend sein. |
| Nachrichten landen trotz SPF-Pass weiterhin im Spamordner. | SPF ist nur ein Authentifizierungssignal. Spamfilter berücksichtigen zusätzlich unter anderem Reputation, Inhalt, Versandvolumen, Empfängerreaktionen, DKIM, DMARC und eigene Richtlinien. | Prüfen Sie neben SPF insbesondere DKIM, DMARC, Absenderkonsistenz, Versandhistorie und konkrete Zustellungsberichte. | Behandeln Sie SPF nicht als Zustellgarantie. Ist SPF technisch sauber, verlagert sich die Diagnose auf die übrigen Authentifizierungs- und Reputationssignale. |
SPF steht auf pass, DMARC scheitert dennoch. |
SPF kann für eine MAIL-FROM-Domain bestehen, die nicht zur sichtbaren Author Domain im From:-Feld ausgerichtet ist. Ein SPF-Pass allein genügt DMARC deshalb nicht in jeder Konstellation. |
Vergleichen Sie smtp.mailfrom, die sichtbare From-Domain und gegebenenfalls die Domain einer bestandenen DKIM-Signatur. |
Prüfen Sie das DMARC-Alignment. Für einen erfolgreichen DMARC-Pfad muss mindestens eine relevante, bestandene SPF- oder DKIM-Authentifizierung zur sichtbaren Author Domain ausgerichtet sein. |
Eine häufige Fehlannahme besteht darin, SPF wie eine Liste erlaubter E-Mail-Adressen zu behandeln. Tatsächlich autorisiert SPF Versandquellen für technische SMTP-Domainidentitäten. Deshalb kann eine Konfiguration auf den ersten Blick plausibel aussehen und trotzdem an der falschen Domain ansetzen. Ein Newsletter kann beispielsweise sichtbar mit newsletter@example.de auftreten, technisch aber eine separate Bounce-Domain im Envelope-Sender verwenden.
Erstellen Sie vor Änderungen eine vollständige Versandinventur. Dazu gehören persönliche Postfächer ebenso wie Kontaktformulare, Shopsysteme, Buchhaltungssoftware, Ticketsysteme, Newsletterdienste, CRM-Plattformen, Monitoring und automatische Systemmeldungen. Notieren Sie für jeden Weg auch die tatsächlich verwendete MAIL-FROM-Domain. Erst dann lässt sich beurteilen, ob ein SPF-Record zu eng, zu weit, veraltet oder formal fehlerhaft ist.
Behandeln Sie DNS-Änderungen entsprechend vorsichtig. Ein falsches Include, eine veraltete IP oder eine zu früh verschärfte Abschlussregel kann legitime Zustellung unmittelbar beeinträchtigen. Gehen Sie deshalb in dieser Reihenfolge vor: technische Absenderdomain feststellen, tatsächliche Versandquellen erfassen, aktuelle Anbieterangaben prüfen, vorhandene SPF-Terme zuordnen und erst danach den Record ändern.
SPF, DKIM und DMARC sauber voneinander trennen
SPF bewertet, ob die einliefernde IP-Adresse für die verwendete MAIL-FROM- oder HELO-Domain autorisiert ist. Der Mechanismus arbeitet damit an der SMTP-Transportebene. Ein SPF-Pass bestätigt nicht automatisch die im Postfach sichtbare Absenderdomain.
DKIM verfolgt einen anderen Ansatz. Dabei signiert ein versendendes System ausgewählte Nachrichtenbestandteile kryptografisch und nennt in der Signatur eine Domain. Der Empfänger kann den öffentlichen Schlüssel aus dem DNS abrufen und prüfen, ob die Signatur noch gültig ist. DKIM autorisiert damit nicht einfach eine Server-IP, sondern schafft eine überprüfbare Signaturbeziehung zur Nachricht.
DMARC verbindet diese Authentifizierungsverfahren mit der sichtbaren Author Domain aus dem From:-Feld. Entscheidend ist das sogenannte Alignment: Für einen erfolgreichen DMARC-Pfad muss mindestens eine bestandene SPF- oder DKIM-Authentifizierung nach den DMARC-Regeln zur sichtbaren Absenderdomain ausgerichtet sein. Deshalb kann SPF bestehen und DMARC trotzdem scheitern, wenn SPF eine technisch andere, nicht passend ausgerichtete MAIL-FROM-Domain bestätigt.
Zusätzlich veröffentlicht DMARC eine Richtlinie und ermöglicht Berichte über die Domainnutzung. Eine Domain kann damit beispielsweise eine Behandlung für nicht erfolgreich authentifizierte und ausgerichtete Nachrichten anfordern. Die endgültige Zustellungsentscheidung bleibt jedoch beim empfangenden System. SPF, DKIM und DMARC ergänzen sich deshalb, ersetzen weder Spamfilter noch eine saubere Versandpraxis und verhindern auch keinen Missbrauch eines bloßen Anzeigenamens.
FAQ zu SPF
Was bedeutet SPF?
SPF steht für Sender Policy Framework. Über einen DNS-TXT-Record kann eine Domain festlegen, welche Server ihre Domain in den SMTP-Identitäten MAIL FROM beziehungsweise HELO verwenden dürfen. SPF prüft damit technische Versandautorisierung und nicht unmittelbar die sichtbare From-Adresse.
Wo wird SPF eingetragen?
Veröffentlichen Sie SPF als TXT-Datensatz am relevanten Domainnamen. Für die Diagnose zählt nicht automatisch die Domain Ihrer sichtbaren E-Mail-Adresse, sondern der Domainname, dessen SPF-Policy bei der jeweiligen SMTP-Identität ausgewertet wird.
Was ist ein TXT-Eintrag?
Ein TXT-Eintrag ist ein Textdatensatz im DNS. SPF nutzt diesen Datensatztyp für die maschinenlesbare Policy. Ein DNS-Name kann daneben weitere TXT-Datensätze für andere Zwecke besitzen; problematisch sind mehrere gleichzeitig auswählbare SPF-v1-Records, nicht mehrere TXT-Records grundsätzlich.
Warum darf es nur einen SPF-Record geben?
Für denselben Domainnamen darf die SPF-Auswahl nicht mehrere SPF-v1-Records ergeben. Werden mehrere passende Records gefunden, endet die SPF-Prüfung mit permerror. Benötigen Sie mehrere Mail- und Versanddienste, müssen deren erforderliche Mechanismen fachlich in einer einzigen SPF-Policy zusammengeführt werden.
Was bedeutet include?
include: lässt die SPF-Regeln einer anderen Domain rekursiv auswerten. Mail-, Newsletter- und Transaktionsdienste nutzen dieses Verfahren häufig, damit ihre aktuelle Versand-Infrastruktur nicht als starre IP-Liste in Ihrer DNS-Zone gepflegt werden muss. Verwenden Sie ausschließlich den Include-Wert, den der betreffende Dienst für Ihren konkreten Versandweg dokumentiert.
Was bedeuten -all und ~all?
-all erzeugt für einen nicht zuvor erfassten Server das SPF-Ergebnis Fail. ~all erzeugt Softfail, ?all Neutral. Ein unqualifiziertes all entspricht +all und führt beim Erreichen dieses Terms zu Pass. Welche Zustellungsfolge daraus entsteht, entscheidet das empfangende System im Gesamtkontext. Verschärfen Sie die Policy erst, wenn alle legitimen Versandquellen vollständig erfasst sind.
Warum landen E-Mails trotz SPF im Spam?
Ein SPF-Pass ist keine Posteingangsgarantie. Empfänger berücksichtigen zusätzlich unter anderem DKIM, DMARC, Domain- und IP-Reputation, Versandvolumen, Inhalte, Nutzerreaktionen und ihre eigenen Filterregeln. Besteht SPF, sollten Sie die Zustellungsanalyse deshalb auf diese weiteren Signale ausweiten.
Ist SPF dasselbe wie DKIM?
Nein. SPF bewertet die Autorisierung einer einliefernden IP für eine SMTP-Domainidentität. DKIM prüft eine kryptografische Nachrichtensignatur und die darin angegebene Signaturdomain. DMARC kann beide Verfahren anschließend mit der sichtbaren From-Domain in Beziehung setzen.
SPF ist ein wichtiger, aber klar begrenzter Baustein der E-Mail-Authentifizierung. Prüfen Sie bei Problemen nicht nur, ob irgendwo ein v=spf1-Eintrag existiert. Entscheidend sind die tatsächlich ausgewertete Domain, die einliefernde Server-IP, die vollständige Versandlandschaft und die technische Gültigkeit der Policy.
Besonders häufig finden sich mehrere SPF-Records, veraltete Includes, nicht erfasste Drittversender, falsche Subdomain-Annahmen, zu viele DNS-abfragende Terme und Probleme durch Weiterleitungen. Ziehen Sie für die vollständige Einordnung anschließend DKIM und DMARC hinzu. So trennen Sie einen echten SPF-Fehler von Zustellproblemen, deren Ursache an einer anderen Stelle liegt.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten