Was ist SPF-Flattening (und wann es wirklich einzusetzen ist)

v=spf1 include:_spf.google.com include:sendgrid.net -all

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20
  ip4:167.89.0.0/17 ip4:168.245.0.0/17 ... -all

Die Falle: die IPs der Dienstleister ändern sich

Hier, was die enthusiastischen Ratgeber oft vergessen zu sagen. Die IP-Bereiche hinter einem Dienstleister-include sind nicht festgeschrieben. Microsoft, Google, SendGrid und die anderen fügen regelmäßig Server hinzu, entfernen oder reorganisieren sie. Das ist sogar der ganze Sinn des include: Es zeigt auf einen Eintrag, den der Dienstleister für seine Kunden pflegt.

Beim Abflachen bricht diese Verbindung. Eingefroren wird eine Momentaufnahme der Dienstleister-IPs zum Zeitpunkt des Abflachens. An dem Tag, an dem er auf einen neuen, nicht mitkopierten Bereich wechselt, scheitert die von diesem Bereich versendete Mail an SPF — und niemand sieht es sofort. Das ist die grausame Ironie des Flattening: Es behebt heute einen PermError und öffnet morgen die Tür für stille Fehlschläge.

Manuelles oder automatisiertes Abflachen

Um dieses Risiko zu handhaben, gibt es zwei Schulen:

• Das manuelle Abflachen besteht darin, die IPs von Hand aufzulösen und zu kopieren. Einfach zu verstehen, aber genau hier beißt die Schuld: Ohne Überwachung veraltet der Eintrag, sobald der Dienstleister sich bewegt. Reserviert für Dienstleister, deren Bereiche stabil und dokumentiert sind.
• Das automatisierte Abflachen delegiert die Nachverfolgung an einen Dienst, der periodisch neu abflacht und den Eintrag aktualisiert (oft über eine DNS-Delegation oder ein include auf einen verwalteten Eintrag). Damit wird die Wartungsschuld gegen eine Abhängigkeit von diesem Dienst getauscht — und in der Praxis kehrt ein include (auf den Dienst) ins SPF zurück. Das ist nichts Schlimmes, sollte aber bewusst sein: Die include-Mechanik ist nicht wirklich entfernt, nur verlagert.

Wann Flattening eine gute Idee ist …

Flattening ist nicht zu verteufeln. Es hat seinen Platz, wenn:

• die Domain über zehn Lookups wirklich blockiert ist und die anderen Hebel nicht reichen;
• die Dienstleister stabile IP-Bereiche haben (manche Infrastrukturen ändern sich selten);
• eine Überwachung eingerichtet ist, die bei jeder Änderung einer Dienstleister-IP warnt, oder ein zuverlässiger automatisierter Dienst zum Einsatz kommt.

Unter diesen Bedingungen ist es ein legitimes Werkzeug, um einen komplexen Eintrag unter der Marke zu halten.

… und wann es besser zu vermeiden ist

Für viele Organisationen ist Flattening eine überzogene Antwort. Vor dem Griff dazu sind die gesünderen Optionen auszuschöpfen:

1. Die unnötigen include aufräumen. Die Hälfte der Überschreitungen kommt von Tools, die man nicht mehr nutzt. Kostenlos und risikofrei.
2. Die Flüsse nach Subdomain trennen. Marketing auf news.beispiel.de, Transaktionales auf notif.beispiel.de: Jede Subdomain hat ihr eigenes Budget von zehn Lookups, und die vom Dienstleister gepflegten include bleiben erhalten. Das ist der nachhaltigste Ansatz und der, den wir zuerst empfehlen.
3. Nur die Dienstleister mit stabilen IPs durch ip4: ersetzen, und die, die sich bewegen, in include belassen.

In der großen Mehrheit der Fälle reichen diese drei Hebel, um wieder unter zehn zu kommen — ohne die Schuld des vollständigen Flattening. Die detaillierte Sequenz steht in das Limit von 10 DNS-Lookups.

Ein echter Fall: der KMU mit mehreren Dienstleistern

Illustrieren wir es mit einer sehr verbreiteten Situation. Ein KMU versendet über Microsoft 365 (Messaging), einen Marketing-Router, ein Rechnungstool und einen elektronischen Signaturdienst. Sein SPF stapelt vier include, die sich in dreizehn Lookups entfalten — PermError garantiert. Die Versuchung ist, alles auf einmal abzuflachen. Schlechte Idee: Drei dieser vier Dienstleister ändern ihre IP-Bereiche mehrmals im Jahr.

Die richtige Lesart des Falls beginnt damit, die Dienstleister nach der Stabilität ihrer IPs zu sortieren, nicht nach ihrem Volumen. Microsoft 365 veröffentlicht ein reichhaltiges, aber gut gepflegtes include: Man behält es als include, denn es einzufrieren hieße, seinen monatlichen Updates hinterherzulaufen. Der Signaturdienst hingegen hat nur eine Handvoll dokumentierter fester IPs: Man kann sie als ip4: eintragen, ohne Risiko, und spart einen Lookup. Der Marketing-Router, ein großer Verbraucher, geht auf eine Subdomain news.pme.fr mit eigenem SPF — er verlässt also vollständig die Zählung der Root-Domain.

Ergebnis: Die Root-Domain trägt nur noch Microsoft 365 (als include), die Rechnungsstellung (als include) und die Signatur (als ip4:), also fünf oder sechs Lookups — unter der Marke, und ohne den instabilsten Dienstleister abzuflachen. Man hat nur das abgeflacht, was sicher abzuflachen war. Das ist der gute Einsatz des Flattening: ein gezieltes Skalpell auf die stabilen IPs, keine Axt auf den ganzen Eintrag. Die verbleibende Wartung beschränkt sich darauf, die Handvoll eingefrorener ip4: zu überwachen, was eine vierteljährliche Kontrolle reichlich abdeckt.

Die abschließende Qualifizierung nicht opfern

Ein zu vermeidender Reflex, den man oft mit dem Flattening einhergehen sieht: die Überarbeitung nutzen, um „zur Sicherheit" auf ~all zu wechseln. Das Flattening ändert nichts an der Strenge des SPF — -all (hardfail) bleibt die richtige abschließende Qualifizierung für eine beherrschte Domain. Abflachen und Abschwächen sind zwei verschiedene Entscheidungen; sie gehören nicht verwechselt. Die Nuance ist in den Mechanismen -all und ~all erklärt.

Nach dem Abflachen prüfen

Sobald der Eintrag abgeflacht ist, sind zwei Dinge zu kontrollieren:

1. Die Lookup-Zählung ist wieder unter zehn, und die Syntax ist gültig — ein Blick in unseren kostenlosen Analyzer, wie in wie sich ein Eintrag prüfen lässt beschrieben.
2. Die Quellen bestehen weiterhin, auf Dauer. Die aggregierten Berichte gehören in den folgenden Wochen überwacht: Eine Quelle, die plötzlich anfängt, an SPF zu scheitern, ist das Signal, dass sich ein IP-Bereich geändert hat und das Abflachen gealtert ist.

Häufige Fragen

Verbessert Flattening die Zustellbarkeit? Nicht direkt. Es behebt einen PermError, der wiederum die Zustellbarkeit belastete — der Nettoeffekt kann also positiv sein. Aber ein SPF abzuflachen, das schon unter dem Limit liegt, bringt nichts und fügt Schuld hinzu.

Muss ich oft neu abflachen? Das hängt von der Stabilität der Dienstleister ab. Manche bewegen sich fast nie, andere ändern ihre Bereiche mehrmals im Jahr. Ohne automatisierten Dienst ist eine regelmäßige Überprüfung einzuplanen — genau das ist die Schuld, die man einkalkulieren muss.

Umgeht Flattening auch die DKIM-Limits? Die Frage stellt sich nicht: DKIM hat kein Lookup-Limit. Das Problem der zehn Lookups ist SPF-eigen. Das ist übrigens ein Grund, das DKIM-Alignment zu pflegen, das robuster ist — siehe wie die drei Protokolle zusammenarbeiten.

