Was ist SPF? - Kurz erklärt
Ein SPF-Record (Sender Policy Framework) ist ein DNS-TXT-Eintrag, der festlegt, welche Mailserver in Deinem Namen E-Mails versenden dürfen. Fehlt er oder ist er fehlerhaft, können Angreifer E-Mails in Deinem Namen fälschen (Spoofing).
SPF ist der erste Baustein sicherer E-Mail-Authentifizierung. Er teilt empfangenden Mailservern mit: „Nur diese IP-Adressen und Hostnamen dürfen E-Mails von @meinedomain.de senden.”
Wie SPF funktioniert:
- Du sendest eine E-Mail von meinedomain.de
- Der empfangende Mailserver fragt den DNS-Server: „Wer darf für meinedomain.de senden?”
- DNS gibt Deinen SPF-Record zurück
- E-Mail-Header-IP wird gegen SPF-Record geprüft
- Ergebnis: Pass (erlaubt), SoftFail (~all), Fail (-all) oder None (kein SPF)
Was wir prüfen
Unser SPF-Check analysiert Deinen DNS-TXT-Record auf:
- Vorhanden? Gibt es überhaupt einen SPF-Record für Deine Domain?
- Syntax korrekt? Ist der Record syntaktisch gültig?
- Policy stark genug?
-all(hard fail) oder nur~all(soft fail)? - DNS-Lookup-Limit? SPF erlaubt maximal 10 DNS-Lookups - mehr und der Check bricht
- Duplikate? Mehrere SPF-Records in einer Domain ungültig
- Fehlende Includes? Microsoft 365, Google Workspace, Newsletter-Dienste eingebunden?
Häufige SPF-Fehler
1. Kein SPF-Record vorhanden
Ohne SPF kann jeder Server E-Mails in Deinem Namen versenden - und die meisten Empfänger-Server lassen diese durch. Einfachste Sicherheitslücke im E-Mail-Setup.
Fix: v=spf1 include:spf.protection.outlook.com -all (Beispiel für M365)
2. Soft Fail (~all) statt Hard Fail (-all)
~all bedeutet: verdächtige E-Mails kommen durch, werden aber als Spam markiert. p=reject in DMARC braucht zwingend -all in SPF für vollen Schutz.
Fix: -all am Ende Deines SPF-Records statt ~all
3. Mehr als 10 DNS-Lookups
SPF erlaubt pro Überprüfung maximal 10 Mechanismen, die DNS-Lookups auslösen (include, a, mx, ptr). Wer Microsoft 365 + Google + Mailchimp + Salesforce + noch 3 andere einbindet, überschreitet das schnell.
Fix: SPF-Flattening - DNS-Lookups durch explizite IP-Listen ersetzen (wird von Tools automatisiert)
4. Mehrere SPF-Records in einer Domain
Ungültig. Nur der erste wird gelesen, der Rest ignoriert - oder der Check schlägt komplett fehl.
Fix: Alle Mechanismen in einen einzigen v=spf1-Record zusammenfassen
5. Fehlende Includes für Drittanbieter
Microsoft 365, Google Workspace, HubSpot, Mailchimp, Salesforce - all diese Dienste senden E-Mails in Deinem Namen. Ohne Include scheitern ihre E-Mails am SPF-Check.
Gängige Includes:
- Microsoft 365:
include:spf.protection.outlook.com - Google Workspace:
include:_spf.google.com - Mailchimp:
include:servers.mcsv.net - HubSpot:
include:hubspotemail.net
SPF-Record richtig aufsetzen - Schritt für Schritt
Schritt 1 - Inventur: Wer sendet E-Mails für Dich? Alle Systeme und Dienste auflisten, die in Deinem Namen Mails versenden: primärer Mailserver, M365/Google, CRM, Newsletter-Tool, Transaktions-Mail-Dienst.
Schritt 2 - Includes sammeln Von jedem Dienst den offiziellen SPF-Include aus der Dokumentation holen.
Schritt 3 - SPF-Record schreiben
Format: v=spf1 include:spf.protection.outlook.com include:_spf.google.com ip4:1.2.3.4 -all
Schritt 4 - DNS-Lookup-Count prüfen Mit einem SPF-Checker (wie unserem) verifizieren, dass ≤10 DNS-Lookups benötigt werden.
Schritt 5 - Als DNS-TXT-Eintrag publizieren
Im DNS-Manager (bei Deinem Domain-/Hosting-Anbieter) als TXT-Record für @ oder Deine Root-Domain eintragen.
Schritt 6 - Überprüfen Check nochmals durchführen, E-Mail-Test mit Tools wie mail-tester.com.
SPF + DKIM + DMARC - das vollständige Trio
SPF allein schützt nicht vollständig. E-Mail-Sicherheit braucht drei Bausteine:
| Baustein | Prüft | Schützt vor |
|---|---|---|
| SPF | Absender-IP gegen DNS-Record | IP-Spoofing des Envelope-Senders |
| DKIM | Kryptografische Signatur im Header | Inhalts-Manipulation, Header-Spoofing |
| DMARC | Alignment von SPF/DKIM + Policy | Spoofing der sichtbaren From-Adresse |
Nur wer alle drei hat, ist gegen E-Mail-Spoofing wirklich geschützt.
→ DMARC-Check → Domain DMARC-Policy prüfen
Häufige Fragen zum SPF-Check
Was bedeutet ~all vs -all?
~all = SoftFail: E-Mails von nicht gelisteten Quellen werden angenommen, aber als verdächtig markiert. -all = HardFail: E-Mails von nicht gelisteten Quellen werden abgelehnt. Für maximalen Schutz: -all plus DMARC p=reject.
Wie viele DNS-Includes sind erlaubt? Maximal 10 DNS-Lookups (Mechanismen: include, a, mx, ptr). Mehr und der SPF-Check gibt einen PermError zurück - E-Mails scheitern am Check.
Brauche ich SPF, wenn ich Microsoft 365 nutze?
Ja. M365 hat einen eigenen SPF-Record für seine IPs - aber Deine Domain braucht trotzdem einen SPF-Record, der M365 als autorisierten Sender einbindet: include:spf.protection.outlook.com.
Was ist ein SPF-Record-Lookup-Flattening? Wenn Du zu viele Includes hast, ersetzt Flattening die DNS-Lookups durch explizite IP-Listen. Muss regelmäßig aktualisiert werden wenn Deine Anbieter IPs ändern.
Schützt SPF gegen Phishing? SPF schützt den Envelope-Sender (Return-Path), nicht die sichtbare From-Adresse im E-Mail-Client. Für vollständigen Spoofing-Schutz der From-Adresse braucht es zusätzlich DKIM + DMARC.
Was passiert, wenn kein SPF-Record vorhanden ist?
None-Ergebnis: der empfangende Server behandelt die Mail ohne SPF-Bewertung. Viele moderne Server gewichten Mails ohne SPF schlechter für den Spam-Filter.
Willst Du die komplette Angriffsfläche sehen?
SPF ist ein Modul von 15. Unser kostenloser Self-Check prüft zusätzlich: DKIM, DMARC, TLS, Certificate Transparency, Subdomain-Leaks, HaveIBeenPwned, Shodan-Exposure, GitHub-Exposure und 7 weitere Module.
→ Voller 15-Modul-Self-Check starten
Brauchst Du Beratung zur E-Mail-Security oder Compliance? → NIS2-Umsetzung · ISO 27001 · Kostenfreie Erstberatung
📞 +49 221 292 763 30 · info@seraph-it.de
Verwandte Themen
DMARC-Check · 15-Modul-Self-Check · NIS2 · E-Mail-Reputation verbessern