Eine Domain wird für E-Mail genutzt, aber Nachrichten landen im Spamordner. Oder ein Mailanbieter meldet, dass SPF fehlt, ungültig ist oder nicht zu einem 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 Server prüfen können, welche Systeme für eine Absenderdomain überhaupt senden dürfen.
SPF steht für Sender Policy Framework und ist ein DNS-Eintrag, der beschreibt, welche Server berechtigt sind, E-Mails im Namen einer Domain zu versenden. Damit ist SPF kein Postfachmerkmal, sondern ein Teil der technischen Identitätsprüfung rund um eine Domain. Der Eintrag hilft empfangenden Mailservern einzuschätzen, ob eine Nachricht von einem erlaubten Versandserver kommt oder ob die Absenderdomain möglicherweise missbräuchlich verwendet wird.
Warum SPF überhaupt nötig ist
Eine E-Mail enthält mehrere Absenderangaben. Ein Teil davon ist für Menschen sichtbar, etwa der Name im Postfach oder die angezeigte Von-Adresse. Andere Angaben werden im technischen Versandprotokoll verwendet. Ohne zusätzliche Prüfmechanismen kann eine Nachricht deshalb so aussehen, als stamme sie von einer bestimmten Domain, obwohl der sendende Server nicht vom Domaininhaber vorgesehen ist.
SPF setzt an dieser Stelle an. Der Domaininhaber veröffentlicht im DNS, welche Server für eine Domain senden dürfen. Empfangende Mailserver können diese Information abfragen und mit dem Server vergleichen, der die Nachricht tatsächlich einliefert. Passt der Server zur veröffentlichten SPF-Regel, ist das ein positives Authentifizierungssignal. Passt er nicht, kann dies auf eine Fehlkonfiguration, einen nicht berücksichtigten Versanddienst oder eine missbräuchliche Nutzung der Domain hindeuten.
Für die Zustellung reicht es daher nicht immer, dass ein Postfach existiert und ein SMTP-Server Nachrichten annimmt. Moderne Empfänger bewerten zusätzlich, ob die technische Absenderdomain nachvollziehbar zu den sendenden Systemen passt. SPF ist einer der Bausteine, mit denen diese Bewertung möglich wird.
Wichtig ist die Grenze des Verfahrens: SPF bestätigt nicht, dass eine Nachricht erwünscht, ungefährlich oder inhaltlich korrekt ist. Es beschreibt nur, ob ein sendender Server nach den DNS-Angaben der Domain als berechtigt gelten kann. Gerade diese begrenzte, aber klare Aufgabe macht SPF für die Diagnose von Zustellproblemen so wichtig.
Wo SPF steht und wie ein SPF-Eintrag grundsätzlich aufgebaut ist
SPF wird als TXT-Eintrag in der DNS-Zone der jeweiligen Domain hinterlegt. Ein TXT-Eintrag ist ein DNS-Textdatensatz, den andere Systeme abfragen können. Im Fall von SPF enthält dieser Text keine allgemeine Beschreibung für Menschen, sondern eine maschinenlesbare Regel, die empfangende Mailserver auswerten.
Ein SPF-Eintrag beginnt typischerweise mit v=spf1. Daran erkennen prüfende Systeme, dass der TXT-Datensatz eine SPF-Regel enthält. Danach folgen Mechanismen, die erlaubte Versandquellen beschreiben. Am Ende steht häufig eine Abschlussregel mit all, die festlegt, wie mit allen übrigen Servern umgegangen werden soll.
Als schematische Logik lässt sich ein SPF-Eintrag so verstehen: Version angeben, erlaubte Versandquellen beschreiben, Umgang mit allen anderen Servern festlegen. Diese Darstellung ersetzt keine anbieterabhängige Konfiguration. Include-Werte, IP-Adressen und Dienstvorgaben müssen immer aus der aktuellen Dokumentation des jeweiligen Anbieters stammen und zur tatsächlich verwendeten Versandart passen.
v=spf1kennzeichnet den TXT-Eintrag als SPF-Regel.includeverweist auf SPF-Regeln eines anderen Dienstes, etwa eines Mail- oder Versanddienstleisters. Der konkrete Wert ist anbieterabhängig und sollte nicht aus fremden Beispielen übernommen werden.ip4nennt erlaubte IPv4-Adressen oder IPv4-Bereiche.ip6nennt erlaubte IPv6-Adressen oder IPv6-Bereiche.abezieht sich auf die A- beziehungsweise AAAA-Adresse der Domain. Dadurch kann ein Server erlaubt werden, der über die Adressdatensätze der Domain erreichbar ist.mxbezieht sich auf die Mailserver, die in den MX-Einträgen der Domain stehen. Das ist nur sinnvoll, wenn diese Systeme tatsächlich auch ausgehend senden.allbeschreibt, wie alle nicht vorher erfassten Server bewertet werden sollen. Häufige Varianten sind eine weichere Bewertung mit~alloder eine strengere mit-all.
SPF ist damit kein Schalter, der einfach auf aktiv gesetzt wird. Der Eintrag muss die reale Versandlandschaft der Domain abbilden. Dazu können der normale Mailanbieter, ein Newsletterdienst, ein Helpdesk, ein CRM, ein Shop oder ein Transaktionsmail-Dienst gehören. Werden Einträge blind zusammenkopiert, können legitime Nachrichten scheitern oder die Regel wird unnötig komplex.
Ebenso wichtig ist die konkrete Domain. SPF wird nicht pauschal für eine gesamte Organisation geprüft, sondern für die Domain, die im jeweiligen technischen Versandkontext relevant ist. Wenn Subdomains für Newsletter, Systeme oder Dienste verwendet werden, müssen diese gesondert betrachtet werden.
Typische SPF-Fehler erkennen, bevor die Zustellung leidet
SPF-Probleme zeigen sich selten als ein einzelnes, eindeutig beschriftetes Symptom. Häufig beginnt die Suche mit einer Provider-Meldung, einem Zustellungsbericht, auffälligen Spam-Einstufungen oder der Beobachtung, dass nur bestimmte Versandwege betroffen sind. Gerade deshalb sollte die Diagnose nicht mit einer schnellen Änderung am DNS-Eintrag beginnen, sondern mit der Frage, welche Domain tatsächlich geprüft wird und welcher Server die Nachricht tatsächlich versendet.
Wichtig ist dabei die Trennung zwischen Beobachtung und Ursache. Eine E-Mail kann trotz vorhandenem SPF im Spam landen, weil auch Inhalt, Reputation, DKIM, DMARC, Empfängerregeln oder frühere Versandhistorie eine Rolle spielen. Umgekehrt kann ein formal kleiner SPF-Fehler dazu führen, dass legitime Systeme nicht mehr als erlaubte Absender erkannt werden. Die folgende Übersicht ordnet typische Situationen ein, ohne daraus eine pauschale Änderungsanleitung für produktive DNS-Zonen abzuleiten.
| Woran das Problem erkennbar ist | Was dahinterstecken kann | Was zuerst geprüft werden sollte | Welcher nächste Schritt sinnvoll ist |
|---|---|---|---|
| Der Provider oder ein Prüfwerkzeug meldet mehrere SPF-Einträge für dieselbe Domain. | Für eine Domain darf normalerweise nur ein SPF-Eintrag ausgewertet werden. Mehrere separate TXT-Einträge mit v=spf1 führen häufig dazu, dass das Ergebnis als ungültig gilt, auch wenn jeder Eintrag für sich plausibel aussieht. |
Ob in der DNS-Zone derselben Absenderdomain mehr als ein TXT-Datensatz mit SPF-Inhalt vorhanden ist. Dabei zählt die konkret verwendete Domain, nicht nur die Hauptdomain im Kundenkonto. | Die vorhandenen SPF-Angaben fachlich konsolidieren lassen, statt weitere Einträge zu ergänzen. Dabei müssen alle tatsächlich genutzten Versandwege erhalten bleiben. |
| Probleme treten erst nach einem Wechsel des Mailanbieters, Hostingpakets oder Versanddienstes auf. | Ein früher korrektes include kann veraltet sein oder noch auf den alten Anbieter verweisen. Häufig bleiben solche Reste im DNS stehen, obwohl der betreffende Dienst nicht mehr sendet. |
Welche Dienste aktuell wirklich für die Domain senden und welche SPF-Angaben die jeweiligen Anbieter heute dokumentieren. Alte Anleitungen, Tickets oder kopierte Einträge sollten nicht als aktuelle Quelle gelten. | Anbieterangaben verifizieren und den SPF-Eintrag anhand der aktuellen Versandlandschaft überprüfen lassen. Nicht mehr genutzte Bestandteile sollten nur entfernt werden, wenn sicher ist, dass darüber kein legitimer Versand mehr läuft. |
| Ein bestimmter Dienst meldet, sein SPF-Teil sei nicht korrekt eingebunden, obwohl ein SPF-Eintrag existiert. | Der include-Wert kann falsch geschrieben, unvollständig übernommen oder für einen anderen Dienst beziehungsweise eine andere Region gedacht sein. Auch kleine Abweichungen können dazu führen, dass die erwarteten Regeln nicht abgefragt werden. |
Ob der Include-Wert exakt aus der aktuellen Dokumentation des betreffenden Versanddienstes stammt und zur verwendeten Domain sowie zum gebuchten Versandweg passt. | Den konkreten Include-Wert mit der Anbieter-Dokumentation oder dem Support abgleichen. Ein ungeprüftes Kopieren aus Foren, alten Projekten oder fremden DNS-Zonen ist riskant. |
| Der SPF-Test scheitert besonders bei Domains, die viele externe Dienste eingebunden haben. | Zu viele abhängige DNS-Abfragen können SPF-Prüfungen scheitern lassen. Das betrifft vor allem Einträge mit mehreren include-, a– oder mx-Mechanismen, wenn diese wiederum weitere Abfragen auslösen. |
Welche SPF-Bestandteile DNS-Abfragen verursachen und ob mehrere Versanddienste kumulativ eingebunden wurden. Entscheidend ist nicht nur die sichtbare Länge des Eintrags, sondern die daraus entstehende Abfragekette. | Die eingebundenen Dienste und Mechanismen prüfen lassen und nicht mehr benötigte Versandwege identifizieren. Bei komplexen Setups ist eine saubere Konsolidierung sinnvoller als ein weiteres Anhängen zusätzlicher Includes. |
| Servermails eines Webservers, Shopsystems oder internen Systems werden abgewiesen oder auffällig oft als verdächtig bewertet. | Die im SPF-Eintrag genannte IP-Adresse kann fehlen, veraltet sein oder nicht zur tatsächlich sendenden Maschine passen. Das passiert etwa nach Serverumzügen, neuen IPv6-Konfigurationen oder beim Wechsel zwischen direktem Versand und Relay-Versand. | Von welcher IP-Adresse die betroffenen Nachrichten tatsächlich beim Empfänger ankommen und ob diese Adresse laut Domaininhaber als legitimer Versandweg vorgesehen ist. | Die tatsächlichen Versandwege erfassen und mit der Infrastruktur-Dokumentation abgleichen. Eine IP-Adresse sollte nur ergänzt oder geändert werden, wenn eindeutig geklärt ist, dass sie dauerhaft und berechtigt für die Domain sendet. |
| Ein SPF-Eintrag ist vorhanden, endet aber nicht mit einem klar erkennbaren Umgang für alle übrigen Server. | Ein fehlendes oder missverstandenes all kann die Aussage des Eintrags unscharf machen. Varianten wie -all oder ~all haben unterschiedliche Strenge, werden in der Praxis aber zusätzlich vom empfangenden System und vom Gesamtkontext bewertet. |
Ob der Eintrag am Ende eine bewusste Regel für nicht genannte Server enthält und ob diese Regel zur aktuellen Versandpraxis passt. Besonders riskant ist eine harte Formulierung, wenn noch nicht alle legitimen Absender erfasst sind. | Die Bedeutung der gewählten all-Variante prüfen lassen, bevor sie verschärft oder gelockert wird. Zuerst sollten alle legitimen Versandquellen vollständig bekannt sein. |
E-Mails von name@example.de funktionieren, aber Nachrichten von einer Subdomain wie service.example.de oder news.example.de bereiten Probleme. |
SPF wird für die konkret verwendete Absenderdomain betrachtet. Ein Eintrag für die Hauptdomain deckt eine Subdomain nicht automatisch in jeder relevanten Konstellation ab. | Welche Domain im technischen Mail-From beziehungsweise Return-Path verwendet wird und ob genau für diese Domain oder Subdomain ein passender SPF-Eintrag existiert. | Die betroffenen Subdomains in die Prüfung einbeziehen. Falls Subdomains eigenständig für Versand genutzt werden, sollten deren DNS-Einträge gesondert bewertet und nicht nur aus Sicht der Hauptdomain betrachtet werden. |
| Normale Postfachmails kommen an, aber Newsletter, CRM-Nachrichten, Helpdesk-Antworten oder Transaktionsmails fallen häufiger durch Prüfungen. | Ein externer Versanddienst wurde möglicherweise nicht in die SPF-Betrachtung aufgenommen. Viele Organisationen nutzen neben dem Mailprovider weitere Systeme, die ebenfalls im Namen der Domain senden. | Welche Dienste tatsächlich E-Mails mit der Domain versenden: Newsletterplattform, Helpdesk, CRM, Buchhaltungssystem, Shop, Monitoring oder Formularserver. Außerdem ist zu prüfen, welche Absenderdomain diese Dienste technisch verwenden. | Alle legitimen Versandwege dokumentieren und die SPF-Vorgaben jedes Dienstes anhand aktueller Anbieterangaben prüfen. Der SPF-Eintrag sollte nicht nur den Haupt-Mailserver, sondern die reale Versandlandschaft abbilden. |
| Nach einer Migration funktionieren manche alten Anwendungen weiter, andere neue Versandwege aber nicht zuverlässig. | Veraltete Anbieterangaben können mit neuen Einträgen vermischt worden sein. Dadurch entsteht ein SPF-Eintrag, der zwar umfangreich aussieht, aber nicht mehr sauber zur aktiven Infrastruktur passt. | Ob die einzelnen Bestandteile des SPF-Eintrags noch einem aktiven System zugeordnet werden können. Besonders kritisch sind Einträge, deren Herkunft niemand mehr nachvollziehen kann. | Eine Bestandsaufnahme der sendenden Systeme durchführen lassen. Unklare Bestandteile sollten nicht vorschnell gelöscht, aber auch nicht dauerhaft als vermeintliche Sicherheit betrachtet werden. |
| Probleme zeigen sich vor allem bei weitergeleiteten Nachrichten, etwa wenn Mails von einer Adresse automatisch an ein anderes Postfach umgeleitet werden. | Bei einer Weiterleitung kann die Nachricht von einem Server kommen, der nicht im SPF der ursprünglichen Absenderdomain steht. Aus Sicht des endgültigen Empfängers passt der sendende Server dann möglicherweise nicht zur SPF-Erlaubnis der ursprünglichen Domain. | Ob die betroffenen Nachrichten direkt zugestellt oder über eine Weiterleitung transportiert wurden. Hilfreich ist die Frage, welcher Server die Nachricht zuletzt an den empfangenden Mailserver übergeben hat. | Weiterleitungsverhalten gesondert prüfen und nicht sofort den SPF-Eintrag der ursprünglichen Domain als falsch bewerten. Je nach Umgebung können auch andere Mechanismen und Weiterleitungsvarianten eine Rolle spielen. |
| E-Mails landen trotz gültigem SPF weiterhin im Spamordner. | SPF ist kein vollständiger Spamfilter und keine Garantie für Posteingangszustellung. Empfänger bewerten zusätzlich Inhalt, Versandvolumen, Reputation, Empfängerreaktionen, DKIM, DMARC und eigene Richtlinien. | Ob SPF tatsächlich besteht und ob andere Signale auffällig sind: fehlende Signaturen, neue Versandinfrastruktur, ungewöhnliche Inhalte, hohe Beschwerderaten oder inkonsistente Absenderangaben. | SPF als einen Baustein der Diagnose behandeln. Wenn der Eintrag technisch korrekt ist, sollte die weitere Zustellungsanalyse über Authentifizierung, Reputation und konkrete Empfängerreaktionen geführt werden. |
| Eine Nachricht zeigt im Postfach einen vertrauten Namen an, wirkt aber dennoch verdächtig oder stammt offensichtlich nicht vom erwarteten Absender. | SPF schützt nicht automatisch den sichtbaren Anzeigenamen im Von-Feld. Ein Angreifer kann einen Namen anzeigen lassen, während technische Domains, Rückpfade oder Signaturen eine andere Geschichte erzählen. | Welche technische Absenderdomain geprüft wurde und ob sichtbarer Name, Von-Adresse, Mail-From und gegebenenfalls DKIM/DMARC-Ausrichtung zusammenpassen. Der Anzeigename allein ist kein verlässliches Authentifizierungsmerkmal. | SPF nicht als vollständigen Phishing-Schutz verstehen. Für eine belastbarere Einordnung sollten technische Header, Domainausrichtung und ergänzende Mechanismen berücksichtigt werden. |
Die häufigste Fehlannahme besteht darin, SPF wie eine einfache Liste erlaubter Absenderadressen zu behandeln. Tatsächlich geht es um sendende Server und um die Domain, die bei der SPF-Prüfung relevant ist. Deshalb kann eine Konfiguration auf den ersten Blick richtig wirken, aber an der falschen Stelle ansetzen: etwa wenn nur die Hauptdomain gepflegt wird, während ein Newsletterdienst mit einer Subdomain arbeitet, oder wenn ein Webserver direkt sendet, obwohl der SPF-Eintrag nur den klassischen Mailprovider berücksichtigt.
Für eine sichere Prüfung sollten zunächst alle Versandwege gesammelt werden. Dazu gehören nicht nur persönliche Postfächer, sondern auch Formularversand, Shopsysteme, Buchhaltungssoftware, Ticketsysteme, Newsletterdienste, CRM-Plattformen und automatisierte Systemmeldungen. Erst wenn klar ist, welche Systeme wirklich im Namen welcher Domain senden, lässt sich beurteilen, ob der vorhandene SPF-Eintrag zu eng, zu weit, veraltet oder formal ungültig ist.
Änderungen am DNS sollten besonders vorsichtig behandelt werden, weil sie legitime Zustellung unmittelbar beeinflussen können. Ein falsch ergänztes Include, eine nicht mehr passende IP-Adresse oder eine unbedacht verschärfte Abschlussregel kann mehr Schaden verursachen als der ursprüngliche Warnhinweis. Sinnvoll ist daher ein kontrollierter Abgleich: verwendete Absenderdomain feststellen, aktuelle Anbieterangaben prüfen, vorhandene SPF-Bestandteile zuordnen und erst danach entscheiden, ob eine Anpassung nötig ist.
SPF, DKIM und DMARC richtig einordnen
SPF prüft erlaubte sendende Server. Der Mechanismus beantwortet also die Frage, ob der einliefernde Server nach den DNS-Angaben der Domain für den Versand vorgesehen ist. Er sagt nicht allein, ob der Inhalt unverändert ist oder ob die sichtbare Darstellung im Postfach vertrauenswürdig wirkt.
DKIM verfolgt einen anderen Ansatz. Dabei werden Nachrichtenbestandteile kryptografisch signiert, sodass empfangende Systeme die Signatur prüfen können. DKIM dreht sich damit nicht primär um die IP-Adresse des sendenden Servers, sondern um eine überprüfbare Signatur der Nachricht.
DMARC verbindet SPF und DKIM mit einer Richtlinie und Berichtsfunktion. Darüber kann eine Domain festlegen, wie Empfänger mit Nachrichten umgehen sollen, die die erwartete Authentifizierung und Ausrichtung nicht erfüllen. Außerdem können Berichte helfen, legitime und problematische Versandwege besser zu erkennen.
Diese Verfahren ergänzen sich, ersetzen einander aber nicht vollständig. SPF allein verhindert Phishing nicht vollständig, schützt nicht automatisch den sichtbaren Von-Namen und ist kein kompletter Spamfilter. Erst im Zusammenspiel aus korrekter Authentifizierung, sauberer Versandpraxis und Empfängerbewertung entsteht ein belastbareres Bild.
FAQ zu SPF
Was bedeutet SPF?
SPF steht für Sender Policy Framework. Es ist ein DNS-Eintrag, der beschreibt, welche Server berechtigt sind, E-Mails im Namen einer Domain zu versenden.
Wo wird SPF eingetragen?
SPF wird als TXT-Eintrag in der DNS-Zone der jeweiligen Domain eingetragen. Entscheidend ist die Domain, die im konkreten Versand technisch für die SPF-Prüfung verwendet wird.
Was ist ein TXT-Eintrag?
Ein TXT-Eintrag ist ein Textdatensatz im DNS. Andere Systeme können ihn abfragen. Bei SPF enthält dieser Text eine Regel, die erlaubte Versandquellen einer Domain beschreibt.
Warum darf es nur einen SPF-Eintrag geben?
Für eine Domain sollte normalerweise nur ein TXT-Eintrag mit v=spf1 vorhanden sein. Mehrere separate SPF-Einträge für dieselbe Domain führen häufig dazu, dass die SPF-Auswertung als ungültig behandelt wird. Benötigte Regeln müssen fachlich in einem gültigen Eintrag zusammengeführt werden.
Was bedeutet include?
include verweist auf die SPF-Regeln eines anderen Dienstes. Das wird häufig genutzt, wenn ein externer Mail-, Newsletter- oder Transaktionsmail-Dienst im Namen einer Domain sendet. Der konkrete Include-Wert muss aus der aktuellen Dokumentation des jeweiligen Dienstes stammen.
Was bedeutet -all oder ~all?
-all steht für eine strengere Bewertung nicht erlaubter Server. ~all steht für eine weichere Bewertung. Die praktische Wirkung hängt davon ab, wie empfangende Systeme SPF im Gesamtkontext auswerten. Vor einer Verschärfung sollte klar sein, dass alle legitimen Versandquellen erfasst sind.
Warum landen E-Mails trotz SPF im Spam?
SPF ist nur ein Authentifizierungsbaustein. Spamfilter berücksichtigen zusätzlich Inhalt, Reputation, Versandvolumen, Nutzerreaktionen, DKIM, DMARC und eigene Richtlinien der empfangenden Systeme. Ein bestandener SPF-Check ist deshalb keine Zustellgarantie.
Ist SPF dasselbe wie DKIM?
Nein. SPF prüft, ob ein sendender Server für eine Domain erlaubt ist. DKIM signiert Nachrichtenbestandteile kryptografisch, damit Empfänger die Signatur prüfen können. Beide Verfahren haben unterschiedliche Aufgaben und werden häufig zusammen mit DMARC betrachtet.
SPF ist ein wichtiger, aber begrenzter Baustein der E-Mail-Zustellung. Der Eintrag sagt empfangenden Mailservern, welche Systeme nach Vorgabe des Domaininhabers im Namen einer Domain senden dürfen. Dadurch wird die Absenderprüfung nachvollziehbarer, aber nicht jede Spam- oder Phishing-Situation automatisch verhindert.
Wer SPF-Probleme einordnet, sollte zuerst die verwendete Absenderdomain, alle tatsächlichen Versandwege und die aktuellen Angaben der beteiligten Anbieter prüfen. Besonders häufig sind mehrere SPF-Einträge, veraltete Includes, fehlende Drittversender, Subdomain-Lücken und Weiterleitungen. Zusammen mit DKIM und DMARC entsteht daraus ein deutlich vollständigeres Bild der technischen E-Mail-Authentifizierung.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten