Was ist SPF-Flattening (und wann du es wirklich einsetzen solltest)

Sobald eine Domain zu viele Versanddienstleister ansammelt, stößt sie an das berüchtigte Limit von zehn DNS-Lookups bei SPF. Unter den immer wiederkehrenden Lösungen trägt eine einen faszinierenden Namen: das SPF-Flattening (oder „Abflachen"). Die Idee klingt auf dem Papier verlockend — die include ein für alle Mal auflösen und durch IP-Adressen ersetzen — aber sie verbirgt eine Wartungsschuld, die viele zu spät entdecken. Dieser Leitfaden erklärt genau, was Flattening ist, wie es funktioniert, seine wahren Risiken und in welchen Fällen ein anderer Ansatz besser ist.

Das Problem, das Flattening zu lösen vorgibt

Kurze Erinnerung: Jedes include:, a, mx oder ptr in deinem SPF-Eintrag kostet mindestens einen DNS-Lookup, und die RFC 7208 deckelt das Gesamtvolumen bei zehn. Darüber kommt der PermError: Dein SPF wird gar nicht mehr ausgewertet, und deine legitime Mail riskiert Quarantäne oder Ablehnung. Die include von Dienstleistern (Microsoft 365, Google Workspace, ein Marketing-Router …) entfalten sich oft in mehrere Lookups pro Stück, sodass man die Grenze überschreitet, ohne es zu merken.

Das Flattening greift dieses Problem an der Wurzel an: Da es die include sind, die Lookups kosten, entfernt man sie — indem man sie durch die IP-Adressen ersetzt, die sie enthalten.

Wie das Abflachen funktioniert

Das Prinzip ist mechanisch. Für jedes include deines Eintrags löst man rekursiv alles auf, worauf es verweist (Sub-include, a, mx), bis man die vollständige Liste der autorisierten Adressbereiche hat. Dann ersetzt man das include durch die entsprechenden ip4: und ip6:.

Nehmen wir ein Beispiel. Ein klassischer Eintrag:

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

Nach dem Abflachen könnte er so aussehen:

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

Das Ergebnis enthält nur noch ip4:/ip6: — Literale, die nicht ins Limit der zehn zählen. Die Lookup-Zählung fällt auf null (bis auf den abschließenden Mechanismus). Auf dem Papier: Problem gelöst.

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 dich pflegt.

Beim Abflachen brichst du diese Verbindung. Du frierst eine Momentaufnahme der Dienstleister-IPs zum Zeitpunkt des Abflachens ein. An dem Tag, an dem er auf einen neuen Bereich wechselt, den du nicht mitkopiert hast, scheitert die von diesem Bereich versendete Mail an SPF — und du siehst es nicht sofort. Das ist die grausame Ironie des Flattening: Du behebst heute einen PermError und setzt dich morgen stillen Fehlschlägen aus.

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 dein 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 deinen Eintrag aktualisiert (oft über eine DNS-Delegation oder ein include auf einen verwalteten Eintrag). Du tauschst die Wartungsschuld gegen eine Abhängigkeit von diesem Dienst — und führst in der Praxis ein include (auf den Dienst) in dein SPF wieder ein. Das ist nichts Schlimmes, aber wisse, dass du die include-Mechanik nicht wirklich entfernt, sondern verlagert hast.

Wann Flattening eine gute Idee ist …

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

• du wirklich blockiert bist über zehn Lookups und die anderen Hebel nicht reichen;
• deine Dienstleister stabile IP-Bereiche haben (manche Infrastrukturen ändern sich selten);
• du eine Überwachung einrichtest, die dich warnt, wenn sich eine Dienstleister-IP ändert, oder einen zuverlässigen automatisierten Dienst nutzt.

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

… und wann du es besser vermeidest

Für viele Organisationen ist Flattening eine überzogene Antwort. Bevor du dazu greifst, schöpfe die gesünderen Optionen aus:

1. Räum die unnötigen include auf. Die Hälfte der Überschreitungen kommt von Tools, die man nicht mehr nutzt. Kostenlos und risikofrei.
2. Trenn deine Flüsse nach Subdomain. Marketing auf news.ton-domaine.fr, Transaktionales auf notif.ton-domaine.fr: Jede Subdomain hat ihr eigenes Budget von zehn Lookups, und du behältst die vom Dienstleister gepflegten include. Das ist der nachhaltigste Ansatz und der, den wir zuerst empfehlen.
3. Ersetze nur die Dienstleister mit stabilen IPs durch ip4:, und lass die, die sich bewegen, in include.

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 würde dich zwingen, 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.

Opfere nicht die abschließende Qualifizierung

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 deines SPF — -all (hardfail) bleibt die richtige abschließende Qualifizierung für eine beherrschte Domain. Abflachen und Abschwächen sind zwei verschiedene Entscheidungen; verwechsle sie nicht. Die Nuance ist in den Mechanismen -all und ~all erklärt.

Nach dem Abflachen prüfen

Sobald der Eintrag abgeflacht ist, kontrolliere zwei Dinge:

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

Häufige Fragen

Verbessert Flattening die Zustellbarkeit? Nicht direkt. Es behebt einen PermError, der wiederum deine 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 deiner Dienstleister ab. Manche bewegen sich fast nie, andere ändern ihre Bereiche mehrmals im Jahr. Ohne automatisierten Dienst plane eine regelmäßige Überprüfung ein — 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, dein 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 du wirst für jede IP jedes Dienstleisters verantwortlich, auf Lebenszeit. 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 du das Problem nicht gelöst, sondern nur in die Zukunft verschoben hast — und zwar in eine Form, die viel schwerer zu bemerken ist. Ein PermError ist wenigstens laut: Er taucht in deinen Berichten auf, er lässt Mail scheitern, du wirst darauf aufmerksam. Ein veraltetes Flattening dagegen ist leise: Nur die Nachrichten, die von einer neu hinzugefügten Provider-IP ausgehen, scheitern, oft ein kleiner Bruchteil deines Volumens, verstreut über die Berichte, ohne einen einzelnen Alarm auszulösen. Du entdeckst es womöglich erst, wenn ein wichtiger Kunde meldet, dass deine 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 dein Marketing-Router seine IPs ändert, weil du sein include gar nicht angetastet hast. Das ist der entscheidende Unterschied: Die strukturelle Lösung ist selbstheilend, das Flattening ist selbstveraltend.

Eine Checkliste vor dem Abflachen

Bevor du dich zum Flattening entschließt, geh diese Fragen durch. Erstens: Hast du wirklich alle unnötigen include entfernt, oder sind ein oder zwei Tools darunter, die du gar nicht 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 du immer noch über zehn liegst, ist Flattening gerechtfertigt — und selbst dann nur für die Provider mit nachweislich stabilen, dokumentierten IP-Bereichen, gekoppelt an eine Überwachung, die dich bei Änderungen warnt. Diese Disziplin trennt den gezielten, wartbaren Einsatz vom pauschalen Abflachen, das dich in sechs Monaten einholt.

Lass Thomas den richtigen Ansatz wählen

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

Analysiere deine Domain kostenlos → oder erstelle ein Konto, um ein sauberes SPF unter der Marke zu halten.