Die meisten Unternehmen entdecken SPF-Datensatz-Limits erst, nachdem die Authentifizierung zusammengebrochen ist. Zu diesem Zeitpunkt werden legitime E-Mails bereits abgewiesen, landen im Spam oder schlagen ohne sichtbare Fehlermeldungen fehl. Das Limit von 10 DNS-Abfragen ist keine Empfehlung – es ist eine harte technische Grenze, die die SPF-Auswertung beendet und einen permanenten Fehler zurückgibt, was typischerweise zu einem DMARC-Alignment-Fehler führt, selbst wenn andere Authentifizierungen erfolgreich sind.

Laut aktuellen E-Mail-Authentifizierungs-Benchmarkdaten überschreiten 63 Prozent der Organisationen, die drei oder mehr Drittanbieter-E-Mail-Plattformen nutzen, das SPF-Lookup-Limit innerhalb von 18 Monaten nach der ersten Implementierung. Das Problem ist strukturell: Jeder autorisierte Absender, der über include:-Mechanismen zu SPF hinzugefügt wird, erhöht die Anzahl der DNS-Abfragen, und die meisten Organisationen erreichen das Limit lange bevor sie erkennen, dass sie die Abfragen falsch zählen.

Dieser Artikel erklärt, wie SPF-Lookup-Limits funktionieren, was kaputt geht, wenn Sie sie überschreiten, wie Sie den Fehler erkennen, bevor er die Zustellung beeinträchtigt, und wie Sie SPF umstrukturieren können, um innerhalb der technischen Grenzen zu bleiben und gleichzeitig die Anbieterabdeckung aufrechtzuerhalten.

I. Was ist das SPF-Lookup-Limit?

SPF (Sender Policy Framework) validiert, dass der sendende Mailserver autorisiert ist, E-Mails im Namen einer Domain zu versenden. Der empfangende Server führt DNS-Abfragen durch, um den SPF-Datensatz aufzulösen und die Autorisierungskette zu bewerten. RFC 7208 legt ein hartes Limit von 10 DNS-Abfragen pro SPF-Auswertung fest, um Missbrauch, unendliche Rekursion und DNS-Amplifikationsangriffe zu verhindern.

Wenn eine SPF-Auswertung 10 DNS-Abfragen überschreitet, stoppt der empfangende Server die Verarbeitung und gibt permerror zurück. Dies ist ein permanenter Fehler, keine temporäre Bedingung. Das Ergebnis wird in den meisten Implementierungen als SPF-Fehler behandelt, was bedeutet:

• DMARC-Alignment schlägt fehl, selbst wenn DKIM erfolgreich ist, weil SPF nicht erfolgreich war und nicht ausgerichtet ist.
• Reputation-Signale verschlechtern sich, weil Mailbox-Provider Inkonsistenz in der Authentifizierung sehen.
• Zustellung wird unvorhersehbar, weil einige empfangende Server stillschweigend filtern, andere ablehnen und viele den Fehler nicht in Bounce-Nachrichten anzeigen.

Das Limit ist fix. Es skaliert nicht mit der Domain-Größe, dem E-Mail-Volumen oder der geschäftlichen Komplexität. Das Hinzufügen eines weiteren autorisierten Absenders, wenn Sie bereits bei 10 Abfragen sind, bricht den gesamten SPF-Datensatz.

II. Wie DNS-Abfragen gezählt werden

Die SPF-Lookup-Zählung wird oft missverstanden, weil nicht jeder Mechanismus in einem SPF-Datensatz eine DNS-Abfrage auslöst. Die folgenden Mechanismen zählen zum 10-Lookup-Limit:

• include: – Jeder include:-Mechanismus löst mindestens eine Abfrage aus, und wenn der eingebundene Datensatz zusätzliche include:, a, mx oder ptr-Mechanismen enthält, zählen diese rekursiv.
• a – Fragt den A-Datensatz für die Domain ab.
• mx – Fragt den MX-Datensatz für die Domain ab, und jedes MX-Ziel erfordert eine zusätzliche A-Datensatz-Abfrage.
• ptr – Fragt den PTR-Datensatz ab (veraltet und sollte nicht verwendet werden).
• redirect= – Löst eine Abfrage aus, plus alle Abfragen innerhalb des umgeleiteten Datensatzes.
• exists: – Fragt den A-Datensatz für die angegebene Domain ab.

