Werkzeug

SPF-Check

Sehen Sie sofort, ob Ihr SPF-Record syntaktisch korrekt ist und unter dem 10-Lookup-Limit bleibt.

Permalink: ?domain=… funktioniert auch.

Was ist SPF?

SPF (Sender Policy Framework) ist der älteste der drei E-Mail-Authentifizierungs-Standards und beantwortet eine einzige Frage: welche Server dürfen im Namen Ihrer Domain Mails versenden? Der Mechanismus ist denkbar einfach — ein TXT-Record auf der Domain listet erlaubte IPs, IP-Ranges oder Verweise auf andere SPF-Records (Includes) auf, und schließt mit einer All-Direktive, die festlegt, was mit nicht aufgelisteten Sendern geschehen soll.

Empfangende Server prüfen bei jeder Mail die Return-Path-Domain (Envelope-From) gegen den dort gefundenen SPF-Record. Stammt die sendende IP nicht aus der erlaubten Liste, greift die All-Direktive: -all bedeutet Hardfail (ablehnen), ~all Softfail (verdächtig markieren), ?all neutral, +all alles erlaubt — letzteres macht den Record praktisch wertlos.

Die wichtigste technische Grenze ist das 10-DNS-Lookup-Limit aus RFC 7208: jedes include:, a:, mx:, ptr: und exists: zählt als Lookup. Wer über 10 kommt, scheitert mit PermError, und SPF gilt als nicht ausgewertet — gefährlich, weil DMARC dann ebenfalls scheitert. Bei vielen Marketing- und CRM-Tools wird dieses Limit schnell gerissen.

Tiefer eintauchen → Was ist SPF?

Typische Fehler bei SPF

  1. Mehrere SPF-Records auf einer Domain

    RFC erlaubt genau einen TXT mit v=spf1. Zwei Records → PermError, Empfänger ignorieren beide. Häufig nach Provider-Wechsel oder Übernahme — alten Record entfernen, alle Includes in einen konsolidieren.

  2. 10-Lookup-Limit überschritten

    Jedes include:, a:, mx: zählt — auch transitiv. Marketing-Tool, CRM, Ticketing, Newsletter-Service: schnell bei 12 Lookups. Resultat: PermError, SPF gilt als fehlgeschlagen, DMARC scheitert mit.

  3. Soft-Fail (~all) statt Hard-Fail (-all)

    Softfail markiert verdächtige Mails nur, lehnt sie aber nicht ab. Für ernsthaften Anti-Spoofing-Schutz ist -all nötig. ~all nur als Übergangsstufe sinnvoll, nicht als Endzustand.

  4. Vergessene neue Sender-IPs

    Neuer Versand-Provider angeschafft, SPF nicht aktualisiert: dessen Mails landen im Spam. SPF muss bei jeder Provider-Änderung mitgepflegt werden — am besten als Inventar-Liste in der IT.

  5. include: ohne Subdomain-Berücksichtigung

    SPF gilt nur für die exakte Domain, nicht für Subdomains. news.example.com braucht eigenen SPF-Record — sonst gilt sie als nicht autorisiert, sobald Empfänger danach fragen.

  6. redirect= falsch eingesetzt

    redirect= ersetzt den ganzen Record, wirkt nur, wenn keine eigenen Mechanismen davor stehen. include: hingegen ergänzt. Verwechslung führt zu nicht-erwartetem Verhalten — fast immer ist include: die richtige Wahl.

  7. Veraltete Includes (alte ESPs)

    Mailchimp, Sendgrid, Mailgun — alle haben in den letzten Jahren ihre Include-Hosts geändert. Wer den alten include: nicht ersetzt, hat tote Verweise im Record und verschwendet Lookups.

Probleme beheben — in 4 Schritten

Auf einen Record konsolidieren

Alle v=spf1-Einträge zusammenführen, alten Record entfernen. Das DNS-Tool muss exakt einen TXT mit v=spf1 zurückgeben — alles andere ist ein Konfigurationsfehler.

@ IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Includes flachklopfen / SPF-Macros

Lookup-Zähler online prüfen. Wenn über 10: nicht genutzte Includes streichen, oder einen Flattening-Service nutzen, der include: durch konkrete IP-Ranges ersetzt — mit automatischer Aktualisierung bei Provider-Änderungen.

-all setzen

Sobald Sie sicher sind, dass alle legitimen Sender im Record stehen: ~all durch -all ersetzen. Empfänger lehnen jetzt jede nicht autorisierte Mail strikt ab.

@ IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DMARC für Sichtbarkeit

SPF allein zeigt nicht, wer gegen die Policy verstößt. Mit DMARC p=none + rua=mailto:… bekommen Sie tägliche Reports über Pass/Fail pro IP — die Datengrundlage für jede SPF-Optimierung.

Wollen Sie alle 8 Standards prüfen?

Der vollständige SelfCheck testet zusätzlich SPF/DKIM/DMARC, BIMI, MTA-STS, TLS-RPT, DNSSEC und MX in einem Durchgang.

Vollständigen SelfCheck starten →

Häufige Fragen zu SPF

Was zählt als DNS-Lookup?
Jedes include:, a:, mx:, ptr: und exists: zählt als DNS-Lookup. SPF erlaubt maximal 10 Lookups pro Auswertung — danach liefert der Empfänger PermError und behandelt SPF als fehlgeschlagen.
Was ist sicherer: -all oder ~all?
-all (Hardfail) ist strenger und weist Empfänger an, nicht autorisierte Mails abzulehnen. ~all (Softfail) markiert sie nur als verdächtig. Für produktive Domains ist -all die richtige Wahl, sobald die Sender-Liste vollständig ist.
Kann ich mehrere SPF-Records haben?
Nein. RFC 7208 erlaubt genau einen TXT-Record mit v=spf1 pro Domain. Zwei Records führen zu PermError; Empfänger ignorieren beide. Konsolidieren Sie alle Includes in einen einzigen Record.
Was ist SPF-Flattening?
Flattening ersetzt include:-Verweise durch die tatsächlichen IP-Bereiche, um unter dem 10-Lookup-Limit zu bleiben. Vorsicht: bei Provider-IP-Wechseln müssen Sie den Record manuell aktualisieren — automatisierte Flattening-Dienste sind dafür sinnvoll.
Wie teste ich SPF risikofrei?
Setzen Sie SPF zunächst mit ~all (Softfail), aktivieren Sie DMARC mit p=none + rua, und werten Sie die Aggregat-Reports 1–2 Wochen aus. Wenn alle legitimen Quellen aligned sind, schalten Sie auf -all um.
—