Was ist SPF, und wie autorisiert es deine Sendeserver?

Wenn ein Server eine E-Mail empfängt, die vorgibt, von deiner 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 dich ausgeben. SPF – Sender Policy Framework, definiert durch die RFC 7208 – ist der erste Baustein, der eine Antwort liefert. Du veröffentlichst in deinem DNS die Liste der Server, die berechtigt sind, in deinem Namen 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 dein 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 deine-domain.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: Du bist der Einzige, der dein DNS kontrolliert, also bist du der Einzige, der dort offiziell die Liste deiner Sendeserver veröffentlichen kann. 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 dein 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@dein-unternehmen.de anzeigen und dabei einen Umschlag MAIL FROM: bounce@eine-andere-domain.com haben. SPF validiert dann eine-andere-domain.com, nicht dein-unternehmen.de. Genau das ist die Bresche, die ein Angreifer ausnutzt, und deshalb reicht SPF allein nie – wir kommen weiter unten darauf zurück. Merke dir schon jetzt diese Unterscheidung Umschlag ≠ sichtbares From:: 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 deiner Domain. Hier ein typisches Beispiel für ein Unternehmen, das über Google Workspace, SendGrid und einen hauseigenen Server versendet:

deine-domain.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, deinen E-Mailing-Dienstleister.
• ip4:203.0.113.10 – eine präzise IP, dein hauseigener 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: Dein Anbieter (Google, Microsoft 365, SendGrid, Mailchimp…) veröffentlicht sein SPF, und du importierst es. Du musst seine IPs, die sich ändern, nicht 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 deine eigenen Server, deren IP stabil ist.
• a – autorisiert die IPs, die in den A-Einträgen (oder AAAA) der Domain vorhanden sind. Praktisch, wenn dein Webserver auch Post versendet.
• mx – autorisiert die IPs deiner 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 deine Domain zu senden. Das ist das Äquivalent einer weit offenen Tür. Wenn du es irgendwo siehst, korrigiere es sofort.

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.

Rechne zusammen: Google Workspace verbraucht mehrere Lookups, dein Marketing-Dienstleister einige, dein Rechnungswerkzeug noch mehr, dein Kundensupport noch mehr… und du überschreitest die 10, ohne es zu merken. Darüber hinaus schickt der Empfänger einen permerror (dauerhafter Fehler) zurück: SPF scheitert vollständig, als existierte es nicht. Deine legitime Post kann dann als verdächtig markiert werden.

Die Falle ist heimtückisch, weil der Eintrag korrekt scheint und funktioniert, solange du unter der Latte bleibst – und dann fügst du eines Tages einen Dienstleister mehr hinzu, überschreitest die Grenze, 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 wenn du die Fehlermeldung selbst verstehen willst, nimmt was ein SPF-permerror ist sie Schritt für Schritt in die Hand.

Die Lösung heißt Abflachung (Flattening): Du ersetzt gierige include: durch die entsprechenden ip4:/ip6:-Blöcke, ein für alle Mal aufgelöst. Du sparst Lookups zum Preis einer Wartung: Wenn der Dienstleister seine IPs ändert, musst du neu 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. Wenn du einen zweiten veröffentlichst – oft indem du einen Dienstleister hinzufügst, ohne den bestehenden anzutasten –, schickt der Empfänger einen permerror zurück und beide werden ignoriert. Die Regel: Führe alles in einem einzigen Eintrag zusammen. 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.

Wenn du nicht weißt, in welchem Zustand deine Domain ist, rate nicht: prüfe deinen SPF-Eintrag in wenigen Sekunden. Und wenn du zwischen Microsoft 365 und Google Workspace jonglierst, wird der 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:

deine-domain.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 bist du schon bei der Hälfte des Budgets von 10 Lookups. Füge die Rechnungsstellung, das Marketing-E-Mailing und den Support hinzu, und der permerror lauert dir auf. 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

Komm 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 deine Domain im From: anzeigen, das dein 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:

1. SPF – autorisiert die sendenden IPs (auf der Umschlagseite).
2. 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.
3. 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.

Deine SPF-Roadmap

Um ein sauberes und dauerhaftes SPF zu setzen, gehe in dieser Reihenfolge vor:

1. Inventarisiere deine Absender. Liste alles, was in deinem Namen sendet: Messaging, Marketing, Rechnungsstellung, Support, interne Apps. Man vergisst immer welche – die DMARC-Berichte helfen, sie aufzuspüren.
2. Veröffentliche einen einzigen Eintrag, der mit v=spf1 beginnt, mit einem include: pro Dienstleister und einem ip4:/ip6: pro hauseigenem Server.
3. Zähle deine Lookups. Bleibe unter 10. Wenn du überschreitest, flache die gierigsten include ab.
4. Schließe mit -all ab, sobald du deines Inventars sicher bist (gehe über ~all, solange du validierst, wenn du die Vorsicht bevorzugst).
5. Veröffentliche niemals zwei Einträge noch +all.
6. Schließe mit DKIM, dann DMARC an – das ist der einzige Weg zu einem echten Schutz.

Du musst das alles nicht im Blindflug tun. Starte eine kostenlose und sofortige Überprüfung der SPF-, DKIM- und DMARC-Posture deiner Domain mit unserem kostenlosen DMARC-Analyzer: Er zeigt dir dein aktuelles SPF, zählt deine Lookups, erkennt die Duplikate und gibt dir eine klare Note. Und wenn du von der Überwachung zum realen Schutz übergehen willst, benennt Thomas, dein virtueller CISO, jeden Absender, generiert das exakte DNS zum Einfügen und sagt dir, wann zu verschärfen ist, ohne eine einzige legitime E-Mail zu brechen.

Analysiere deine Domain kostenlos → und sieh in wenigen Sekunden, wo dein SPF steht.