So flatten Sie einen SPF-Eintrag

Einen SPF-Eintrag zu flatten bedeutet, die Mechanismen, die DNS-Lookups auslösen – include:, a, mx, exists, ptr und redirect – durch die expliziten ip4:- und ip6:-Bereiche zu ersetzen, zu denen sie auflösen. Das Ergebnis ist ein Eintrag, der genau dieselben Absender autorisiert, aber empfangende Server zwingt, weit weniger (idealerweise null) DNS-Abfragen zu durchlaufen, wodurch Sie sicher unter dem 10-Lookup-Limit von RFC 7208 bleiben. Diese Anleitung führt Schritt für Schritt durch den Prozess, zeigt, wie ein geflatteter Eintrag aussieht, und erklärt, wie Sie ihn nach dem Livegang korrekt halten.

Diese Seite ist Teil unseres größeren Leitfadens zum SPF Flattening. Wenn Sie die manuelle Arbeit ganz überspringen möchten, expandiert der SPF Checker jedes Include und zählt Ihre Lookups in Sekunden.

Warum Sie einen SPF-Eintrag überhaupt flatten würden

Die SPF-Authentifizierung ist unter RFC 7208 auf 10 DNS-Lookups pro Auswertung begrenzt. Jeder include:-, a-, mx-, exists- und redirect-Term zählt gegen dieses Budget, und jeder einzelne kann weitere rekursive Lookups innerhalb der Domain auslösen, auf die er verweist. Fügen Sie eine Marketingplattform, ein CRM, ein Helpdesk und einen Rechnungsdienst hinzu, und ein einzelner v=spf1-Eintrag kann still auf 15–40 Lookups anschwellen.

Wenn Sie das Limit überschreiten, geben Empfänger einen PermError zurück. Ein PermError lässt nicht nur eine Nachricht scheitern – er macht den gesamten Eintrag ungültig, sodass legitime Mail von jeder autorisierten Quelle an SPF zu scheitern beginnen kann. Da nichts laut zurückprallt, bemerken Teams es oft erst, wenn ein Kunde eine fehlende Rechnung oder Passwort-Reset-E-Mail meldet.

Flattening löst dies, indem es diese indirekten Mechanismen im Voraus auflöst und die rohen IPs veröffentlicht. Ein Empfänger, der einen vollständig geflatteten Eintrag auswertet, führt einfachen IP-Abgleich ohne rekursive DNS-Traversierung durch, was auch schnellere Validierung und keine Anfälligkeit für einen temporären DNS-Ausfall eines Drittanbieters bedeutet.

Wie ein geflatteter SPF-Eintrag aussieht

Hier ist ein typischer ungeflatteter Eintrag, der sich auf drei Includes stützt:

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

Jedes Include ist mindestens ein Lookup, und allein Googles Include verschachtelt mehrere weitere. Geflattet wird dieselbe Autorisierung zu einer direkten Liste von IPs:

v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -all

Zum Auswertungszeitpunkt finden keine Lookups statt, weil jede autorisierte Adresse bereits ausgeschrieben ist. Der -all-Qualifikator bleibt erhalten, sodass die Richtlinie streng bleibt.

Wie man einen SPF-Eintrag flattened, Schritt für Schritt

Schritt 1: Ihren aktuellen Eintrag finden und prüfen

Rufen Sie Ihren bestehenden SPF-Eintrag mit einer dig TXT ihredomain.com-Abfrage (oder dem Dashboard Ihres DNS-Anbieters) ab und bestätigen Sie, dass Sie genau einen v=spf1-TXT-Eintrag haben. Mehrere SPF-Einträge unter demselben Namen sind selbst ein PermError. Notieren Sie, welche Mechanismen Lookups verursachen (include, a, mx, exists, redirect, ptr) im Gegensatz zu den kostenlosen ip4/ip6-Einträgen, die Sie unverändert lassen können.