Die folgenden Mechanismen zählen nicht:

• ip4: – Statische IP-Adresse, keine DNS-Abfrage erforderlich.
• ip6: – Statische IPv6-Adresse, keine DNS-Abfrage erforderlich.
• all – Mechanismus, der die Standardaktion definiert, keine DNS-Abfrage.

Beispiel: Versteckte Lookup-Explosion

Ein scheinbar einfacher SPF-Datensatz kann das Limit schnell überschreiten:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.zendesk.com include:_spf.salesforce.com ~all

Scheinbare Lookup-Anzahl: 5
Tatsächliche Lookup-Anzahl: 12+

Der Grund dafür:

• include:_spf.google.com → 3 Abfragen (Google verwendet verschachtelte Includes)
• include:sendgrid.net → 2 Abfragen
• include:spf.protection.outlook.com → 2 Abfragen
• include:mail.zendesk.com → 2 Abfragen
• include:_spf.salesforce.com → 3 Abfragen

Gesamt: 12 Abfragen. Dieser Datensatz wird permerror zurückgeben und die SPF-Authentifizierung fehlschlagen lassen.

Organisationen nehmen oft an, dass fünf include:-Anweisungen gleich fünf Abfragen sind. Das stimmt nicht. Jede eingebundene Domain kann sich in mehrere verschachtelte Abfragen erweitern, und diese zählen zur Gesamtzahl.

III. Was kaputt geht, wenn Sie das Limit überschreiten

1. SPF gibt permerror zurück

Wenn der empfangende Server das 10-Lookup-Limit erreicht, stoppt die SPF-Auswertung und gibt permerror zurück. Dies wird im Authentication-Results-Header protokolliert als:

spf=permerror (too many DNS lookups)

Die E-Mail profitiert nicht von der SPF-Authentifizierung. Wenn DKIM nicht vorhanden ist oder nicht ausgerichtet ist, schlägt DMARC fehl.

2. DMARC-Alignment schlägt fehl

DMARC erfordert, dass entweder SPF oder DKIM erfolgreich ist und mit der From:-Domain ausgerichtet ist. Wenn SPF permerror zurückgibt, kann es nicht ausgerichtet werden. Wenn DKIM fehlt, nicht signiert oder falsch ausgerichtet ist, schlägt DMARC vollständig fehl.

Bei p=quarantine oder p=reject bedeutet dies, dass die E-Mail gefiltert oder blockiert wird. Bei p=none ist der Fehler unsichtbar, wird aber dennoch in aggregierten Berichten aufgezeichnet, was die Reputation im Laufe der Zeit verschlechtert.

3. Stille Filterung

Nicht alle Mailbox-Provider lehnen E-Mails mit SPF permerror ab. Einige stufen die Zustellung stillschweigend herab:

• Die E-Mail landet im Spam statt im Posteingang.
• Die E-Mail wird verzögert oder gedrosselt.
• Die E-Mail wird zugestellt, aber im Mail-Client des Empfängers als potenziell verdächtig gekennzeichnet.

Da der Fehler still ist, erkennen Organisationen oft nicht, dass SPF defekt ist, bis die Beschwerderate steigt, das Engagement sinkt oder eine wichtige Kampagne fehlschlägt.

4. Anbieterspezifische Auswirkungen

Die Auswirkung variiert je nach Anbieter:

