SPF (Sender Policy Framework): Autorisierte Sender per DNS definieren
SPF definiert per DNS-TXT-Record, welche Server E-Mails für Ihre Domain senden dürfen — die erste Verteidigungslinie gegen Domain-Spoofing. Dieser Guide erklärt Mechanismen, Qualifier, das 10-Lookup-Limit und liefert Provider-spezifische Anleitungen für 9 Provider.
Warum SPF unverzichtbar ist
Sender Policy Framework (SPF) ist ein DNS-basiertes Authentifizierungsverfahren nach RFC 7208, das per TXT-Record festlegt, welche Server E-Mails im Namen Ihrer Domain versenden dürfen — und damit die erste Verteidigungslinie gegen Domain-Spoofing und Business Email Compromise (BEC). Ohne SPF kann jeder beliebige Server E-Mails versenden, die aussehen, als kämen sie von Ihrer Domain. Empfangende Mailserver haben dann keine Möglichkeit, legitime von gefälschten E-Mails zu unterscheiden. Der Wolf-Agents Email Security Check prüft Ihre SPF-Konfiguration auf 22 Einzelkriterien und zeigt konkret, wo Handlungsbedarf besteht.
SPF ist mit 22 von 165 Punkten einer der gewichtigsten Faktoren im Wolf-Agents Email Security Check. Die Implementierung dauert wenige Minuten — ein einzelner DNS-TXT-Record genügt. Trotzdem fehlt bei vielen Unternehmen im DACH-Raum ein korrekt konfigurierter SPF-Record oder das 10-Lookup-Limit ist überschritten.
Dieser Guide erklärt die SPF-Syntax im Detail, zeigt die häufigsten Fehler und liefert Provider-spezifische Anleitungen für Microsoft 365, Google Workspace und 7 weitere Provider.
Wie SPF funktioniert: DNS-Abfrage in Echtzeit
SPF funktioniert wie eine Gästeliste bei einer Veranstaltung: Der empfangende Mailserver (Türsteher) prüft bei jeder eingehenden E-Mail den DNS-TXT-Record der Absender-Domain (Gästeliste), ob die IP-Adresse des sendenden Servers (Gast) autorisiert ist. Steht der Server nicht auf der Liste, wird die E-Mail je nach SPF-Policy abgewiesen oder als verdächtig markiert.
Ohne SPF
- Jeder Server weltweit kann E-Mails als Ihre Domain versenden
- Phishing-Angriffe im Namen Ihres Unternehmens bleiben unerkannt
- Empfangende Mailserver können legitime von gefälschten Mails nicht unterscheiden
- Ihre Domain-Reputation leidet durch Missbrauch Dritter
Mit SPF
- Nur autorisierte Server bestehen die SPF-Prüfung
- Domain-Spoofing wird bei Hard Fail (-all) automatisch blockiert
- Grundlage für DMARC-Alignment und vollständige E-Mail-Authentifizierung
- Nachweisbare Compliance-Maßnahme für NIS2, DSGVO und BSI TR-03182
SPF-Prüfung: Schritt für Schritt
SPF-Syntax: Mechanismen und Qualifier
Ein SPF-Record besteht aus der Version v=spf1, einer Reihe von Mechanismen, die autorisierte Server definieren, und einem abschließenden Qualifier, der das Verhalten für nicht autorisierte Server festlegt. Mechanismen werden der Reihe nach ausgewertet — der erste Treffer entscheidet. Jeder Mechanismus verbraucht null oder einen DNS-Lookup.
SPF-Mechanismen
| Mechanismus | Bedeutung | Lookup | Beispiel |
|---|---|---|---|
ip4: | IPv4-Adresse oder CIDR-Bereich | Nein | ip4:203.0.113.0/24 |
ip6: | IPv6-Adresse oder Präfix | Nein | ip6:2001:db8::/32 |
a | A-Record der Domain | Ja | a:mail.example.com |
mx | MX-Records der Domain | Ja | mx |
include: | SPF-Record einer anderen Domain einbinden | Ja | include:_spf.google.com |
exists: | Prüft ob A-Record existiert (für Makros) | Ja | exists:%{i}.%{d}._spf.example.com |
redirect= | SPF an andere Domain delegieren | Ja | redirect=_spf.example.com |
Qualifier für den all-Mechanismus
| Qualifier | Syntax | Bedeutung | Bewertung |
|---|---|---|---|
| Hard Fail | -all | Ablehnen — Server nicht autorisiert | Optimal |
| Soft Fail | ~all | Verdächtig markieren, aber zustellen | Akzeptabel |
| Neutral | ?all | Keine Aussage — wie kein SPF | Unzureichend |
| Pass | +all | Jeden Server erlauben | Kritisch |
-all (Hard Fail). Das 10-Lookup-Limit: Der häufigste SPF-Fehler
RFC 7208 § 4.6.4 begrenzt die Anzahl der DNS-Lookups während einer SPF-Auswertung auf maximal 10. Wird dieses Limit überschritten, liefert SPF einen PermError — empfangende Server behandeln das wie keinen SPF-Record. Mechanismen wie include:, a, mx und redirect verbrauchen je einen Lookup. Entscheidend: Verschachtelte Includes addieren sich. Ein einziger include: kann intern 7-9 weitere Lookups auslösen. Cross-Layer-Kontext: DNSSEC + DANE erhöhen die DNS-Lookup-Last pro Mail-Übertragung (DNSKEY-, DS-, RRSIG-, TLSA-Lookups) zusätzlich — Details und Pattern siehe DNS-Sicherheit-Kapitel-Sektion 6 „DNS-Lookup-Budget-Cross-Reference“ und MX-Infrastruktur-Kapitel-Sektion „MX-Lookup-Budget“.
Was zählt als Lookup?
Zählt als Lookup
include:amxptrexists:redirect=
Zählt NICHT
ip4:ip6:allv=spf1
Praxisfall: BMW.de mit 14 Lookups
BMW hatte zeitweise 14 DNS-Lookups in ihrem SPF-Record — weit über dem Limit von 10. Das Ergebnis: SPF PermError, was die E-Mail-Zustellbarkeit beeinträchtigte und im Wolf-Agents Scanner maximal eine Note D ergäbe. Das organisatorische Problem: Jede Abteilung fügt eigenständig ihren Dienst hinzu — Marketing bucht Mailchimp (2-3 Lookups), Vertrieb braucht HubSpot (7-9 Lookups), Support nutzt Freshdesk (7-8 Lookups).
3 Strategien gegen das Lookup-Limit
Subdomain-Delegation
EmpfohlenJede Subdomain erhält ein eigenes 10-Lookup-Budget. Isolation, Übersicht und DMARC-kompatibel mit aspf=r.
SPF Flattening
ÜbergangsweiseIncludes durch aufgelöste IP-Adressen ersetzen. 0 Lookups, aber IP-Monitoring nötig — Änderungen bei Providern werden verpasst.
SPF-Makros
Für ExpertenDer exists:-Mechanismus verbraucht nur 1 Lookup — unabhängig von der Anzahl autorisierter IPs. Erfordert DNS-API-Zugriff.
SPF als Compliance-Anforderung
SPF gehört zum „Stand der Technik“ bei der E-Mail-Authentifizierung und wird von mehreren Regulierungen direkt oder indirekt gefordert. Für NIS2-pflichtige Unternehmen ist ein korrekt konfigurierter SPF-Record ein nachweisbarer Baustein der geforderten Cybersicherheitsmaßnahmen.
NIS2 Art. 21
SPF ist eine direkte technische Maßnahme gegen E-Mail-Spoofing im Sinne der Kommunikationssicherheit. Die Geschäftsleitung haftet persönlich nach §38 BSIG — das Fehlen von SPF kann im Schadensfall als grobe Fahrlässigkeit gewertet werden.
DSGVO Art. 32
„Geeignete technische Maßnahmen“ zum Schutz personenbezogener Daten — SPF verhindert, dass Angreifer per Domain-Spoofing personenbezogene Daten abgreifen.
BSI TR-03182
Die BSI Technische Richtlinie für E-Mail-Authentifizierung fordert SPF als Pflichtmaßnahme. Ein SPF-Record mit Hard Fail (-all) ist Mindestanforderung.
SPF adressiert konkrete Bedrohungen: Email-Spoofing (BSI Lagebericht 2025: 950 angezeigte Ransomware-Vorfälle 1.7.2024–30.6.2025, 80 % betreffen KMU) und Phishing (Verizon DBIR 2025: 16 % aller Initial-Access-Vektoren). Vertiefung im Bedrohungs-Cluster.
Der Wolf-Agents Email Security Check prüft alle 165 Kriterien — kostenlos und ohne Registrierung. Das Monitoring überwacht Ihre SPF-Konfiguration alle 6 Stunden und alarmiert bei Änderungen.
SPF-Anleitung für Ihren Provider:
Wie steht Ihre Domain bei SPF?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.
Häufig gestellte Fragen
Was ist SPF (Sender Policy Framework)?
SPF ist ein DNS-basiertes Authentifizierungsverfahren nach RFC 7208, das per TXT-Record festlegt, welche Server E-Mails im Namen Ihrer Domain versenden dürfen. Empfangende Mailserver prüfen bei jeder eingehenden E-Mail, ob die IP-Adresse des sendenden Servers im SPF-Record der Absender-Domain autorisiert ist. SPF ist die erste Verteidigungslinie gegen Domain-Spoofing und bildet zusammen mit DKIM und DMARC das Fundament der E-Mail-Authentifizierung.
Was ist das 10-Lookup-Limit und warum ist es ein Problem?
RFC 7208 begrenzt die Anzahl der DNS-Lookups während einer SPF-Auswertung auf maximal 10. Mechanismen wie include:, a, mx und redirect verbrauchen je einen Lookup — verschachtelte Includes addieren sich. Wird das Limit überschritten, liefert SPF einen PermError und die Authentifizierung schlägt fehl. Dienste wie HubSpot verbrauchen allein 7-9 Lookups. Lösungen sind Subdomain-Delegation, SPF-Flattening oder SPF-Makros.
Was ist der Unterschied zwischen Hard Fail (-all) und Soft Fail (~all)?
Hard Fail (-all) weist empfangende Server an, E-Mails von nicht autorisierten Servern abzulehnen. Soft Fail (~all) markiert sie als verdächtig, stellt sie aber zu. Im Dauerbetrieb ist -all Pflicht — ~all ist nur als Übergangslösung bei der Ersteinrichtung gedacht. Der Wolf-Agents Email Security Check bewertet -all als optimal und ~all als akzeptabel, aber verbesserungswürdig.
Reicht SPF allein zum Schutz vor E-Mail-Spoofing?
SPF allein schützt nicht ausreichend, weil es nur die Envelope-From-Adresse prüft — nicht die sichtbare From-Adresse im E-Mail-Client. Ein Angreifer kann die From-Adresse fälschen, obwohl SPF die Envelope-From korrekt validiert. Erst DMARC verknüpft SPF (und DKIM) mit der sichtbaren Absenderadresse durch das sogenannte Alignment. Ohne DMARC mit p=reject bleibt Domain-Spoofing möglich.
Beeinflusst SPF die E-Mail-Zustellung bei Weiterleitungen?
Ja, SPF bricht bei klassischer E-Mail-Weiterleitung. Wenn Server B eine E-Mail von Server A an Server C weiterleitet, prüft Server C die IP von Server B gegen den SPF-Record der Absender-Domain — die Prüfung schlägt fehl, weil Server B nicht autorisiert ist. SRS (Sender Rewriting Scheme) löst dieses Problem, indem es die Envelope-From bei Weiterleitung umschreibt. DKIM übersteht Weiterleitungen unbeschadet.
Wie teste ich meinen SPF-Record?
Prüfen Sie Ihren SPF-Record mit dig TXT ihre-domain.de auf Linux/macOS oder nslookup -type=TXT ihre-domain.de unter Windows. Tools wie der dmarcian SPF Surveyor visualisieren die Lookup-Kette und zählen DNS-Lookups. Der Wolf-Agents Email Security Check prüft SPF auf 22 Einzelkriterien — kostenlos und ohne Registrierung unter /tools/email-security-check.