Schritt 2: Ihre Lookups zählen

Bevor Sie etwas ändern, messen Sie, wie weit Sie über dem Budget liegen. Lassen Sie Ihre Domain durch den SPF Checker laufen, der jedes Include rekursiv expandiert und Ihnen eine exakte Lookup-Anzahl liefert. Wenn Sie bei 8 oder mehr liegen oder bereits einen PermError sehen, ist Flattening (oder Delegation) angebracht. Wenn Sie bei 3 oder weniger stabilen Includes liegen, müssen Sie möglicherweise überhaupt nicht flatten.

Schritt 3: Jeden Mechanismus rekursiv zu IPs auflösen

Dies ist der Kern des Flattenings. Lösen Sie für jeden Lookup-verursachenden Term zu expliziten Adressen auf:

Mechanismus	Wie man ihn auflöst	Ergebnis
include:	Rufen Sie den SPF-Eintrag des Ziels ab und expandieren Sie dessen Mechanismen rekursiv	ip4:/ip6: für jede IP, die es autorisiert
a	Lösen Sie die A/AAAA-Einträge der Domain auf	Ein ip4:/ip6: pro Adresse
mx	Lösen Sie MX-Einträge auf, dann die A/AAAA jedes Mailhosts	ip4:/ip6: für jede MX-Host-IP
ptr	Nicht flatten – es ist veraltet, langsam und unzuverlässig	Entfernen Sie es
exists:	Kann in der Regel nicht geflattet werden (hängt von Laufzeit-Makros ab)	Unverändert lassen oder auf eine Subdomain isolieren
ip4/ip6	Bereits statisch	Unverändert lassen

Durchlaufen Sie den Graphen tiefensuchorientiert und verfolgen Sie, welche Domains Sie bereits besucht haben, damit Sie zirkuläre Includes erkennen können – wenn ein Include auf eine Domain zurückverweist, die bereits auf Ihrem Auflösungs-Stack liegt, halten Sie an und behalten Sie es als Include bei, anstatt endlos zu schleifen.

Schritt 4: CIDRs deduplizieren und aggregieren

Rekursive Expansion erzeugt Überschneidungen. Zwei Anbieter teilen sich möglicherweise eine IP, oder Sie sammeln mehrere benachbarte /25-Blöcke, die sich sauber zu einem /24 kombinieren lassen. Deduplizieren Sie jede Adresse, dann aggregieren Sie benachbarte Bereiche zu Supernets nur, wenn die Vereinigung vollständig innerhalb des autorisierten Raums eines Anbieters bleibt. Über-Aggregation über nicht verwandte Anbieter hinweg autorisiert IPs, die Sie nicht kontrollieren – eine Sicherheitsregression, keine Optimierung.

Schritt 5: Die Eintragsgröße im Auge behalten

DNS-TXT-Strings sind auf 255 Zeichen pro in Anführungszeichen gesetztes Segment begrenzt; längere Einträge müssen in mehrere verkettete Strings innerhalb desselben Eintrags aufgeteilt werden. Als praktische Regel gilt: Halten Sie die Gesamtantwort unter etwa 450–900 Bytes, um UDP-Fragmentierung und Middlebox-Probleme zu vermeiden. Wenn die geflattete Liste zu groß ist, teilen Sie IPs in Helfer-Labels auf (z. B. spf-a.example.com, spf-b.example.com), die jeweils nur ip4/ip6-Einträge enthalten, und includen Sie diese vom Haupteintrag – jeder Helfer kostet einen Lookup, halten Sie die Gesamtzahl also bei ≤ 10.

Schritt 6: Den all-Qualifikator wieder anhängen und validieren

