Lösung der SPF 10-Lookup-Grenze: Ein technischer Leitfaden für MSPs

Zusammenfassung Jeder SPF-Eintrag einer Domain ist auf 10 DNS-Lookups begrenzt – eine Einschränkung aus dem Jahr 2006, die mit heutigen SaaS-Landschaften nicht mehr Schritt hält. Für MSPs, die Dutzende Kundendomains mit jeweils eigener Mischung aus E-Mail-, Marketing-, Abrechnungs- und Support-Tools verwalten, ist das Überschreiten dieses Limits fast unvermeidbar. Passiert es, scheitern legitime E-Mails stillschweigend bei der Authentifizierung, DMARC-Alignment geht verloren und Support-Tickets häufen sich. Dieser Leitfaden erklärt MSPs die Hintergründe der Lookup-Grenze, wie der Check von Kundendomains im großen Maßstab funktioniert, warum klassische Lösungen wie „Flattening“ und Subdelegation nicht ausreichen und wie Dynamic SPF die Einschränkungen vollständig beseitigt – sodass SPF-Management von einer reaktiven Brandbekämpfung zu einem automatisierten, skalierbaren Service wird.

Wichtigste Erkenntnisse

• Jeder SPF-Mechanismus wie include, a, mx, redirect, exists und ptr zählt zum 10-Lookup-Limit – verschachtelte Includes in Drittanbieter-Einträgen verbrauchen versteckte Lookups, die bei manueller Prüfung leicht übersehen werden.
• Ein typischer Mittelstandskunde mit sieben oder mehr genutzten SaaS-Tools befindet sich bereits am Limit – eine einzige neue Anwendung kann eine PermError auslösen und die Zustellung ohne Vorwarnung verhindern.
• Google und Microsoft erzwingen mittlerweile explizit die SPF-Konformität für Großversender. Damit ist die Lookup-Grenze eine Zustellbarkeitsvoraussetzung statt einer Best Practice.
• SPF-Flattening schafft Pflegeaufwand, weil Cloud-Anbieter ihre Versende-IPs regelmäßig rotieren und geflattete Einträge so schnell veralten.
• Dynamic SPF fasst alle autorisierten Versender in einem einzigen, automatisch aktualisierten Include zusammen, der immer unter dem Limit bleibt, egal wie viele Dienste beim Kunden laufen.
• MSPs sollten jede Kundendomain bei der Aufnahme prüfen, ab 8+ Lookups als risikobehaftet kennzeichnen und die Auflösung des SPF-Limits als Voraussetzung sehen, um Kunden von DMARC-Monitoring hin zu vollständiger Durchsetzung zu führen.

Ein Kunde integriert HubSpot in seinen Marketing-Stack. Eine Woche später landen die Rechnungen des CFO im Spam. Das Support-Ticket folgt. Die Ursache: ein Problem, das nie auf einer Onboarding-Checkliste stand – der SPF-Eintrag des Kunden hat gerade seine zehnte DNS-Abfrage überschritten, wodurch eine permanente Authentifizierungsstörung ausgelöst wird, die keine Postfach-Fehlersuche mehr reparieren kann. Für MSPs, die Dutzende Kundendomains mit unterschiedlichen E-Mail-Diensten, CRM-Plattformen und Support-Tools betreuen, wiederholt sich dieses Szenario immer häufiger. 

Plattformen wie Red Sift OnDMARC lösen das Problem mit Dynamic SPF, das die Lookup-Beschränkung vollständig eliminiert. Doch zu verstehen, warum das Limit existiert, wie es gebrochen wird und warum klassische Workarounds scheitern, ist essenzielles Wissen für MSPs, die eine DMARC-Praxis aufbauen wollen.

Dieser Leitfaden erklärt die SPF 10-Lookup-Grenze praxisnah, geht auf typische Workarounds und ihre Schwächen ein und stellt automatisierte Ansätze vor, mit denen MSPs E-Mail-Authentifizierung portfolioweit ohne diese Hürde skalieren können.

• Was die SPF 10-Lookup-Grenze wirklich bedeutet
• Warum MSPs das Limit öfter als alle anderen begegnen
• Wie man den SPF-Eintrag eines Kunden prüft
• Klassische Workarounds und warum sie scheitern
• Dynamic SPF: Die automatisierte Lösung
• Ein SPF-Management-Workflow für Ihr MSP
• FAQ

