Was du brauchst
Zugriff auf die DNS-Verwaltung deiner Domain und eine vollständige Liste aller Systeme, die in deinem Namen E-Mails versenden. Der zweite Punkt ist der aufwendigere: Neben dem Mailserver gehören dazu Newsletter-Tools, CRM- und Ticketsysteme, Shop-Software, Monitoring und Rechnungsversand.
Schritt 1 — TXT-Record anlegen
SPF ist ein normaler DNS-TXT-Record auf der Domain selbst, nicht auf einer Subdomain wie _spf. Als Name trägst du je nach Provider @, den Domainnamen oder nichts ein.
Schritt 2 — die richtigen Mechanismen wählen
include:anbieter.de— übernimmt den SPF-Record eines Dienstleisters. Der bevorzugte Weg, weil der Anbieter seine IPs selbst pflegt.ip4:1.2.3.4— autorisiert eine einzelne IPv4-Adresse. Auch als Netz möglich:ip4:1.2.3.0/24.ip6:2001:db8::1— dasselbe für IPv6. Wer über IPv6 sendet, muss das eintragen, sonst schlägt SPF für diese Verbindungen fehl.a— autorisiert die IPs aus dem A-Record der Domain.mx— autorisiert die eigenen MX-Server. Nur sinnvoll, wenn dieselben Server auch senden.ptr— veraltet, langsam und von RFC 7208 ausdrücklich abgeraten. Nicht verwenden.
Typische Beispiele:
Schritt 3 — den all-Qualifier setzen
Der letzte Term legt fest, was mit allen nicht genannten Servern passiert:
-all(hardfail) — alle anderen sind nicht autorisiert. Das ist das Ziel.~all(softfail) — nicht autorisiert, aber bitte nur markieren. Vertretbar in der Einführungsphase.?all(neutral) — keine Aussage. Praktisch wirkungslos.+all— autorisiert jeden Server der Welt. Nie verwenden.
Beginne mit ~all, wenn du unsicher bist, ob du alle Absender erfasst hast, und stelle nach zwei bis vier Wochen Beobachtung über DMARC-Reports auf -all um.
Schritt 4 — das Lookup-Limit einhalten
Das ist der häufigste und tückischste Fehler. RFC 7208 erlaubt bei der Auswertung eines SPF-Records maximal 10 DNS-Lookups. Gezählt werden include, a, mx, ptr, exists und redirect — und zwar rekursiv: Ein include: auf einen Anbieter, dessen Record selbst drei weitere Includes enthält, verbraucht vier Lookups.
Wird das Limit überschritten, liefert der gesamte Record permerror. Nicht nur der überzählige Teil fällt aus, sondern alles — auch die Absender, die vorher funktioniert haben. Wichtig: ip4: und ip6: verbrauchen keinen Lookup.
Wenn es eng wird:
- Nicht mehr genutzte
include:-Einträge entfernen — meist die Hälfte. - Einzelne Anbieter durch ihre konkreten
ip4:-Bereiche ersetzen, sofern diese stabil sind. - Verschiedene Versandsysteme auf eigene Subdomains legen (
news.deinedomain.de), jede mit eigenem SPF-Record und eigenem Lookup-Budget.
Zusätzlich gilt ein Limit von 2 Void-Lookups — Abfragen, die ins Leere laufen. Ein include: auf eine gelöschte Domain zählt dagegen.
Häufige Fehler
- Zwei SPF-Records: Eine Domain darf genau einen
v=spf1-Record haben. Bei zweien ist das Ergebnis permerror. Alles in einen Record zusammenführen. - Record auf der falschen Ebene: SPF gehört auf die Domain, aus der versendet wird. Versendest du von
firma.de, hilft ein Record aufwww.firma.denicht. - Subdomains vergessen: SPF wird nicht vererbt. Jede sendende Subdomain braucht einen eigenen Record.
- Zeilenlänge: Ein einzelner TXT-String darf 255 Zeichen nicht überschreiten. Längere Records müssen in mehrere Strings aufgeteilt werden — die meisten DNS-Oberflächen machen das automatisch.
Testen
Nach dem Anlegen dauert es je nach TTL bis zu 24 Stunden, bis die Änderung überall sichtbar ist. Danach schickst du eine E-Mail an hello@analyzemy.email und bekommst den vollständigen SPF-Audit zurück: Ergebnis, rekursive Lookup-Zählung mit Breakdown, Void-Lookups und alle IPs, die dein Record tatsächlich autorisiert.