Hängen Sie Ihren ursprünglichen terminierenden Mechanismus an – -all für strenge Durchsetzung wird für produktive Absender empfohlen. Lassen Sie dann den Eintrag erneut durch einen SPF-Validator laufen, um zu bestätigen, dass die Syntax sauber ist, es weiterhin nur einen Eintrag gibt und die Lookup-Anzahl dort liegt, wo Sie es erwarten. Wenn Sie vorsichtig migrieren, können Sie kurzzeitig mit ~all veröffentlichen und dann auf -all umstellen, sobald die Überwachung stabile Passraten zeigt.

Schritt 7: Mit niedriger TTL veröffentlichen, dann anheben

Bevor Sie veröffentlichen, senken Sie die TTL des Eintrags auf 60–300 Sekunden, damit jeder Fehler schnell korrigiert werden kann. Veröffentlichen Sie den neuen geflatteten Eintrag, verifizieren Sie, dass er von mehreren öffentlichen Resolvern (Google, Cloudflare, Quad9) korrekt auflöst, und beobachten Sie Ihre DMARC-Aggregatberichte auf jeden Rückgang der SPF-Passraten. Sobald alles stabil ist, heben Sie die TTL wieder auf 1–4 Stunden an.

Der Haken: Geflattete Einträge veralten

Hier ist das Problem, über das die meisten Menschen stolpern, die von Hand flatten. In dem Moment, in dem Sie flatten, ist Ihr Eintrag eine Momentaufnahme. Wenn Google, Mailchimp, Amazon SES oder ein anderer Anbieter seine sendenden IPs rotiert – und große ESPs tun dies ständig – stimmt Ihre fest codierte Liste nicht mehr mit der Realität überein. Mail von den neuen IPs scheitert stillschweigend an SPF, und Sie sind zurück bei verlorenen Rechnungen und fehlgeschlagenen Passwort-Resets, nur ist die Ursache jetzt unsichtbar, weil der Eintrag einwandfrei aussieht.

CDN-gestützte und Marketing-Absender sind die schlimmsten Übeltäter: Interne AutoSPF-Daten über mehr als 1.200 Domains zeigen, dass CDN-gestützte Absender monatlich 8–15 % ihres IP-Sets rotieren, gegenüber unter 0,5 % bei internen Mailservern. Einen Anbieter mit hoher Fluktuation blind zu flatten, ist ein Rezept für Ärger.

Die praktischen Erkenntnisse:

• Flatten Sie stabile Quellen (On-Prem-Relays, statische Cloud-IPs) aggressiv.
• Lassen Sie volatile ESPs als Includes oder isolieren Sie sie hinter einer delegierten Subdomain wie mail-out.example.com, die der Root mit einem einzigen Lookup includet.
• Behandeln Sie Flattening niemals als einmalige Angelegenheit – es benötigt kontinuierliche Neuauflösung.

Re-Flattening mit AutoSPF automatisieren

Die Schritte 1–7 jedes Mal von Hand auszuführen, wenn ein Anbieter IPs ändert, ist nicht realistisch. Genau dafür ist der automatisierte SPF-Flattening-Dienst von AutoSPF gebaut. Er führt den obigen deterministischen Flattening-Algorithmus kontinuierlich aus: Er scannt Ihre Includes alle 15 Minuten neu, und wenn sich die IPs eines vorgelagerten Anbieters ändern, aktualisiert er Ihren veröffentlichten Eintrag automatisch über die API Ihres DNS-Anbieters – mit atomaren Swaps, gestaffelten TTLs und Ein-Klick-Rollback, falls eine Canary-Prüfung fehlschlägt.

Entscheidend ist, dass AutoSPF zu genau denselben IPs auflöst, zu denen auch Ihre Includes auflösen – es weitet die Autorisierung nie durch überbreite CIDR-Zusammenführungen aus, sodass Sie nicht versehentlich Absender autorisieren, die Sie nicht beabsichtigt haben. Sie behalten einen kleinen, stabilen Eintrag am Root; AutoSPF hält ihn im Hintergrund korrekt.

