Was ist SPF? Syntax, ~all vs. -all und typische Fehler erklärt

SPF (Sender Policy Framework) ist die “Gästeliste” deiner Domain. Es ist ein DNS-Eintrag, der genau festlegt, welche Mailserver überhaupt in deinem Namen E-Mails versenden dürfen – und damit eine wichtige Grundlage für DMARC.

Warum ist SPF so wichtig?

Das ursprüngliche E-Mail-Protokoll (SMTP) hat einen grundlegenden Schwachpunkt: Es gibt keine eingebaute Absenderverifizierung. Jeder kann sich mit einem Server verbinden und behaupten, er sei chef@deine-firma.de. Spammer und Phisher nutzen das systematisch aus.

SPF löst dieses Problem durch einen DNS-Eintrag: Empfangende Mailserver (wie Gmail oder Microsoft 365) prüfen bei jeder eingehenden E-Mail, ob die IP-Adresse des absendenden Servers in der SPF-Liste deiner Domain steht. Steht sie dort nicht, ist die E-Mail verdächtig.

Ohne SPF kann ein Angreifer beliebige E-Mails mit deiner Absenderadresse versenden. Mit SPF sehen empfangende Server sofort: “Diese IP-Adresse ist nicht autorisiert – wahrscheinlich Spam oder Phishing.”

Wie sieht ein SPF-Record aus? Die Syntax erklärt

Ein SPF-Eintrag ist ein TXT-Record in deinen DNS-Einstellungen, angelegt direkt für deine Domain (oder eine Subdomain). Hier ein vollständiges Beispiel für eine Domain, die Google Workspace nutzt und einen eigenen Server betreibt:

Die wichtigsten Mechanismen im Detail

~all vs. -all: Der entscheidende Unterschied

Das all-Tag am Ende des SPF-Records ist eines der wichtigsten Elemente. Es definiert, was mit E-Mails passiert, die von keiner der explizit aufgeführten Quellen stammen:

Typische SPF-Konfigurationen für bekannte Anbieter

Wenn du mehrere Dienste nutzt, kombiniere sie in einem Record: v=spf1 include:_spf.google.com include:spf.strato.de ip4:1.2.3.4 ~all

Typische Fehler und wie du sie vermeidest

Fehler 1: Mehrere SPF-Records

Deine Domain darf nur einen einzigen TXT-Record haben, der mit v=spf1 beginnt. Wenn du zwei separate Einträge anlegst, schlägt die SPF-Prüfung bei vielen Empfängern fehl (PermError). Fasse alles in einem Record zusammen.

Fehler 2: Die 10-DNS-Lookup-Grenze überschreiten

SPF erlaubt maximal 10 DNS-Lookups bei der Auswertung. Jedes include:, a, mx und ptr zählt als ein Lookup. Wenn du viele externe Dienste (Newsletter, CRM, Support-Tool, Webshop) nutzt, ist dieses Limit schnell erreicht. Die Folge: SPF-Prüfung schlägt fehl (PermError).

Lösung: Nutze SPF-Flattening-Tools, die alle Include-Chains aufgelöst als direkte IP-Adressen in einen kompakten Record schreiben.

Fehler 3: SPF und DMARC-Alignment vergessen

SPF prüft den “MAIL FROM” (Envelope-Sender), der oft vom sichtbaren From:-Header abweicht. DMARC verlangt Alignment: Beide müssen übereinstimmen. Wenn dein Newsletter-Dienst über eine eigene Domain sendet, musst du entweder das Alignment anpassen oder DKIM konfigurieren, das die richtige Domain signiert.

SPF im Zusammenspiel mit DKIM und DMARC

SPF allein schützt nicht gegen alle Angriffsszenarien. Beim E-Mail-Forwarding (Weiterleitung) ändert sich die sendende IP-Adresse, wodurch SPF fehlschlägt – auch wenn die E-Mail legitim ist. Deshalb ergänzt DKIM SPF durch kryptografische Signaturen, die bei Weiterleitungen erhalten bleiben. Das übergeordnete DMARC-Protokoll wertet dann die Ergebnisse beider Tests gemeinsam aus.

Möchtest du alle drei Protokolle von Grund auf einrichten? Die Step-by-Step-Anleitung zur E-Mail-Authentifizierung führt dich durch den gesamten Prozess.

SPF und die Google/Yahoo Sender-Anforderungen

Seit Februar 2024 verlangen Google (Gmail) und Yahoo für alle Absender, die mehr als 5.000 E-Mails täglich senden, zwingend einen gültigen SPF-Record sowie DKIM und DMARC. Domains ohne diese Konfiguration riskieren, dass ihre E-Mails abgewiesen oder direkt im Spam landen.

Aber auch für kleinere Absender gilt: Fehlende oder fehlerhafte SPF-Records sind eines der häufigsten Ursachen für E-Mails, die nicht zugestellt werden oder im Spam landen. Ein korrekt konfigurierter SPF-Record ist die absolute Mindestanforderung für jede Domain, die E-Mails sendet.

Wie prüfe ich meinen SPF-Record?

Nach dem Anlegen oder Ändern eines SPF-Records ist es wichtig, ihn direkt zu testen. Öffentliche DNS-Resolver cachen Einträge für die Dauer des TTL-Werts – was bedeutet, dass ein normales Lookup-Tool möglicherweise noch den alten Record anzeigt.

Unser DMARC-Checker fragt direkt am autoritativen Nameserver ab und zeigt dir sofort das aktuelle Ergebnis – ideal für schnelles Debugging nach DNS-Änderungen. Neben dem reinen Record-Text analysiert der Checker auch, ob die Syntax korrekt ist, wie viele DNS-Lookups verbraucht werden, und ob ein DMARC-Alignment-Problem vorliegen könnte.