SPF (Sender Policy Framework) erlaubt Domain-Inhabern, zu deklarieren, welche Mailserver berechtigt sind, im Namen ihrer Domain E-Mails zu versenden. Empfangsserver prüfen den SPF-Eintrag der absendenden Domain und verifizieren, ob die absendende IP-Adresse zugelassen ist. Das Protokoll ist effektiv, hat aber eine hart festgelegte Grenze gemäß RFC 7208: Eine SPF-Prüfung darf nicht mehr als 10 Mechanismen oder Modifikatoren erfordern, die zusätzliche DNS-Lookups auslösen [1].

Diese Limitierung schützt die DNS-Infrastruktur. Andernfalls könnte ein fehlerhafter oder böswilliger SPF-Eintrag unkontrollierte DNS-Query-Ketten erzeugen, Ressourcen beim Empfänger verbrauchen und Denial-of-Service-Bedingungen schaffen. Das Limit hält die Evaluation vorhersehbar und kontrollierbar.

Ein kritisches Detail: Gezählt wird die Zahl der Mechanismen, die Lookups erfordern, nicht die Gesamtzahl der ausgelösten DNS-Abfragen [2]. Ein mx-Mechanismus zählt einmal zum Limit, auch wenn er zur Adressauflösung mehrere Folgeabfragen erzeugt. Dieser Unterschied ist beim Optimieren relevant, weil der Ersatz von mx durch ip4-Einträge einen Lookup spart – unabhängig von der Zahl der MX-Records der Domain.

Überschreitet ein Empfängerserver beim Prüfen die 10-Lookup-Grenze, antwortet er mit PermError, einem permanenten SPF-Fehler. Die Folge hängt vom Empfänger ab: Manche lehnen die Mail ab, andere verschieben sie in den Spamordner, manche bewerten sie neutral. In jedem Fall bricht DMARC-Alignment, wenn SPF der einzige gültige Mechanismus ist – was Quarantäne oder Ablehnen nach sich ziehen kann.

Die SPF-Lookup-Grenze wurde 2006 definiert, in RFC 7208 (2014) festgeschrieben – damals nutzten die meisten Unternehmen ein oder zwei E-Mail-Dienste. Heute sieht das SaaS-Umfeld völlig anders aus. Ein einzelner Mittelstandskunde braucht meist SPF-Includes für:

• E-Mail-Plattform (Google Workspace oder Microsoft 365)
• Marketing Automation (HubSpot, Marketo oder Mailchimp)
• CRM-System (Salesforce)
• Support-Desk (Zendesk oder Freshdesk)
• Abrechnung & Buchhaltung (QuickBooks, Xero)
• HR und Recruiting (Greenhouse, BambooHR)
• Transaktions-E-Mail (SendGrid oder Amazon SES)

Jeder dieser Dienste erfordert meist einen eigenen Include-Mechanismus im SPF-Eintrag der Domain. Sieben Services ergeben sieben Lookups – ohne a- oder mx-Mechanismen der Domain selbst. Kommt ein weiteres Tool hinzu, ist das Limit überschritten.

Für MSPs verschärft sich das Problem, weil jede Kundendomain eigene Herausforderungen mitbringt. Ein Portfolio mit 30 Domains bedeutet: 30 SaaS-Kombinationen, 30 SPF-Einträge, 30 potenzielle Schwachstellen. Sobald IT- oder Marketingteams des Kunden einen Dienst hinzufügen, ohne den MSP einzubeziehen, kann der SPF unbemerkt das Limit überschreiten. E-Mails fallen sporadisch durch (da PermError erst beim 11. Lookup greift und nicht jeder Empfänger alle Mechanismen evaluiert), was die Analyse erschwert.

Google verlangt SPF-Konformität bei Organisationen, die täglich mehr als 5.000 Mails versenden [3]. Microsoft hat ähnliche Anforderungen samt expliziter Empfehlung, das SPF-Limit einzuhalten [4]. Für MSPs ist Massenversender-Konformität für alle Kunden, die E-Mail-Kampagnen aufziehen, Pflicht.

Bevor das Problem gelöst werden kann, muss es quantifiziert werden. Ein systematisches Audit zeigt, wie viele Lookups der SPF aktuell erfordert und woher überzählige Einträge stammen.

Schritt-für-Schritt-Audit:

1. SPF-Eintrag abfragen, z. B. mit Red Sift's SPF Checker oder einem DNS-Tool (dig TXT example.com), um den Rohwert abzurufen
2. Include-Kette aufschlüsseln: Jeden Include-Mechanismus rekursiv expandieren. Jeder Include zählt und kann wiederum weitere Includes enthalten
3. Alle lookup-auslösenden Mechanismen zählen – include, a, mx, redirect, exists und ptr
4. Unbenutzte Dienste identifizieren, indem SPF-Includes mit tatsächlich genutzten Mail-Sendern abgeglichen werden. Auch deaktivierte Dienste verbrauchen Lookups
5. Aktuelle Zahl dokumentieren und jede Domain ab 8 Lookups als kritisch einstufen (zwei zusätzliche Dienste bis zum Bruch)
6. Tiefe der Verschachtelung prüfen, da Drittanbieter-Einträge oft mehrere Includes enthalten. Ein include:thirdparty.com kann drei oder vier Lookups verschlingen, sobald er vollständig expandiert ist