• Gmail: Behandelt permerror als Fehlersignal, kann aber dennoch zustellen, wenn DKIM erfolgreich ist und die Domain-Reputation stark ist. Allerdings verschlechtert sich die Posteingangsplatzierung im Laufe der Zeit.
• Microsoft 365: Behandelt permerror als SPF-Fehler. Wenn DKIM nicht ausgerichtet ist, wird die E-Mail je nach Richtlinie und Reputation gefiltert oder abgelehnt.
• Yahoo, AOL: Strikte Durchsetzung. permerror führt oft zur Ablehnung oder Spam-Filterung.
• Mailinglisten, Forwarder: SPF bricht während der Weiterleitung, weil der Envelope-Absender nicht ausgerichtet ist. Wenn der ursprüngliche SPF-Datensatz bereits permerror ist, hat die weitergeleitete E-Mail keine Authentifizierungsabdeckung.

5. DMARC-Berichte zeigen den Fehler

Wenn Ihre DMARC-Richtlinie auf p=none mit aktivierter aggregierter Berichterstattung gesetzt ist, sehen Sie permerror im spf-Ergebnisfeld der DMARC-Aggregatberichte. Der Bericht zeigt:

<auth_results>
  <spf>
    <domain>example.com</domain>
    <result>permerror</result>
  </spf>
</auth_results>

Der Fehler wird aufgezeichnet, aber wenn Sie DMARC-Berichte nicht aktiv überprüfen, werden Sie ihn nicht sehen. Deshalb überschreiten viele Organisationen das SPF-Limit, ohne es zu bemerken, bis Zustellungsprobleme auftreten.

IV. Wie Sie die SPF-Lookup-Anzahl erkennen, bevor sie kaputt geht

Manuelle SPF-Lookup-Zählung

Sie können SPF-Lookups manuell zählen, indem Sie jeden include:-Mechanismus rekursiv erweitern und alle aufgetretenen include:, a, mx, redirect= und exists:-Mechanismen zusammenzählen.

Schrittweiser Prozess:

1. Fragen Sie Ihren SPF-Datensatz ab:

   dig TXT example.com

2. Für jeden include:-Mechanismus fragen Sie die eingebundene Domain ab:

   dig TXT _spf.google.com
   dig TXT sendgrid.net

3. Zählen Sie alle Mechanismen, die DNS-Abfragen im primären Datensatz und allen verschachtelten Datensätzen auslösen.

Dieser Prozess ist zeitaufwändig und fehleranfällig, besonders wenn Anbieter ihre SPF-Datensätze ohne Vorankündigung ändern.

Automatisierte SPF-Lookup-Validierung

Verwenden Sie einen SPF-Datensatz-Checker, der automatisch DNS-Abfragen zählt und identifiziert, welche Mechanismen zur Gesamtzahl beitragen. Tools wie:

• Skysnag Domain Checker – Scannt Ihre Domain, zählt SPF-Lookups und kennzeichnet Datensätze, die das 10-Lookup-Limit überschreiten oder sich diesem nähern.
• dig + manuelle Rekursion (technisch, aber umfassend).
• Drittanbieter-SPF-Validatoren (variieren in der Genauigkeit; einige zählen verschachtelte Lookups nicht korrekt).

Skysnag Domain Checker zeigt:

• Aktuelle Lookup-Anzahl
• Welche include:-Mechanismen sich in mehrere Lookups erweitern
• Ob der Datensatz bereits permerror ist
• Empfehlungen für Flattening oder Umstrukturierung

V. Wie Sie SPF-Lookup-Limit-Probleme beheben

1. Ersetzen Sie include: durch ip4: oder ip6:, wo möglich

Wenn ein Drittanbieter-Absender einen statischen IP-Bereich bereitstellt, ersetzen Sie den include:-Mechanismus durch explizite IP-Adressen:

Vorher:

v=spf1 include:mail.vendor.com ~all

Nachher:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.5 ~all

Dies eliminiert DNS-Abfragen für diesen Absender. Dieser Ansatz funktioniert jedoch nur, wenn der Anbieter statische IPs verwendet und die Infrastruktur nicht häufig rotiert. Viele SaaS-Plattformen rotieren IPs, was statische Auflistungen unpraktisch macht.

2. Flatten Sie den SPF-Datensatz

SPF-Flattening löst alle include:-Mechanismen in ihre finalen IP-Adressen auf und konsolidiert sie in einem einzigen Datensatz. Dies reduziert DNS-Abfragen, schafft aber operationelle Risiken:

• Anbieter-IP-Änderungen brechen die Authentifizierung. Wenn ein Anbieter IP-Adressen hinzufügt oder rotiert, wird Ihr abgeflachter SPF-Datensatz veraltet, und legitime E-Mails schlagen bei der Authentifizierung fehl.
• Manuelle Updates erforderlich. Sie müssen Anbieter-SPF-Datensätze überwachen und Ihren abgeflachten Datensatz aktualisieren, wann immer Änderungen auftreten.
• Keine Benachrichtigung bei Anbieteränderungen. Die meisten Anbieter kündigen SPF-Datensatz-Änderungen nicht an, sodass Sie den Fehler erst entdecken, wenn E-Mails zurückspringen.

Flattening funktioniert als kurzfristige Lösung, erfordert aber laufende Wartung und Überwachung.

3. Verwenden Sie Subdomains zur Segmentierung von Absendern

Verschieben Sie spezifische E-Mail-Streams auf dedizierte Subdomains und erstellen Sie separate SPF-Datensätze für jede:

Beispiel:

• example.com → Authentifiziert für primäre Geschäfts-E-Mails (Microsoft 365)
• marketing.example.com → Authentifiziert für Marketing-Plattformen (SendGrid, Mailchimp)
• support.example.com → Authentifiziert für Support-Tools (Zendesk, Intercom)

Jede Subdomain hat ihren eigenen SPF-Datensatz, und jeder Datensatz bleibt unter dem 10-Lookup-Limit. Dieser Ansatz funktioniert gut für Organisationen mit klarer Absendersegmentierung, erfordert aber:

• E-Mail-Plattform-Unterstützung für Subdomain-Versand (nicht alle Plattformen unterstützen dies).
• DNS-Konfiguration für jede Subdomain.
• DMARC-Richtlinien-Alignment über Subdomains hinweg (wenn nicht konfiguriert, kann DMARC fehlschlagen).

4. Entfernen Sie ungenutzte oder redundante include:-Mechanismen

Viele SPF-Datensätze enthalten Absender, die nicht mehr verwendet werden:

• Legacy-Marketing-Plattformen
• Stillgelegte Support-Tools
• Doppelte include:-Anweisungen (z. B. zwei Einträge für denselben Anbieter)
• Anbieter, die getestet, aber nie eingesetzt wurden

Auditieren Sie Ihren SPF-Datensatz und entfernen Sie alle include:-Mechanismen, die nicht aktiven Absendern entsprechen. Verwenden Sie Skysnag Protect, um zu identifizieren, welche Absender aktiv E-Mails senden und welche include:-Einträge ungenutzt sind.

5. Konsolidieren Sie Anbieter, wo möglich

Wenn Sie mehrere Marketing-Plattformen, Support-Tools oder Transaktions-E-Mail-Anbieter verwenden, konsolidieren Sie auf weniger Anbieter. Dies reduziert die Anzahl der include:-Mechanismen und vereinfacht die SPF-Verwaltung.

Zum Beispiel:

• Verwenden Sie eine Transaktions-E-Mail-Plattform statt drei.
• Konsolidieren Sie Marketing-E-Mails über einen einzigen ESP.
• Leiten Sie Support-E-Mails über ein Ticketing-System.

Dies ist eine geschäftliche Entscheidung, nicht nur eine technische Lösung, aber es ist der nachhaltigste Weg, die SPF-Komplexität zu reduzieren.

VI. SPF-Lookup-Limit und DMARC-Durchsetzung

Wenn SPF das Lookup-Limit überschreitet und permerror zurückgibt, hängt die DMARC-Auswertung davon ab, ob DKIM erfolgreich ist und ausgerichtet ist.

Szenario 1: SPF permerror + DKIM erfolgreich + DKIM ausgerichtet

DMARC ist erfolgreich, weil DKIM die erforderliche Authentifizierung und Ausrichtung liefert. SPF-Fehler blockiert die Zustellung nicht, schwächt aber die gesamte Authentifizierungshaltung.

