SPF-Flattener — Lookups zählen, verschachtelte Includes auflösen, einen flachen Record erzeugen
Geben Sie eine Domain ein. Der Browser löst den am Apex veröffentlichten SPF-Record auf, folgt rekursiv jedem include-, a-, mx-, redirect- und exists-Mechanismus über DNS over HTTPS, zählt die gesamten DNS-Lookups gegen das RFC-7208-Limit von 10, zählt Void-Lookups gegen das separate Limit von 2 und erzeugt eine geflachte Version mit allen Mechanismen aufgelöst zu direkten ip4- und ip6-Adressen. Sie sehen den Originalrecord, die Lookup-Mathematik, die geflachte Ausgabe zur Veröffentlichung und Warnungen, wenn das Ergebnis 255 Zeichen pro TXT-String oder insgesamt 450 Zeichen überschreitet. Kein Konto, keine Rate-Limits; die gesamte Auflösung läuft in Ihrem Browser.
SPF-Record einer Domain flach machen
Geben Sie eine Domain ein. Die Abfrage läuft in Ihrem Browser über Cloudflares DNS over HTTPS. Große rekursive Includes können einige Sekunden dauern.
DNS over HTTPS via cloudflare-dns.com · Keine Daten an unsere Server gesendet
SPF-Flattening ersetzt jeden DNS-abfragenden Mechanismus in Ihrem Record durch die IP-Adressen, zu denen diese Mechanismen auflösen — verwandelt eine Kette verschachtelter Lookups in eine statische IP-Liste
RFC 7208 — die SPF-Spezifikation — setzt ein hartes Limit von 10 DNS-Lookups während der Evaluation eines einzelnen SPF-Records. Die lookup-konsumierenden Mechanismen sind include:, a, mx, ptr, exists und der Modifikator redirect=. Die Mechanismen, die keinen Lookup konsumieren, sind ip4:, ip6: und all. Receiver müssen einen permerror-Result zurückgeben, wenn die Evaluation 10 Lookups überschreitet — unabhängig davon, wie syntaktisch korrekt der Rest des Records ist. Ein separates, seltener zitiertes Limit deckelt „Void-Lookups" — DNS-Abfragen, die NXDOMAIN oder eine leere Antwort liefern — auf 2 pro Evaluation; das Überschreiten produziert ebenfalls permerror.
Die Arithmetik wird mit realen Versender-Stacks schnell unbarmherzig. Google Workspace allein verbraucht beim Expandieren seiner verschachtelten Includes rund 4 Lookups; Microsoft 365 (spf.protection.outlook.com) fügt 2 hinzu; SendGrid fügt 1 hinzu; Mailchimp transaktional und Marketing fügen 3+ hinzu; Salesforce fügt 2+ hinzu; HubSpot fügt 1-2 hinzu. Ein Unternehmen, das Google + einen transaktionalen Anbieter + eine Marketing-Plattform + ein CRM + ein bis zwei Nischen-Tools betreibt, landet leicht bei 12-14 Lookups. Der Record sieht sauber aus — ein halbes Dutzend include:-Einträge — aber jeder Receiver, der ihn evaluiert, gibt permerror zurück, jede DMARC-Alignment-Prüfung scheitert auf dem SPF-Bein, und die Inbox-Platzierung verschlechtert sich bei Gmail, Outlook und Yahoo gleichzeitig. Der Fehler ist still: Kein Bounce erklärt „SPF too many lookups" in Klartext, und Operatoren finden ihn meist erst beim Ausführen eines Checks wie dem oben.
Flattening löst das Lookup-Problem durch Vor-Auflösung jedes abfragenden Mechanismus zum Zeitpunkt der Record-Veröffentlichung. Das Tool durchläuft die TXT jedes Includes, folgt verschachtelten Includes rekursiv, sammelt jede gefundene ip4:- und ip6:-Adresse und schreibt Ihren SPF als flache Liste neu. Ergebnis: ein Record mit null include:-Mechanismen (oder einer kleinen Zahl, wenn Sie strategisch ein bis zwei behalten) und einer langen Liste von IP-Literalen. Die Lookup-Zahl sinkt auf 1 — nur der SPF-Wurzel-Lookup selbst — und Receiver evaluieren den gesamten Record, ohne je die 10-Lookup-Decke zu berühren.
Der Kompromiss ist Wartung. Wenn Google einen neuen Versandbereich zu _spf.google.com hinzufügt, übernimmt Ihr lebendiges include:_spf.google.com die Änderung automatisch; Ihr geflachter Record nicht. Große Anbieter aktualisieren ihre veröffentlichten IP-Bereiche still und nach eigenem Zeitplan — typisch ein paar Mal pro Jahr für die großen, häufiger für kleinere Dienste. Ein veralteter geflachter Record bedeutet, dass legitime Post von einer neu eingeführten Anbieter-IP anfängt, SPF zu scheitern, was DMARC-Alignment scheitert, was Inbox-Verschlechterung bedeutet. Die Disziplin ist: flachen, wenn nötig, monatlich überwachen, wieder flachen, wenn der nächste Check Drift offenbart.
Im DACH-Kontext verstärkt der regulatorische Rahmen die operative Bedeutung. Der BfDI und die Datenschutzkonferenz (DSK) haben in ihren Hinweisen 2024-2025 Domain-Authentifizierung als angemessene technische Maßnahme nach Art. 32 DSGVO und §22 BDSG-neu eingeordnet. Ein anhaltender SPF-permerror, der monatelang besteht und den jeder B2B-Auditor in Sekunden erkennt, schwächt das Argument für angemessene Maßnahmen. Für deutsche Mittelständler unter B2B-Audit, eine Schweizer Bank unter dem revidierten DSG und der FINMA-Aufsicht, oder einen österreichischen Anbieter unter der DSB ist das Halten von SPF unter dem 10-Lookup-Limit und DMARC im Enforcement Teil des angemessenen Mindeststandards, den ein Sicherheits-Auditor zu sehen erwartet.
Jeder Mechanismus in einem SPF-Record, wie viele Lookups er kostet und worauf zu achten ist
include:domain Mindestens 1 Lookup plus alle verschachtelten Lookups innerhalb dieses inkludierten Records. Die häufigste Überlaufursache. Jeder große SaaS-Anbieter publiziert seinen eigenen SPF, und diese Records verschachteln oft weitere 2-4 Includes.
a · a:domain 1 Lookup. Löst den A/AAAA-Record der Domain auf (oder der SPF-Record-Domain bei nacktem a). Ersetzen Sie mit ip4: oder ip6:, wenn die IP bekannt ist.
mx · mx:domain 1 Lookup für den MX-Record, dann 1 zusätzlicher Lookup pro MX-Server zur IP-Auflösung. Eine Domain mit 3 MX-Servern verbraucht 4 Lookups für einen einzelnen mx-Mechanismus.
redirect=domain 1 Lookup plus alle Lookups innerhalb des umgeleiteten Records. Verhält sich wie ein vollständiger SPF-Ersatz. Die Kombination von redirect mit anderen Mechanismen ist nach RFC 7208 technisch ungültig.
exists:domain 1 Lookup. Testet, ob ein Domainname überhaupt auflöst. Selten in modernen Versendern; in Macro-basiertem SPF für empfängerbezogene Evaluation verwendet.
ptr · ptr:domain 1 Lookup, aber RFC 7208 rät explizit von ptr wegen Performance- und Zuverlässigkeitsproblemen ab. Entfernen Sie es. Immer.
ip4:adresse · ip6:adresse 0 Lookups. Statisches IP-Literal — das Flattening-Ziel. Akzeptiert sowohl einzelne Adressen als auch CIDR-Bereiche.
all · -all · ~all · ?all · +all 0 Lookups. Endgültige Disposition: -all harter Fehler, ~all weicher Fehler (am häufigsten), ?all neutral, +all alles bestanden (deaktiviert SPF effektiv — nie verwenden). Immer der letzte Mechanismus im Record.
Flattening ist einer von fünf vernünftigen Ansätzen, um unter 10 Lookups zu bleiben. Die richtige Wahl hängt davon ab, wie oft sich Ihr Versand-Stack ändert
1. Entfernen Sie, was Sie nicht nutzen
Immer der erste Schritt. Die meisten SPF-Records tragen Includes für Dienste, die das Unternehmen vor sechs Monaten getestet und nie abgeschaltet hat. Mailgun, Postmark, dieses ESP, das jemand evaluierte und nie migrierte — entfernen. Der sauberste Record ist der, der nur autorisiert, was heute tatsächlich sendet.
2. Ersetzen Sie mx und a mit direkten IPs
Sind Ihre Mailserver-IPs stabil — was sie für selbst gehostetes Postfix oder eine gehostete MTA typisch sind — ersetzen Sie mx- und a-Mechanismen durch ip4:-Literale. Ein einzelner mx-Mechanismus kann verschachtelt 4+ Lookups verbrauchen. Direkte IPs verbrauchen null. Der Kompromiss: Überwachung beim Re-IPing.
3. Alles flachen (dieses Tool)
Die nukleare Option. Ersetzen Sie jedes include: durch die IPs, zu denen es heute auflöst, drücken Sie die Lookup-Zahl auf 1 und akzeptieren Sie die monatliche Wartungsbürde. Richtig für Versender mit stabilem Anbieter-Stack (Google + 1-2 SaaS), falsch für Versender, die ständig neue Tools evaluieren.
4. Subdomain-Delegation
Verschiedene Versendertypen über verschiedene Subdomains routen: transaktional von tx.beispiel.de, Marketing von mkt.beispiel.de, intern von mail.beispiel.de. Jede Subdomain hat ihren eigenen SPF-Record, jeder bleibt unter 10 Lookups, und der Apex trägt nur die kritischsten Versender.
5. Hosted SPF (AutoSPF, EasySPF, PowerSPF)
Ersetzen Sie Ihren SPF durch einen einzigen Include, der auf einen gehosteten Dienst zeigt. Diese lösen und aktualisieren Ihre Anbieter-IPs kontinuierlich, Sie pflegen einen einzeiligen SPF, und Sie zahlen eine Monatsgebühr ($10-$30/Monat bei typischen SMB-Volumen). Richtig für Teams, die häufig Anbieter wechseln und die Wartung auslagern wollen.
Flattening behebt permerror. Es behebt nicht DMARC-Alignment, DKIM-Signierung oder BIMI-Berechtigung — das sind separate Probleme auf demselben Record-Set
Ein SPF-Record mit null Lookups scheitert immer noch DMARC, wenn die Envelope-Sender-Domain nicht mit der From-Header-Domain alignieren. Ein flacher SPF-Record ist immer noch nutzlos ohne DKIM-Signierung, weil DMARC verlangt, dass entweder SPF oder DKIM besteht und aligned. Das richtige mentale Modell: SPF autorisiert IPs zum Versand für Ihre Domain, DKIM beweist, dass die Nachricht nicht manipuliert wurde, DMARC orchestriert beides mit Policy. SPF-Lookups zu beheben holt Sie aus dem permerror-Fehlermodus heraus; es bringt Sie nicht allein zur Enforcement-Authentifizierung.
Die längere Arbeit — die, für die unsere gemanagten Kunden uns engagieren — ist der Rollout von keiner Authentifizierung zu DMARC p=reject: Aggregate-Reports einlesen, um jeden legitimen Versender zu identifizieren, SPF- und DKIM-Alignment für jeden zu beheben, die richtige Subdomain-Delegation einzurichten und die Kette Ende-zu-Ende zu validieren, bevor Enforcement erklärt wird.
Was Teams beim ersten Ausführen des SPF-Flatteners fragen
Wie oft muss ich neu flachen?
+
Einmal im Monat ist die operativ ehrliche Antwort. Große Anbieter — Google, Microsoft, SendGrid — aktualisieren ihre veröffentlichten SPF-Bereiche einige Male im Jahr, oft ohne öffentliche Ankündigung. Kleinere Anbieter aktualisieren häufiger. Ein geflachter Record, der im Januar perfekt funktionierte, beginnt im März legitime Post fallen zu lassen, wenn einer der Anbieter eine neue Versandregion hinzufügt. Die in der Praxis funktionierende Disziplin: setzen Sie eine monatliche Kalendererinnerung, lassen Sie den Flattener laufen, vergleichen Sie die neue Ausgabe mit dem aktuell Veröffentlichten, aktualisieren Sie bei Änderungen.
Kann ich den Microsoft-365-Include flachen? Den von Google Workspace?
+
Technisch ja, operativ für diese beiden nicht empfohlen. Microsoft und Google aktualisieren ihre Versand-IP-Bereiche nach eigenem Zeitplan und mit höherer Frequenz als kleinere Anbieter. Ein zwei Monate alter geflachter Microsoft-365-Include hat eine nicht-triviale Chance, neu hinzugefügte Versand-IPs zu verpassen und legitime Post Ihres Tenants SPF scheitern zu lassen. Die Microsoft-Dokumentation empfiehlt, include:spf.protection.outlook.com in Ihrem Top-Level-SPF zu behalten und seltener aktualisierte Includes drumherum zu flachen. Google publiziert eine ähnliche Empfehlung. Das funktionierende Muster: behalten Sie die 1-2 großen Anbieter-Includes lebendig, flachen Sie alles andere, und landen Sie bei 3-4 Lookups insgesamt statt 12-14.
Was ist ein „Void-Lookup" und wie vermeide ich das Limit von 2?
+
Ein Void-Lookup ist eine DNS-Abfrage, die keinen Record liefert — entweder NXDOMAIN (die Domain existiert nicht) oder leere Antwort (die Domain existiert, aber kein Record dieses Typs). RFC 7208 deckelt diese auf 2 pro SPF-Evaluation; der dritte Void-Lookup erzeugt einen permerror, unabhängig davon, wie viele reguläre Lookups Sie haben. Die üblichen Quellen: ein include:, das auf eine stillgelegte Domain zeigt (der SaaS wurde abgeschaltet, die Subdomain gelöscht), ein a- oder mx-Mechanismus für einen Hostname, der nicht mehr auflöst, oder ein ptr-Mechanismus. Der Flattener oben markiert jeden Void-Lookup, den er bei der Auflösung trifft.
Bricht Flattening mein DMARC-Alignment?
+
Nein — Flattening betrifft nur die Lookup-Zahl, nicht die Alignment-Mathematik. DMARC-Alignment hängt davon ab, ob die Envelope-Sender-Domain (das MAIL FROM, für SPF verwendet) zur From-Header-Domain passt. Ein geflachter SPF-Record autorisiert dieselben IPs wie das Original; wenn Ihre Post vorher SPF-Alignment bestand, besteht sie danach auch. Was brechen kann, ist DMARC-Pass insgesamt, nicht Alignment speziell — wenn die IP eines Anbieters nach dem Flachen ändert und Ihr Record veraltet, beginnt die Post dieses Anbieters SPF-Authentifizierung direkt zu scheitern.
Können mehrere SPF-Records kombiniert werden?
+
Nein — RFC 7208 verbietet explizit mehrere SPF-Records auf derselben Domain. Hat eine Domain zwei oder mehr TXT-Records beginnend mit v=spf1, behandeln Receiver die Konfiguration als ungültig und geben permerror zurück, indem sie beide Records ignorieren. Das ist einer der häufigsten SPF-Fehler, die wir sehen: ein Security-Tool veröffentlicht einen neuen Record, ohne den bestehenden zu entfernen, und SPF bricht still über die gesamte Domain. Die Behebung ist Konsolidierung. Kombinieren Sie die Mechanismen jedes Records in einen einzelnen TXT-Record beginnend mit v=spf1, löschen Sie die anderen, warten Sie auf DNS-Propagation (typisch 24 Stunden) und verifizieren Sie mit einem frischen Lookup.