Ein Portfolio-Audit zeigt das Ausmaß des Problems: Die meisten MSPs sehen, dass ein erheblicher Teil ihrer Kundendomains bereits über dem Limit liegt – oder nur einen Dienst entfernt davon ist.

MSPs, die zum ersten Mal die 10-Lookup-Grenze erreichen, probieren typischerweise mehrere verbreitete Ansätze. Jeder hat Schwächen, die ihn für den Einsatz im großen Maßstab ungeeignet machen.

Flattening ersetzt Include-Mechanismen durch aufgelöste IP-Adressen (ip4- und ip6-Einträge), was die Lookup-Zahl für diese Dienste auf null reduziert. In der Theorie praktikabel, aber in der Praxis scheitert es daran, dass Cloud-Mailprovider ihre Versende-IPs regelmäßig ändern. Ergänzt Google Infrastruktur, wird der geflattete Record sofort veraltet – legitime E-Mails scheitern an der Authentifizierung.

Manuelles Flattening verlangt vom MSP, IP-Ranges sämtlicher Provider laufend zu überwachen und die DNS-Einträge bei jeder Änderung anzupassen. Bei 30 Kundendomains mit verschiedenen Anbietern ist dieser Pflegeaufwand nicht mehr leistbar. Ein verpasster Wechsel führt zu weitreichenden Problemen bei der Zustellung.

Für eine Domain mehr als einen SPF-TXT-Record zu veröffentlichen, widerspricht der Spezifikation [1]. Empfänger müssen in diesem Fall PermError liefern, das heißt: Diese Methode verschlimmert das Problem und löst nicht das Limit.

Wer verschiedene Dienste auf Subdomains (z. B. marketing.example.com, support.example.com) auslagert, verteilt die Lookups auf mehrere Einträge. Die Zahl pro Subdomain sinkt, die Komplexität steigt – DMARC-Alignment, das Setzen von Return-Path und betriebliche Abläufe werden komplex und sind im Portfolio nur schlecht skalierbar.

Manche MSPs registrieren, dass nicht alle Empfänger das Limit strikt durchsetzen. „Scheint zu funktionieren“ – das überzogene Record bleibt bestehen. Das Risiko: Das Verhalten und die Strenge der Durchsetzung variieren und können sich ohne Vorwarnung verschärfen. Sowohl Google als auch Microsoft betonen die SPF-Konformität bei Großversender-Anforderungen, wodurch das Zustellbarkeitsrisiko stetig steigt.

Dynamic SPF verfolgt einen grundlegend anderen Ansatz. Statt die 10-Lookup-Grenze durch manuelles Record-Management einzuhalten, bündelt Dynamic SPF alle autorisierten Versender in einem einzigen, automatisch gepflegten Include, das immer unter dem Schwellenwert bleibt.

So funktioniert es:

1. Kontinuierliches Monitoring: Die Plattform beobachtet IP-Bereiche aller autorisierten Dienste (z. B. Google Workspace, Microsoft 365, Salesforce, HubSpot) in Echtzeit
2. Intelligente Konsolidierung: Domain-basierte Includes werden auf aktuelle IP-Adressen aufgelöst und in einem optimierten Record zusammengefasst
3. Automatische Updates: Wenn ein Provider seine Infrastruktur ändert, aktualisiert sich der Dynamic SPF-Record binnen Minuten – ohne manuelle DNS-Eingriffe
4. Nur ein Include: Der SPF-Eintrag des Kunden verweist auf einen Dynamic SPF-Include, was unabhängig von der Zahl autorisierter Dienste nur einen Lookup kostet

Der Effekt: MSPs können beliebig neue E-Mail-Dienste beim Kunden hinzufügen, ohne die Lookup-Zahl zu fürchten. Ein Kunde mit 15 Diensten verursacht denselben einen Lookup wie ein Kunde mit drei. Die technische Hürde, die DMARC-Durchsetzung bislang verhinderte, entfällt.

