SPF-Record im DNS verständlich erklärt: Spam-Schutz
Das Sender Policy Framework (SPF) ist ein wichtiges E-Mail-Authentifizierungsverfahren, das als TXT-Record im DNS hinterlegt wird. Es dient dazu, das Fälschen von Absenderadressen (E-Mail-Spoofing) zu unterbinden. SPF teilt empfangenden E-Mail-Servern im Internet mit, welche IP-Adressen und Server autorisiert sind, E-Mails im Namen Ihrer Domain zu versenden. Gemeinsam mit DKIM und DMARC bildet SPF das Fundament moderner E-Mail-Authentifizierung – erst alle drei Verfahren zusammen schützen eine Domain zuverlässig vor Missbrauch.
Die Syntax eines SPF-Records
Ein typischer SPF-Eintrag sieht so aus:
example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.50 include:_spf.google.com ~all"
- Version (
v=spf1): Kennzeichnet den Eintrag als SPF-Version 1. - Mechanismen (Mechanisms): Definiert die erlaubten Absender.
ip4:192.0.2.50: Erlaubt E-Mails von dieser spezifischen IPv4-Adresse.ip6:2001:db8::1: Erlaubt E-Mails von dieser IPv6-Adresse.aundmx: Erlaubt die im A- bzw. MX-Record der Domain hinterlegten Server.include:_spf.google.com: Integriert (erbt) die SPF-Regeln des externen Dienstleisters (hier Google Workspace).
- Ausschluss-Regel (
~allbzw.-all): Definiert, was mit unbefugten Absendern geschehen soll.-all(Hard Fail): Nicht autorisierte E-Mails sollen sofort blockiert und abgewiesen werden.~all(Soft Fail): E-Mails von nicht autorisierten Servern werden angenommen, aber als potenzieller Spam markiert (empfohlen in Kombination mit DMARC).?all(Neutral): Keine Aussage über nicht autorisierte Server (nicht empfohlen).
Die zwei grössten Fallstricke bei der SPF-Konfiguration
1. Das Verbot mehrerer SPF-Records
Nutzen Unternehmen verschiedene Mail-Dienste (z. B. Microsoft 365 für Mitarbeiter, Mailchimp für Newsletter, Salesforce für CRM), wird oft für jeden Dienst ein eigener SPF-Record angelegt.
- Falsch:
TXT "v=spf1 include:spf.protection.outlook.com ~all"TXT "v=spf1 include:servers.mcsv.net ~all"
- Richtig: Die Einträge müssen in einem einzigen TXT-Record zusammengeführt werden:
TXT "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all"
2. Das 10-DNS-Lookup-Limit (RFC 7208)
Um DNS-DDoS-Angriffe zu verhindern, schreibt der Standard vor, dass die Auswertung eines SPF-Records maximal 10 zusätzliche DNS-Abfragen (Lookups) erfordern darf. Jeder Mechanismus wie include, mx oder a zählt als Lookup.
- Enthält Ihr SPF-Record viele
include-Einträge, und diese verweisen intern wiederum auf weitereincludes, ist das Limit von 10 schnell überschritten. - Die Folge: Empfänger-Server brechen die Prüfung mit einem
PermError(Permanent Error) ab. Die E-Mail gilt als nicht authentifiziert. - Die Lösung: Konsolidieren Sie Ihre Einträge oder nutzen Sie Techniken wie SPF Flattening, bei dem die Hostnamen durch direkte IP-Bereiche ersetzt werden.
SPF-Mechanismen und Qualifier im Überblick
Jeder Mechanismus in einem SPF-Record kann mit einem Qualifier kombiniert werden, der das Ergebnis steuert. Die folgende Tabelle fasst die wichtigsten Bausteine zusammen:
| Baustein | Bedeutung | Zählt als Lookup? |
|---|---|---|
ip4: / ip6: | Erlaubt eine konkrete IP-Adresse oder ein IP-Netz | Nein |
a | Erlaubt die im A-Record hinterlegten Server | Ja |
mx | Erlaubt die im MX-Record genannten Mailserver | Ja |
include: | Erbt die SPF-Regeln eines externen Anbieters | Ja (rekursiv) |
~all (Soft Fail) | Nicht autorisiert → annehmen, aber markieren | – |
-all (Hard Fail) | Nicht autorisiert → abweisen | – |
SPF schrittweise von ~all zu -all verschärfen
Viele Domains starten bewusst mit ~all (Soft Fail), weil ein zu früh gesetztes -all legitime Mailströme blockieren kann, solange noch nicht alle Versanddienste erfasst sind. Die empfohlene Reihenfolge:
| Stufe | Konfiguration | Wirkung |
|---|---|---|
| 1. Aufbau | ~all ohne DMARC | Nichts wird hart abgewiesen, Sie sammeln Erfahrung |
| 2. Beobachten | ~all + DMARC p=none | Reports zeigen alle Versender Ihrer Domain |
| 3. Durchsetzen | -all + DMARC p=reject | Fälschungen werden zuverlässig blockiert |
Das Zusammenspiel ist wichtig: Erst wenn die DMARC-Reports belegen, dass alle legitimen Quellen SPF bzw. DKIM bestehen, sollten Sie auf -all umstellen.
Das 10-Lookup-Limit in der Praxis lösen
Das Lookup-Limit ist die häufigste Ursache für PermError. Ein Beispiel für einen Record, der das Limit überschreitet, weil zu viele Drittanbieter eingebunden sind:
"v=spf1 include:_spf.google.com include:servers.mcsv.net include:spf.protection.outlook.com include:_spf.salesforce.com include:sendgrid.net -all"
Lösungsansätze:
- Konsolidieren: Nicht mehr genutzte Dienste aus dem Record entfernen.
- SPF Flattening: Hostnamen durch die dahinterliegenden
ip4:/ip6:-Bereiche ersetzen (reduziert Lookups, erfordert aber Pflege). - Subdomains nutzen: Newsletter über eine eigene Subdomain mit eigenem SPF-Record versenden.
Weitere Diagnoseschritte und dig-Beispiele finden Sie im DNS-Troubleshooting-Leitfaden.
[!TIP] Ein fehlerhafter SPF-Record führt dazu, dass Ihre geschäftlichen E-Mails direkt im Spam-Ordner Ihrer Kunden landen. Validieren Sie Ihre SPF-Konfiguration und prüfen Sie das Lookup-Limit mit dem kostenlosen SPF & DKIM Check auf balou.tools.
Häufig gestellte Fragen (FAQ)
Darf man mehrere SPF-Records für eine Domain anlegen?
Nein. Es darf zwingend nur ein einziger SPF-Record pro Domain existieren. Liegen mehrere Einträge vor, erklären Empfänger-Mailserver SPF sofort für ungültig, was die Zustellungsrate der E-Mails drastisch verschlechtert.
Was ist das 10-DNS-Lookup-Limit?
Um Überlastungen zu vermeiden, bricht ein prüfender Mailserver ab, wenn die Auflösung des SPF-Records (z. B. durch verschachtelte „include“-Anweisungen) mehr als 10 zusätzliche DNS-Abfragen erfordert. E-Mails fallen dann durch die Prüfung.
Wie prüfe ich, ob mein SPF-Record funktioniert?
Fragen Sie den TXT-Record Ihrer Domain ab (z. B. mit `dig TXT example.com +short`) und zählen Sie die enthaltenen Lookups. Ein Online-Validator zeigt zusätzlich, ob die Syntax korrekt ist, ob nur ein Record existiert und ob das 10-Lookup-Limit eingehalten wird.