Was ist SPF, und wie autorisiert es die Sendeserver einer Domain?

Von Thomas · virtueller CISO · 2026-06-14

Wenn ein Server eine E-Mail empfängt, die vorgibt, von einer bestimmten Domain zu stammen, stellt er sich eine sehr einfache Frage: Hat die IP, die mir diese Nachricht schickt, das Recht, für diese Domain zu senden? Ohne Antwort kann sich jeder für den Inhaber ausgeben. SPF – Sender Policy Framework, definiert durch die RFC 7208 – ist der erste Baustein, der eine Antwort liefert. Im DNS wird die Liste der Server veröffentlicht, die berechtigt sind, im Namen der Domain zu senden, und der Empfänger vergleicht. Dieser Leitfaden erklärt, was SPF ist, wie der Eintrag aussieht, was die Mechanismen bedeuten, die berüchtigte Falle der 10 Lookups und warum SPF allein nicht schützt, was der Empfänger wirklich sieht.

Das Problem, das SPF löst

Ursprünglich prüft das E-Mail-Protokoll nichts. Jeder beliebige Server, irgendwo im Internet, kann eine Verbindung öffnen und erklären „ich trage Post von beispiel.de". Nichts hindert ihn daran, und nichts warnt den Empfänger. Dieses Fehlen einer Kontrolle hat Spam und Usurpation jahrelang trivial gemacht.

SPF schließt einen Teil dieser Lücke mit einer ganz einfachen Idee: Nur der Inhaber kontrolliert das DNS seiner Domain, also kann auch nur er dort offiziell die Liste seiner Sendeserver veröffentlichen. Der Empfänger liest diese Liste und prüft, dass die IP gegenüber dort auftaucht. Wenn ja, besteht SPF; wenn nein, scheitert SPF und die Nachricht wird verdächtig.

Was SPF wirklich ist – und was es genau prüft

Ein Detail ist entscheidend und wird fast immer missverstanden: SPF prüft nicht die From:-Adresse, die der Nutzer in seinem Mail-Client liest. Es prüft den Umschlag der Nachricht – technisch das MAIL FROM der SMTP-Sitzung, auch Return-Path genannt. Das ist die Adresse, an die die Rückläufer zurückkehren, und sie ist oft eine andere als das sichtbare From:.

Konkret: Eine E-Mail kann From: buchhaltung@beispiel-unternehmen.de anzeigen und dabei einen Umschlag MAIL FROM: bounce@eine-andere-domain.com haben. SPF validiert dann eine-andere-domain.com, nicht beispiel-unternehmen.de. Genau das ist die Bresche, die ein Angreifer ausnutzt, und deshalb reicht SPF allein nie – wir kommen weiter unten darauf zurück. Diese Unterscheidung Umschlag ≠ sichtbares From: ist schon jetzt zu merken: Sie erklärt die Hälfte der Missverständnisse über die E-Mail-Authentifizierung.

Wie ein SPF-Eintrag aussieht

SPF ist ein einziger TXT-Eintrag, veröffentlicht an der Wurzel der Domain. Hier ein typisches Beispiel für ein Unternehmen, das über Google Workspace, SendGrid und einen hauseigenen Server versendet:

beispiel.de.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

Zerlegen wir ihn:

v=spf1 – die Version. Jeder SPF-Eintrag beginnt damit; so erkennt ihn der Empfänger.
include:_spf.google.com – delegiert an Google: „jeder Server, den Google für diese Subdomain als autorisiert erklärt, ist es auch für mich".
include:sendgrid.net – dasselbe für SendGrid, den E-Mailing-Dienstleister.
ip4:203.0.113.10 – eine präzise IP, der hauseigene Server, fest autorisiert.
-all – der abschließende Qualifikator: alles, was oben nicht gelistet ist, wird strikt abgelehnt.

Ein einziger Eintrag, eine einzige Zeile (auch wenn man sie zur Lesbarkeit auf mehrere darstellt). Das ist schon die erste Falle: es darf nur einen geben – wir kommen darauf zurück.

Die Mechanismen, einer nach dem anderen

Das Innere eines SPF-Eintrags ist eine Folge von Mechanismen, die der Empfänger von links nach rechts auswertet, bis er eine Übereinstimmung findet:

include: – delegiert die Autorisierung an eine andere Domain. Das ist der gängigste Mechanismus: Der Anbieter (Google, Microsoft 365, SendGrid, Mailchimp…) veröffentlicht sein SPF, das dann importiert wird. Seine IPs, die sich ändern, muss niemand kennen: Er hält sie aktuell.
ip4: / ip6: – autorisiert eine präzise IP-Adresse oder einen ganzen Block (z. B. ip4:203.0.113.0/24). Ideal für die eigenen Server, deren IP stabil ist.
a – autorisiert die IPs, die in den A-Einträgen (oder AAAA) der Domain vorhanden sind. Praktisch, wenn der Webserver auch Post versendet.
mx – autorisiert die IPs der eingehenden Mailserver (die MX-Einträge). Nützlich, wenn dieselbe Maschine empfängt und sendet.
der abschließende Qualifikator all – das Sicherheitsnetz, das über das Schicksal von allem Übrigen entscheidet.

Jeder Mechanismus kann einen Qualifikator tragen: + (autorisiert, Standard), - (lehnt ab), ~ (Softfail), ? (neutral). In der Praxis sieht man ihn nur bei all, und die Wahl dort ist entscheidend:

-all (strikter Fail) – alles, was nicht gelistet ist, wird abgelehnt. Das ist das richtige Ziel: eine klare und verteidigbare Posture.
~all (Softfail) – „wahrscheinlich nicht legitim, aber durchlassen und markieren". Nützlich in der Ausroll-Phase, solange man alles inventarisiert.
?all (neutral) – keine Meinung. Genauso gut nichts veröffentlichen; das schützt nicht.
+all – NIEMALS veröffentlichen. Das autorisiert die ganze Welt, für die Domain zu senden. Das ist das Äquivalent einer weit offenen Tür. Wo es auftaucht, ist es sofort zu korrigieren.

Für das Detail jedes Qualifikators und der Grenzfälle haben wir einen eigenen Leitfaden geschrieben: den all-Mechanismus in SPF verstehen.

Die Falle der 10 DNS-Lookups

Hier ist der häufigste Fehler, und der heimtückischste, weil er stumm ist. Die RFC 7208 schreibt vor, dass die Auswertung eines SPF-Eintrags nicht mehr als 10 DNS-Auflösungen auslösen darf. Jedes include:, jedes a, jedes mx zählt für mindestens eine Auflösung – und ein include kann selbst weitere enthalten, in Kaskade.

Die Rechnung geht schnell auf: Google Workspace verbraucht mehrere Lookups, der Marketing-Dienstleister einige, das Rechnungswerkzeug noch mehr, der Kundensupport noch mehr… und die 10 sind überschritten, ohne dass es jemand merkt. Darüber hinaus schickt der Empfänger einen permerror (dauerhafter Fehler) zurück: SPF scheitert vollständig, als existierte es nicht. Die legitime Post kann dann als verdächtig markiert werden.

Die Falle ist heimtückisch, weil der Eintrag korrekt scheint und funktioniert, solange man unter der Latte bleibt – und dann kommt eines Tages ein Dienstleister mehr hinzu, die Grenze fällt, und alles bricht auf einen Schlag zusammen, ohne sichtbare Fehlermeldung. Wir behandeln die Diagnose und die Ursachen in SPF: zu viele DNS-Lookups im Detail, und wer die Fehlermeldung selbst verstehen will, findet in was ein SPF-permerror ist eine Erklärung Schritt für Schritt.

Die Lösung heißt Abflachung (Flattening): Gierige include: werden durch die entsprechenden ip4:/ip6:-Blöcke ersetzt, ein für alle Mal aufgelöst. Das spart Lookups zum Preis einer Wartung: Ändert der Dienstleister seine IPs, ist neu zu generieren. Das ist ein zu handhabender Kompromiss, im Detail erklärt in unserem Leitfaden zur Abflachung eines SPF-Eintrags.

Die häufigen Fallen jenseits der Lookups

Zwei weitere Fehler brechen SPF unauffällig:

Zwei SPF-Einträge auf derselben Domain. Die RFC ist eindeutig: Es darf nur einen einzigen TXT-Eintrag geben, der mit v=spf1 beginnt. Wird ein zweiter veröffentlicht – oft, indem ein Dienstleister hinzugefügt wird, ohne den bestehenden anzutasten –, schickt der Empfänger einen permerror zurück und beide werden ignoriert. Die Regel: alles in einem einzigen Eintrag zusammenführen. Zwei zusätzliche include gehören in die bestehende Zeile, nicht in eine neue.
+all aus Versehen. Wir haben es gesagt, aber es verdient Wiederholung: Das ist die schlimmstmögliche Konfiguration. Ein +all (oder ein all ohne einschränkenden Qualifikator in manchen Lesarten) kommt dem gleich, keinerlei Schutz zu haben.