Kann ich alles auf ip4: setzen und gar kein include haben? Technisch ja, aber dann liegt die Verantwortung für jede IP jedes Dienstleisters auf Lebenszeit beim Domaininhaber. Das ist selten vernünftig, außer für eine vollständig intern beherrschte Versandinfrastruktur.

Löst Flattening den doppelten SPF-Eintrag? Nein, das sind zwei verschiedene Probleme. Zwei v=spf1-Einträge zu haben ist ein Konfigurationsfehler, der durch Zusammenführen zu einem einzigen zu beheben ist — unabhängig von der Lookup-Zählung.

Der versteckte Preis der Bequemlichkeit

Der eigentliche Grund, warum Flattening so verlockend wirkt, ist psychologisch: Es verspricht, ein Problem sofort und endgültig verschwinden zu lassen. Der PermError ist heute weg, die Lookup-Zählung steht auf null, das Häkchen im Analyzer ist grün. Diese sofortige Befriedigung verschleiert, dass das Problem nicht gelöst, sondern nur in die Zukunft verschoben ist — und zwar in eine Form, die viel schwerer zu bemerken ist. Ein PermError ist wenigstens laut: Er taucht in den Berichten auf, er lässt Mail scheitern, er fällt auf. Ein veraltetes Flattening dagegen ist leise: Nur die Nachrichten, die von einer neu hinzugefügten Provider-IP ausgehen, scheitern, oft ein kleiner Bruchteil des Volumens, verstreut über die Berichte, ohne einen einzelnen Alarm auszulösen. Entdeckt wird es womöglich erst, wenn ein wichtiger Kunde meldet, dass die Rechnungen im Spam landen.

Genau deshalb raten erfahrene Betreiber, Flattening als letztes Mittel zu behandeln und die strukturellen Lösungen — Aufräumen und Subdomain-Trennung — immer zuerst auszuschöpfen. Diese kosten am Anfang etwas mehr Nachdenken, aber sie erzeugen keine schlummernde Wartungsschuld. Ein nach Subdomain aufgeteilter Versand bleibt korrekt, egal wie oft der Marketing-Router seine IPs ändert, weil sein include gar nicht angetastet wurde. Das ist der entscheidende Unterschied: Die strukturelle Lösung ist selbstheilend, das Flattening ist selbstveraltend.

Eine Checkliste vor dem Abflachen

Vor dem Entschluss zum Flattening sind diese Fragen durchzugehen. Erstens: Sind wirklich alle unnötigen include entfernt, oder sind ein oder zwei Tools darunter, die niemand mehr nutzt? Zweitens: Können die volumenstärksten Flüsse — typischerweise Marketing — auf eine eigene Subdomain wandern, wo sie ihr eigenes Lookup-Budget haben? Drittens: Lassen sich einige Drittanbieter über ausgerichtetes DKIM statt über SPF einbinden, was gar keinen Lookup kostet? Erst wenn diese drei Hebel ausgeschöpft sind und die Zählung immer noch über zehn liegt, ist Flattening gerechtfertigt — und selbst dann nur für die Provider mit nachweislich stabilen, dokumentierten IP-Bereichen, gekoppelt an eine Überwachung, die bei Änderungen warnt. Diese Disziplin trennt den gezielten, wartbaren Einsatz vom pauschalen Abflachen, das einen in sechs Monaten einholt.

Thomas wählt den richtigen Ansatz

Soll man abflachen, aufräumen oder in Subdomains aufteilen? Die Antwort hängt von den realen Dienstleistern und der Stabilität ihrer IPs ab. Thomas, der virtuelle CISO, entfaltet das SPF, identifiziert die gefräßigen include, unterscheidet die, die man risikofrei einfrieren kann, von denen, die sich bewegen, und empfiehlt die nachhaltigste Korrektur für den behandelten Fall — nicht die modischste.

Eine Domain kostenlos analysieren oder ein Konto erstellen, um ein sauberes SPF unter der Marke zu halten.