Szenario 2: SPF permerror + DKIM fehlgeschlagen oder fehlend

DMARC schlägt fehl. Wenn Ihre Richtlinie auf p=quarantine oder p=reject gesetzt ist, wird die E-Mail gefiltert oder während der SMTP-Zustellung abgelehnt, wenn der empfangende Server die Richtlinie berücksichtigt. Wenn Ihre Richtlinie p=none ist, wird der Fehler protokolliert, löst aber keine Durchsetzung aus.

Szenario 3: SPF permerror + DKIM erfolgreich, aber nicht ausgerichtet

DMARC schlägt fehl. DKIM muss mit der From:-Domain ausgerichtet sein (entweder strikte oder lockere Ausrichtung). Wenn DKIM erfolgreich ist, aber nicht ausgerichtet ist, und SPF permerror ist, hat DMARC keinen gültigen Authentifizierungspfad.

Der häufigste Fehlermodus ist Szenario 2 – SPF bricht, DKIM ist für den Drittanbieter-Absender nicht konfiguriert, und DMARC schlägt vollständig fehl.

VII. Wie Sie die SPF-Lookup-Anzahl im Laufe der Zeit überwachen

SPF-Datensätze ändern sich, wenn Sie autorisierte Absender hinzufügen oder entfernen. Die Überwachung der Lookup-Anzahl verhindert Authentifizierungsfehler, bevor sie die Zustellung beeinträchtigen.

Verwenden Sie Skysnag Protect für kontinuierliche SPF-Überwachung

Skysnag Protect überwacht kontinuierlich Ihren SPF-Datensatz und verfolgt die DNS-Lookup-Anzahl. Wenn ein Anbieter seinen SPF-Datensatz aktualisiert und Ihre Gesamt-Lookup-Anzahl steigt, warnt Sie Skysnag, bevor das 10-Lookup-Limit überschritten wird.

So funktioniert es:

1. Skysnag scannt Ihren SPF-Datensatz täglich.
2. Verfolgt die Lookup-Anzahl für alle include:-Mechanismen.
3. Warnt Sie, wenn die Lookup-Anzahl sich dem Limit nähert oder es überschreitet.
4. Bietet Empfehlungen für Flattening, Subdomain-Segmentierung oder IP-Konsolidierung.

Dies verhindert den stillen Fehlermodus, bei dem SPF kaputt geht und Sie es erst entdecken, wenn die Zustellbarkeit abnimmt.

Beginnen Sie mit der Überwachung Ihres SPF-Datensatzes mit Skysnag Protect.

VIII. SPF-Alternativen: MTA-STS und reine DKIM-Authentifizierung

Einige Organisationen eliminieren SPF vollständig und verlassen sich auf DKIM für die Authentifizierung. Dies vermeidet das Lookup-Limit, entfernt aber die Rolle von SPF bei der Verhinderung von Envelope-Level-Spoofing.

Reine DKIM-Authentifizierung

DKIM authentifiziert den Nachrichtentext und Header mithilfe einer kryptografischen Signatur. Es validiert nicht den Envelope-Absender (die während SMTP verwendete Adresse), verhindert also nicht bestimmte Arten von Spoofing. DKIM hat jedoch kein Lookup-Limit, bricht nicht während der Weiterleitung und bietet stärkere kryptografische Garantien als SPF.

Wenn Sie reine DKIM-Authentifizierung einsetzen:

• Stellen Sie sicher, dass DKIM für alle autorisierten Absender konfiguriert ist.
• Verwenden Sie DMARC mit aspf=r (lockere Ausrichtung), um Subdomain-Flexibilität zu ermöglichen.
• Überwachen Sie DMARC-Aggregatberichte, um die DKIM-Abdeckung zu verifizieren.

MTA-STS für Transportsicherheit

MTA-STS (Mail Transfer Agent Strict Transport Security) erzwingt verschlüsselte Zustellung, ersetzt aber nicht SPF oder DKIM. Es stellt sicher, dass E-Mails über TLS zugestellt werden, um Man-in-the-Middle-Angriffe zu verhindern, authentifiziert aber nicht den Absender.