Bleibt der Zustand einer Domain unklar, ist Raten der falsche Reflex: den SPF-Eintrag prüfen dauert wenige Sekunden. Und wer zwischen Microsoft 365 und Google Workspace jongliert, findet den Sonderfall des Nebeneinanders der beiden include in SPF für Microsoft 365 und Google Workspace behandelt.

Ein konkreter Fall: Microsoft 365 und Google Workspace

Nehmen wir eine sehr häufige Situation. Ein Unternehmen migriert von Microsoft 365 zu Google Workspace, hält aber vorübergehend beide aktiv. Der Eintrag wird:

beispiel.de.  IN TXT
  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Jedes der beiden include löst mehrere DNS-Auflösungen aus. Mit zwei großen Dienstleistern ist schon die Hälfte des Budgets von 10 Lookups aufgebraucht. Kommen Rechnungsstellung, Marketing-E-Mailing und Support hinzu, lauert der permerror bereits. Das ist das typische Szenario, in dem die Abflachung eines der beiden include nötig wird – und in dem man ganz konkret versteht, warum die SPF-Lookup-Grenze es verdient, im Auge behalten zu werden, bevor sie zubeißt.

Warum SPF allein nicht ausreicht

Zurück zur Unterscheidung vom Anfang: SPF validiert den Umschlag (MAIL FROM / Return-Path), nicht das sichtbare From:. Ein Angreifer kann also ein perfektes SPF für seine eigene Domain einrichten, die Kontrolle problemlos passieren und die fremde Domain im From: anzeigen, das der Korrespondent liest. SPF sieht davon nichts: Es hat diese Adresse nie angeschaut.

Das ist eine strukturelle Grenze, kein Bug. SPF tut genau das, wofür es entworfen wurde – prüfen, wer das Recht hat, von einer gegebenen IP für eine Umschlag-Domain zu senden. Es sagt nichts über die Kohärenz zwischen dem Umschlag und dem angezeigten From:. Diese Kohärenz nennt man die Ausrichtung (Alignment), und DMARC ist es, das sie verlangt.

Das vollständige Trio funktioniert so:

SPF – autorisiert die sendenden IPs (auf der Umschlagseite).
DKIM – hängt eine kryptografische Signatur an die Nachricht, die beweist, dass sie nicht verändert wurde und tatsächlich von einer bestimmten Domain stammt.
DMARC – verknüpft SPF und DKIM mit dem sichtbaren From: und verlangt die Ausrichtung, dann sagt es dem Empfänger, was im Fehlerfall zu tun ist (none, quarantine, reject).

Mit anderen Worten, SPF ist nötig, aber nicht ausreichend. Es ist das Fundament; DKIM fügt den Integritätsbeweis hinzu; DMARC setzt das Dach auf, das endlich die Adresse schützt, die der Mensch liest. Ein gutes SPF ohne DMARC zu veröffentlichen heißt, ein Fenster zu verriegeln und die Tür offen zu lassen.

Die SPF-Roadmap

Um ein sauberes und dauerhaftes SPF zu setzen, empfiehlt sich diese Reihenfolge:

Die Absender inventarisieren. Alles auflisten, was im Namen der Domain sendet: Messaging, Marketing, Rechnungsstellung, Support, interne Apps. Man vergisst immer welche – die DMARC-Berichte helfen, sie aufzuspüren.
Einen einzigen Eintrag veröffentlichen, der mit v=spf1 beginnt, mit einem include: pro Dienstleister und einem ip4:/ip6: pro hauseigenem Server.
Die Lookups zählen. Unter 10 bleiben. Bei Überschreitung sind die gierigsten include abzuflachen.
Mit -all abschließen, sobald das Inventar sicher steht (der vorsichtige Weg führt über ~all, solange noch validiert wird).
Niemals zwei Einträge veröffentlichen und nie +all.
Mit DKIM, dann DMARC anschließen – das ist der einzige Weg zu einem echten Schutz.

Nichts davon muss im Blindflug geschehen. Eine kostenlose und sofortige Überprüfung der SPF-, DKIM- und DMARC-Posture einer Domain läuft über unseren kostenlosen DMARC-Analyzer: Er zeigt das aktuelle SPF, zählt die Lookups, erkennt die Duplikate und gibt eine klare Note. Und für den Übergang von der Überwachung zum realen Schutz benennt Thomas, der virtuelle CISO, jeden Absender, generiert das exakte DNS zum Einfügen und nennt den Moment, um zu verschärfen, ohne eine einzige legitime E-Mail zu brechen.

Eine Domain kostenlos analysieren und in wenigen Sekunden sehen, wo das SPF steht.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos