Was SPF Flattening ist (und was nicht)
SPF Flattening ersetzt die Mechanismen, die einen DNS-Lookup kosten (include:, a, mx, redirect, exists), durch direkte Adressen (ip4: / ip6:). Diese Adressen sowie all kosten null Lookups - deshalb scheint Flattening auf dem Papier zu funktionieren.
Der Haken: Flattening friert eine lebende Delegation in eine statische Momentaufnahme ein. Verwechseln Sie statisches Flattening nicht mit dynamischem Hosted-SPF oder Makros - das sind nicht dieselben Dinge. Statisch veraltet, dynamisch aktualisiert sich selbst (siehe SPF Flattening vs. Makros).
Beispiel - vor dem Flattening:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Dieser Eintrag verbraucht mehrere DNS-Lookups.
Beispiel - nach dem Flattening (eingefrorene Momentaufnahme, die mit der Zeit zerfällt):
v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ip4:198.2.128.0/18 ~all
Die Lookups sinken, aber die Adressen sind nun fixiert und müssen gepflegt werden.
Das Limit von 10 DNS-Lookups und der PermError
RFC 7208 Abschnitt 4.6.4 schreibt maximal 10 DNS-Lookups bei der SPF-Auswertung vor.
| Mechanismus | Lookup-Kosten |
|---|---|
include: / a / mx / ptr / exists / redirect | mindestens 1 |
ip4: / ip6: / all | 0 |
Über das Limit hinaus entsteht ein permerror. Dieser hat eine doppelte Wirkung: legitime E-Mails können abgelehnt oder in den Spam-Ordner verschoben werden, Spoofer werden nicht mehr zuverlässig blockiert, und die DMARC-Ausrichtung bricht für alle Versandströme (siehe SPF too many DNS lookups beheben und den PermError-Leitfaden).
Es gibt ein zweites, oft vergessenes Limit: mehr als zwei Void-Lookups (Anfragen, die keine Antwort liefern) lösen ebenfalls einen permerror aus. Die meisten Checker übersehen das; dieses Tool macht die Void-Lookups sichtbar.
Unterscheiden Sie außerdem den Lookup-PermError vom Syntax-PermError: Flattening behebt weder Syntaxfehler noch mehrere SPF-Einträge. Das Verdikt "Fehler" des Tools fängt solche Fälle ab - prüfen Sie dann zuerst mit dem SPF Record Check und dem SPF Syntax Check.
Warum Flattening riskant ist (IP-Churn)
Ein statisches Flattening erzeugt drei Risiken:
- False Negatives - eine neue, legitime IP eines E-Mail-Anbieters fehlt im eingefrorenen Eintrag und scheitert an SPF.
- Spoofing-Fläche - eine außer Dienst gestellte IP bleibt weiterhin autorisiert.
- Schwer zu diagnostizierende, sporadische Ausfälle, die unregelmäßig auftreten.
Zwei belegte Anker zeigen das Ausmaß. Dokumentierter Fall von Mailhardener: nach einem Flattening ließ eine vom ESP hinzugefügte Load-Balancer-IP rund eine von 20 Nachrichten an SPF scheitern. Laut AutoSPF-Telemetrie ändert sich ein Drittanbieter-include im Median etwa alle 11,5 Tage, und IPv6-Ziele ändern sich rund 2,1-mal häufiger als IPv4 (bestmögliche, indikative Angabe).
Dazu die Größenfalle: Flattening löst das Lookup-Limit, verschärft aber das Größenlimit von 255 Zeichen pro TXT-Segment und rund 512 Byte - der Eintrag bläht sich zu Dutzenden von ip4- und ip6-Blöcken auf.
Microsoft 365 und Google Workspace veröffentlichen große, sich ändernde IP-Bereiche, was ein statisches Flattening fragil macht. Das Tool zeigt je Anbieter Churn-Badges (niedrig, mittel, hoch); das ist eine editoriale Einstufung, keine erfundene Änderungsfrequenz.
Um die Auswirkung auf die Zustellung zu messen, sehen Sie den Zustellbarkeits-Score.
Alternativen, bevor Sie flatten
Die folgenden Optionen sind nach steigendem Risiko geordnet - genau wie die Empfehlungen des Tools.
- Zuerst bereinigen - ungenutzte oder nie passende
include:entfernen,ptrstreichen (von der RFC abgeraten), redundantea/mxlöschen, Duplikate beseitigen. Das bringt Sie oft wieder unter 10, ganz ohne eingefrorene IPs. Gleichen Sie dies mit Ihren DMARC-Aggregatberichten ab. - Subdomain-Delegation - ein dedizierter Subdomain je Versandstrom, jeweils mit einem frischen Budget von 10 Lookups. Zur häufigen Sorge: eine gelockerte DMARC-Ausrichtung (
aspf=r) hält alles ausgerichtet - DMARC bricht dadurch nicht. - SPF-Makros (RFC 7208 Abschnitt 7) - ein dynamischer Eintrag ohne Veraltungsschuld; fortgeschritten.
- Hosted beziehungsweise selbstaktualisierender CNAME - bleibt aktuell; ehrlicherweise mit Anbieterbindung und Verlust der direkten DNS-Kontrolle.
- Vertrauen auf DKIM und DMARC verlagern (mit ARC und SRS) - der konzeptionelle Schlüssel: Flattening behebt nie Fehler bei Weiterleitungen oder Mailinglisten, da SPF die verbindende IP prüft, die sich beim Weiterleiten ändert. Robustheit entsteht durch DKIM (überlebt das Relay) und DMARC-Ausrichtung über DKIM. Prüfen Sie dies mit dem DKIM Record Check und dem DMARC Record Check; einen DMARC-Eintrag bauen Sie mit dem DMARC Generator.
Wann Flattening wirklich gerechtfertigt ist
Der Fall ist eng: Sie haben bereinigt, können nicht delegieren oder auf Hosted wechseln, liegen mit ausschließlich unverzichtbaren Sendern echt über 10 Lookups - und Sie verpflichten sich zur Re-Synchronisation. Flattening ist Wartungsschuld, kein einmaliger Vorgang.
Bevorzugen Sie wenn möglich dynamische Varianten (Makro oder Hosted) gegenüber dem statischen Flattening. Wenn Sie statisch flatten: überwachen Sie fortlaufend (etwa mit dem SPF Record Check) und akzeptieren Sie das gerade beschriebene Churn-Risiko. Ehrlich gesagt: ein statisches Einmal-Flattening ist eine Schuld, keine Lösung.
So lesen Sie das Verdikt des Tools
| Verdikt | Bedeutung |
|---|---|
| ok | Kein Flattening nötig - lassen Sie den Eintrag in Ruhe. |
| nahe am Limit | Knapp unter 10 Lookups; beobachten und vorsorglich bereinigen. |
| über dem Limit | permerror; vorrangig beheben. |
| Fehler | Lässt sich nicht flatten; zuerst Syntax oder mehrere SPF-Einträge korrigieren. |
| fehlend | Veröffentlichen Sie zuerst einen SPF-Eintrag. |
Die Budgetanzeige zeigt "X von 10 Lookups" und "V von 2 Void-Lookups". Merksatz: ein grünes Verdikt bedeutet, den Eintrag unverändert zu lassen.
FAQ - Häufig gestellte Fragen
F: Was ist SPF Flattening - und brauche ich es überhaupt?
A: SPF Flattening ersetzt die Lookup-kostenden Mechanismen (include:, a, mx, redirect, exists) durch direkte ip4:/ip6:-Adressen. Die meisten Einträge unter 10 Lookups brauchen das nicht. Ein grünes Verdikt im Tool heißt: lassen Sie den Eintrag, wie er ist.
F: Wie funktioniert das Limit von 10 DNS-Lookups (RFC 7208)?
A: RFC 7208 Abschnitt 4.6.4 begrenzt SPF auf 10 DNS-Lookups. include:, a, mx, ptr, exists und redirect kosten jeweils mindestens einen Lookup; ip4:, ip6: und all kosten null. Über 10 entsteht ein permerror. Es gibt ein zweites Limit: mehr als zwei Void-Lookups lösen ebenfalls einen permerror aus.
F: Wie behebe ich "too many DNS lookups" beziehungsweise einen permerror?
A: Nicht reflexartig flatten. Entfernen Sie zuerst ungenutzte include:, streichen Sie ptr und beseitigen Sie Duplikate - das bringt Sie meist wieder unter 10. Danach kommt die Subdomain-Delegation in Frage. Flattening kommt zuletzt. Mehr dazu im Leitfaden SPF too many DNS lookups beheben.
F: Ist SPF Flattening sicher?
A: Es birgt ein reales Risiko: ein statisches Flattening friert die IPs der Anbieter ein. Dokumentierter Fall (Mailhardener): eine hinzugefügte Load-Balancer-IP ließ rund eine von 20 Nachrichten an SPF scheitern. Laut AutoSPF-Telemetrie ändern sich Drittanbieter-includes im Median etwa alle 11,5 Tage. Bevorzugen Sie dynamische Optionen.
F: Welche Alternativen gibt es zum Flattening?
A: In Reihenfolge steigenden Risikos: Bereinigen, dann Subdomain-Delegation (mit gelockerter DMARC-Ausrichtung aspf=r), dann SPF-Makros, dann Hosted beziehungsweise CNAME, und schließlich das Vertrauen auf DKIM und DMARC verlagern.
F: Bricht Flattening DMARC oder behebt es Weiterleitungsfehler?
A: Flattening behebt keine Fehler bei Weiterleitungen oder Mailinglisten, denn SPF prüft die verbindende IP, die sich beim Weiterleiten ändert. DMARC-Robustheit kommt aus der DKIM-Ausrichtung; eine Subdomain-Delegation mit aspf=r hält die Ausrichtung intakt. Prüfen Sie Ihren Eintrag mit dem DMARC Record Check.
F: Statisches Flattening vs. Hosted oder dynamischer SPF - was ist der Unterschied?
A: Statisch ist eine eingefrorene IP-Momentaufnahme, die mit der Zeit veraltet. Dynamisch (Makro oder Hosted) aktualisiert sich selbst. Beides sollte man nicht verwechseln (siehe SPF Flattening vs. Makros).
F: Flattening hat meine Lookups behoben, aber der Eintrag ist jetzt zu lang - warum?
A: Das Limit von 255 Zeichen pro TXT-Segment und rund 512 Byte ist ein eigenes Limit. Flattening tauscht das Lookup-Problem gegen ein Größenproblem. Lösung: in Segmente aufteilen oder per Subdomain delegieren.
F: SPF Flattener vs. SPF Generator vs. SPF Checker - was nutze ich?
A: Der SPF Record Check diagnostiziert, der SPF Generator baut einen frischen Eintrag, und der SPF Flattener ist der beratende Optimierer für den letzten Schritt.
Ergänzende Tools
| Tool | Nutzen |
|---|---|
| SPF Record Check | Lookup-Budget diagnostizieren und nach jeder Änderung erneut prüfen |
| SPF Syntax Check | SPF-Syntax vor der Veröffentlichung validieren |
| SPF Generator | Einen frischen SPF-Eintrag erstellen |
| DMARC Record Check | DMARC-Ausrichtung und -Richtlinie prüfen |
| DKIM Record Check | DKIM-Robustheit für Weiterleitungen prüfen |
| Mail Tester | Den Versand Ende zu Ende validieren |
| Mail Domain Check | Komplettaudit der E-Mail-Authentifizierung |
| IP-Blacklist-Prüfung | Reputation der sendenden IP prüfen |
| Domain-Blacklist-Prüfung | Reputation der sendenden Domain prüfen |
Nützliche Ressourcen
- RFC 7208 - Sender Policy Framework (SPF) : Quelle für das Limit von 10 Lookups, die Void-Lookups und die Makros
- RFC 4408 - SPF (ältere Version) : Frühere Version der SPF-Spezifikation
- dmarcian - SPF Best Practices : Autorität, die das Flattening-Experiment für beendet erklärt hat
- Mailhardener - Do not flatten your SPF record : Quelle des dokumentierten Falls von rund einer von 20 Nachrichten
- Google Workspace - SPF konfigurieren und Fehler beheben : Google-Anleitung zur SPF-Konfiguration
- Microsoft 365 - SPF konfigurieren und Fehler beheben : Microsoft-Anleitung zur SPF-Konfiguration