MTA-STS arbeitet neben DMARC, nicht als Ersatz.

IX. Häufige SPF-Lookup-Limit-Fehler

1. Annehmen, dass Anbieter-SPF-Datensätze sich nie ändern

Anbieter aktualisieren ihre SPF-Datensätze, um Infrastruktur hinzuzufügen, IPs zu rotieren oder Hosting-Provider zu wechseln. Wenn Sie Ihren SPF-Datensatz abflachen und Anbieteränderungen nicht überwachen, bricht die Authentifizierung stillschweigend.

2. include:-Anweisungen statt DNS-Abfragen zählen

Ein SPF-Datensatz mit 5 include:-Mechanismen kann 12+ DNS-Abfragen auslösen, weil jeder eingebundene Datensatz zusätzliche verschachtelte include:, a oder mx-Mechanismen enthalten kann.

Zählen Sie immer die gesamten rekursiven DNS-Abfragen, nicht nur die Top-Level-Mechanismen.

3. Verwenden von ptr-Mechanismen

Der ptr-Mechanismus ist veraltet und ineffizient. Er löst Reverse-DNS-Abfragen aus und erhöht die Abfragezahl. Verwenden Sie ptr nicht in modernen SPF-Datensätzen.

4. Nicht testen von SPF-Änderungen vor der Veröffentlichung

Die Veröffentlichung einer SPF-Änderung ohne Test kann die Authentifizierung für alle E-Mails brechen. Verwenden Sie eine Test-Domain oder Subdomain, um den Datensatz vor der Anwendung in der Produktion zu validieren.

5. Ignorieren von DMARC-Aggregatberichten

DMARC-Berichte zeigen SPF-permerror-Fehler, aber viele Organisationen überprüfen Berichte nicht regelmäßig. Richten Sie Überwachung über Skysnag ein, um SPF-Probleme zu identifizieren, bevor sie die Zustellung beeinträchtigen.

X. Wichtigste Erkenntnisse

SPF-Lookup-Limits sind nicht flexibel. Die 10-DNS-Lookup-Grenze ist eine fest vorgegebene technische Beschränkung, und deren Überschreitung führt zu einem permerror, was die SPF-Authentifizierung unterbricht und häufig zum DMARC-Fehler führt.

Organisationen, die mehrere E-Mail-Plattformen von Drittanbietern nutzen, überschreiten das Limit häufig, ohne es zu bemerken, weil DNS-Lookups rekursiv gezählt werden und Anbieter ihre SPF-Einträge ohne Vorankündigung ändern.

Der Fehler verläuft oft unbemerkt. E-Mails werden möglicherweise weiterhin zugestellt, landen aber im Spam-Ordner, werden gedrosselt oder beeinträchtigen die Reputation langfristig. DMARC-Aggregatberichte zeigen das permerror-Ergebnis, doch wenn Berichte nicht aktiv überwacht werden, bleibt der Fehler unbemerkt, bis Zustellbarkeitsprobleme auftreten.

Um innerhalb des SPF-Lookup-Limits zu bleiben:

• Ersetzen Sie include:-Mechanismen durch ip4: oder ip6:, wenn Anbieter statische IPs verwenden.
• Verteilen Sie E-Mail-Ströme auf mehrere Subdomains, um die Lookup-Anzahl zu verteilen.
• Entfernen Sie ungenutzte oder veraltete include:-Einträge.
• Konsolidieren Sie Anbieter, um die SPF-Komplexität zu reduzieren.
• Überwachen Sie SPF-Einträge kontinuierlich, um Änderungen bei Anbietern zu erkennen.

Nutzen Sie Skysnag Protect, um die DNS-Lookup-Anzahl zu überwachen, zu identifizieren, welche Absender zur Lookup-Inflation beitragen, und Warnungen zu erhalten, bevor SPF fehlschlägt. Skysnag bietet Transparenz in die SPF-Struktur, verfolgt Änderungen an Anbieter-Einträgen und hilft Ihnen, Einträge umzustrukturieren, bevor die Authentifizierung fehlschlägt.