Für MSPs, die DMARC-Plattformen prüfen, sollte die Dynamic-SPF-Fähigkeit ein zentrales Auswahlkriterium sein. Die Protokollunterschiede zwischen SPF, DKIM und DMARC sind relevant, aber die praktische Frage ist, ob die Plattform das Lookup-Limit für alle Kunden bewältigen kann.

Für eine einzelne Domain ist die Lösung der SPF-Lookup-Grenze einfach. Im ganzen Portfolio braucht es einen klaren Prozess.

Empfohlener MSP-Workflow:

1. Portfolio-Audit: Führen Sie Prüfungen für alle Kundendomains beim Onboarding durch. Jede Domain ab 8 Lookups als kritisch einstufen
2. Nach Auswirkung priorisieren: Erst Domains über dem Limit beheben, dann die kritischen. Kunden mit DMARC p=quarantine oder p=reject haben höchst-priorität, weil SPF-Fehler direkt die Zustellung verhindern
3. Dynamic SPF einsetzen: Kundendomains auf eine Plattform mit Dynamic SPF umziehen. Das MSP-Partnerprogramm von Red Sift bietet Multi-Tenant-Infrastruktur, speziell für MSPs mit vielen Domains
4. Change Control etablieren: Prozess einrichten, der das Hinzufügen neuer E-Mail-Dienste über das MSP laufen lässt, damit Kundenteams nicht durch neue SaaS-Tools SPF brechen
5. Dauerhaftes Monitoring: Automatisiertes Alerting nutzen, um neue Versender, Konfigurationsabweichungen oder SPF-Fehler frühzeitig zu erkennen
6. Kundenberichterstattung: SPF-Gesundheit, Authentifizierungsraten, Versender-Inventar und Lookup-Auslastung regelmäßig im Reporting ausweisen

MSPs, die diesen Workflow etablieren, senken den Pflegeaufwand pro Domain erheblich. Anfangs sind Audit und Migration Arbeit – danach läuft die Betreuung automatisiert statt reaktiv.

SPF-Management ist natürlicher Bestandteil gestaffelter DMARC-Servicepakete. Das Lookup-Limit ist oft der technische Haken, der Kunden vom Monitoring (p=none) an voller Durchsetzung (p=reject) hindert. Die Lösung von SPF-Problemen im Portfolio macht den Weg frei für vollständige Durchsetzung – das ist die höchste Wertstufe im Managed E-Mail-Authentifizierungsservice.

[1] Kitterman, S. „Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1.“ IETF RFC 7208, 2014. https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

[2] Mailhardener. „The SPF lookup limit explained.“ Mailhardener Blog, 2024. https://www.mailhardener.com/blog/spf-lookup-limit-explained

[3] Google. „Email sender guidelines.“ Google Workspace Admin Help, 2024. https://support.google.com/a/answer/81126

[4] Microsoft Defender for Office 365 Team. „Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders.“ Microsoft Tech Community, 2025. https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730

Der empfangende Mailserver quittiert das mit einem PermError (permanenter SPF-Fehler). Je nach Policy beim Empfänger und DMARC-Einstellung der Domain kann das dazu führen, dass Nachrichten abgelehnt, im Spam landen oder als nicht authentifiziert gelten. Das Problem tritt nur auf, wenn tatsächlich der 11. Lookup erreicht wird – was je nach Mail und Empfänger variiert.

Flattening ersetzt Include-Mechanismen durch statische IPs und spart Lookups, macht aber viel Aufwand. Cloudprovider rotieren Versende-IPs regelmäßig – geflattete Records veralten schnell und verursachen Authentifizierungsfehler. Bei Einzeldomains noch machbar, ist es im Portfolio mit vielen Anbietern nicht skalierbar.

Dynamic SPF automatisiert Konsolidierung und Wartung. Die Plattform überwacht fortlaufend die IP-Ranges der Anbieter und aktualisiert den SPF-Record selbständig bei Änderungen. Klassisches Flattening ist eine Momentaufnahme, die nachträgliche Pflege verlangt – Dynamic SPF bleibt stets aktuell und braucht keinen manuellen Eingriff.

Google schreibt SPF-Konformität für Absender mit mehr als 5.000 Mails pro Tag vor [3]. Microsoft verlangt explizit, dass Absender das 10-Lookup-Limit einhalten [4]. Beide Plattformen filtern nicht-konforme Mails zunehmend strenger.

Zuerst Domains, die bereits das Limit überschreiten (PermError liefern), dann die mit 8–9 Lookups (nur eins entfernt von Problemen). Innerhalb dieser Gruppen Priorität für Kunden mit DMARC-Durchsetzung (p=quarantine oder p=reject), da SPF-Fehler bei ihnen die sofortige Nicht-Zustellung bedeuten.