Um zu entscheiden, welche Ihrer Quellen Sie flatten und welche Sie delegieren sollten, siehe unseren Leitfaden zu den besten SPF-Flattening-Tools. Wenn Sie das Fest-Codieren von IPs lieber ganz vermeiden möchten, vergleichen Sie die Ansätze in SPF Flattening vs. Makros. Und bevor Sie flatten, lohnt es sich zu bestätigen, dass die Änderung Ihre anderen Authentifizierungseinträge nicht stört – siehe beeinflusst SPF Flattening DKIM und DMARC.

Häufig gestellte Fragen

Bricht das Flatten eines SPF-Eintrags DKIM oder DMARC?

Nein, wenn es korrekt gemacht wird. Flattening ändert nur, welche IPs SPF autorisiert – es berührt weder DKIM-Signaturen noch die DMARC-Ausrichtung. Das Risiko ist indirekt: Wenn ein veralteter geflatteter Eintrag beginnt, für legitime Mail an SPF zu scheitern, kann das die DMARC-Passraten nach unten ziehen. Halten Sie den Eintrag neu aufgelöst, und beide bleiben gesund.

Wie viele DNS-Lookups verwendet ein geflatteter SPF-Eintrag?

Ein vollständig geflatteter Eintrag verwendet zum Auswertungszeitpunkt null DNS-Lookups, weil jede autorisierte IP explizit als ip4:/ip6: aufgeführt ist. Wenn Sie einige volatile Includes beibehalten oder IPs in Helfer-Labels aufteilen, fügt jedes davon einen Lookup hinzu – halten Sie die Gesamtzahl einfach bei oder unter dem RFC-7208-Limit von 10.

Kann ich ptr- und exists-Mechanismen flatten?

Im Allgemeinen nein. ptr ist veraltet, langsam und sollte einfach entfernt werden. exists: stützt sich in der Regel auf Laufzeit-Makros (die MAIL FROM oder HELO zum Prüfzeitpunkt auswerten), sodass es nicht auf eine statische IP-Liste reduziert werden kann. Lassen Sie exists unverändert oder isolieren Sie es auf eine delegierte Subdomain, um seine Lookup-Auswirkung zu begrenzen.

Wie oft muss ein geflatteter SPF-Eintrag aktualisiert werden?

So oft, wie Ihre Absender ihre IPs ändern. Interne Mailserver können wochenlang stabil sein, aber große ESPs und CDNs können ihre Adressen täglich ändern. Deshalb ist manuelles Flattening fragil und AutoSPF scannt alle 15 Minuten neu und veröffentlicht automatisch einen aktualisierten Eintrag, sobald sich ein vorgelagertes IP-Set ändert.

Was passiert, wenn mein geflatteter Eintrag zu groß wird?

DNS-TXT-Einträge sind auf 255 Zeichen pro String begrenzt, und übergroße Einträge riskieren UDP-Fragmentierung. Wenn die geflattete IP-Liste zu groß ist, teilen Sie sie in Helfer-Labels auf (die jeweils nur ip4/ip6-Einträge enthalten) und includen Sie diese vom Haupteintrag, oder delegieren Sie volatile Anbieter an eine Subdomain. Zielen Sie darauf ab, die Gesamtantwort unter ~900 Bytes und die Lookups bei ≤ 10 zu halten.

Sollte ich meinen SPF-Eintrag manuell flatten oder ein Tool verwenden?

Manuelles Flattening funktioniert für eine einmalige Lösung, aber es kann mit Anbietern, die IPs rotieren, nicht Schritt halten – ein von Hand geflatteter Eintrag de-autorisiert stillschweigend Absender, sobald sich ein vorgelagerter Bereich ändert. Ein verwaltetes Tool wie AutoSPF übernimmt die rekursive Auflösung, Deduplizierung, Größenverwaltung und kontinuierliches Re-Flattening für Sie, weshalb es der empfohlene Ansatz für alles ist, was über einen einzelnen statischen Absender hinausgeht.