Defaults.Exposed › Berichte

Warum schlägt mein SPF fehl? Das 10-Lookup-Problem für UK- und EU-Absender mit SaaS-Tools (2026)

Veröffentlicht 2026-07-09

Zahlen vom 2026-06-29 · Methodik v7. Aggregierte Zensusdaten aus 261 Millionen bewerteten Domains. Siehe wie wir bewerten.

Wenn SPF bei einem Unternehmen mit SaaS-Tools in der UK oder EU fehlschlägt, liegt die häufigste Ursache in einer einzigen RFC-Regel, über die man sich nie Gedanken machen musste: Jenseits von 10 DNS-Lookups gibt SPF kein „fail” zurück – sondern PermError. Das bedeutet, der Eintrag wird behandelt, als existiere er nicht. Mindestens 797.263 Domains haben diese Grenze bereits überschritten. Weitere 2.119.539 liegen exakt bei 9–10 Lookups – ein neues Tool, und sie fallen über denselben Abgrund.

Warum bricht SPF, wenn ein neues SaaS-Tool hinzugefügt wird?

SPF funktioniert, indem es die Mailserver auflistet, die im Namen einer Domain Nachrichten versenden dürfen. Moderne Unternehmen betreiben keine eigenen Mailserver mehr – sie nutzen Google Workspace für interne E-Mails, Mailchimp für Kampagnen, HubSpot für Vertriebssequenzen, Pipedrive für CRM-Outreach. Jede Plattform liefert eine include:-Zeile, die in das DNS eingetragen werden muss.

Das Problem: Jedes include: ist selbst ein DNS-Lookup. Und jeder Eintrag innerhalb dieses Includes kann rekursiv weitere Lookups auslösen. RFC 7208 §4.6.4 setzt eine harte Obergrenze von zehn. Jenseits von zehn stoppt der empfangende Mailserver die Auswertung und gibt PermError zurück – und ein PermError ist kein Soft-Failure, der im Spam landet. Es bedeutet, dass der SPF-Eintrag als nicht vorhanden gilt. Die E-Mail-Authentifizierung schlägt am SPF-Punkt fehl.

Im DNS-Panel ist das nicht sichtbar. Der Zähler läuft nur bei der Live-Auswertung. Man kann drei include:-Zeilen im sichtbaren Eintrag haben und trotzdem zwölf Lookups tief sein, weil jeder Anbieter-SPF-Eintrag eigene Sub-Includes enthält.

Wie viele Domains haben die Grenze bereits überschritten?

Mindestens 797.263. Das ist die Zahl, nachdem wir jedes SPF-include:-Ziel aufgelöst haben, das 100 oder mehr Mal referenziert wird – 10.842 verschiedene Ziele, die 95,2% aller Include-Referenzen abdecken – und die vollständige Kette jeder Domain bewertet haben. Die oberflächliche Zählung (nur die sichtbaren Zeilen im Eintrag) ergibt etwa 7.958. Die kettenbasierte Zahl ist 100 Mal größer, weil fast aller Schaden unsichtbar in Include-Zielen verborgen ist.

Die für europäische Unternehmen häufigste Situation:

Europäische Hosting-Anbieter und schwache SPF-Standards

Der ursprüngliche Hosting-Anbieter spielt eine Rolle – denn manche setzen SPF-Standards, die bereits mehrere der zehn Lookups verbrauchen, bevor ein einziges SaaS-Tool verbunden wird.

Unter den größten Hosting-Anbietern europäischer Domains in unserer Erhebung:

IONOS fällt auf: Nur 1,0% der bei IONOS gehosteten Domains haben ein erzwingendes DMARC – die überwältigende Mehrheit verfügt damit über keine sinnvolle Absenderauthentifizierung. OVH-Domains schneiden beim strikten SPF besser ab (43,7%), fallen aber bei der DMARC-Durchsetzung auf 2,2% – SPF allein, ohne DMARC, das es mit dem From:-Header verknüpft, schützt nur den Envelope, nicht das, was der Empfänger sieht.

Microsoft 365 ist in positiver Weise ein Ausreißer: 85,0% der bei Microsoft gehosteten Domains verwenden striktes SPF, vor allem weil Microsofts Mail-Flow-Assistent -all als Standard setzt. Google Workspace setzt ~all (Softfail) als Standard und lässt 92% seiner Domains ohne strikten Schutz.

SPF-Fehler in unter 60 Sekunden diagnostizieren

Die schnellste Prüfung ist ein kostenloses Tool, das die vollständige Lookup-Kette auswertet – nicht nur den sichtbaren Eintrag. nslookup -type=TXT yourdomain.com in der Befehlszeile ausführen und jedes include: zählen. Dann jeden dieser Einträge einzeln nachschlagen und dessen Includes zählen. Wenn die Finger ausgehen, bevor die Includes enden, ist man in der Gefahrenzone.

Zuverlässiger: Domain hier prüfen – der Scanner wertet die vollständige aufgelöste Kette aus, markiert PermError und zeigt, welche Mechanismen das Lookup-Budget verbrauchen.

Drei mögliche Diagnoseergebnisse:

• PermError – bereits über zehn. Jede versendete E-Mail schlägt beim SPF-Check am Empfänger fehl.
• Bei 9–10 Lookups – am Rand des Abgrunds. Die nächste SaaS-Integration kippt darüber hinaus.
• Softfail (~all) statt Hardfail (-all) – unter dem Limit, aber der Eintrag ist zu permissiv für echten Schutz. Siehe den SPF-Fehlkonfigurationsbericht für das vollständige Bild zu -all vs. ~all.

SPF reparieren, wenn mehrere SaaS-Tools im Einsatz sind

Es gibt drei Ansätze, geordnet nach Dauerhaftigkeit:

1. Prüfen und bereinigen. Mit einer vollständigen Liste aller include:-Einträge im aktuellen SPF-Eintrag beginnen. Alle Plattformen entfernen, die nicht mehr genutzt werden – alte E-Mail-Dienstleister, CRM-Tools aus früheren Verträgen, Plattformen, die getestet aber nie eingesetzt wurden. Das kostet nichts und gibt oft mehrere Lookups zurück. Jedes entfernte include: kann 1–3 Sub-Lookups einsparen.

2. Den SPF-Eintrag flatten. SPF-Flattening löst alle include:-Ziele in die darunter liegenden IP-Bereiche auf und schreibt sie direkt als ip4:- und ip6:-Mechanismen in den Eintrag. IP-Mechanismen verursachen keine Lookups, sodass ein geflatteter Eintrag Dutzende von Absendern listen und trotzdem bei null Lookups bleiben kann. Der Nachteil: Bei jeder Aktualisierung der Versand-IPs eines Anbieters muss erneut geflattert werden – und das geschieht ohne Vorankündigung. Die meisten Unternehmen nutzen einen kostenpflichtigen SPF-Flattening-Service (PowerDMARC, EasyDMARC, Dmarcian u. a.) oder bauen einen eigenen Monitoring-Workflow.

3. SPF-Makros verwenden. RFC 7208-Makros ermöglichen Einträge, die pro Prüfung nur einen DNS-Lookup durchführen und dynamisch antworten, statt eine Kette von Includes zu durchlaufen. Makros erfordern DNS-Hosting-Unterstützung und etwas Implementierungsaufwand, sind aber die architektonisch saubere Lösung für Organisationen mit vielen SaaS-Absendern.

Nach der SPF-Reparatur sollte DMARC-Durchsetzung ergänzt werden – SPF ohne DMARC schützt nur den Envelope-Absender, nicht die From:-Adresse im Header, die Empfänger sehen.

Häufig gestellte Fragen

Warum besteht mein SPF-Eintrag das DNS-Tool-Test, schlägt aber in E-Mail-Headern fehl? Die meisten DNS-Lookup-Tools zählen nur die Mechanismen, die im eigenen Eintrag sichtbar sind, nicht die Sub-Lookups, die diese Mechanismen auslösen. Man kann zwei include:-Zeilen haben und trotzdem über dem Limit liegen, wenn jeder Anbieter-Eintrag mehrere weitere enthält. Nur ein kettenbewertendes Tool (oder ein empfangender Mailserver) zählt die volle Tiefe. Domain prüfen um die echte Kettenanzahl zu sehen.

Bedeutet ein SPF-Fehler, dass E-Mails im Spam landen? PermError (zu viele Lookups) bedeutet, dass der SPF-Authentifizierungsschritt kein Ergebnis zurückgibt – effektiv als nicht vorhanden. DMARC wertet sowohl SPF als auch DKIM aus; wenn DKIM besteht, kann DMARC trotz des SPF-PermErrors bestehen. Wenn keines besteht, schlägt DMARC fehl, und das Ergebnis hängt von der DMARC-Richtlinie ab. Bei p=none wird die E-Mail weiterhin zugestellt, aber der Fehler wird protokolliert. Bei p=quarantine oder p=reject wird die E-Mail gefiltert oder abgewiesen. SPF reparieren, um nicht allein auf DKIM angewiesen zu sein.

Wie viele Lookups verbraucht ein typischer SaaS-Stack? Der p99-SPF-Eintrag in unserer Erhebung liegt bereits bei 9 Lookups – direkt an der Grenze – bevor irgendetwas hinzukommt. Ein Google-Workspace-Eintrag fügt 3–4 Lookups hinzu; Mailchimp 1–2; HubSpot 1–3, je nach aktueller Konfiguration. Drei gängige Tools plus der Standard-Eintrag des Hosting-Anbieters reichen oft, um zehn zu überschreiten.

Ist SPF-Flattening sicher? Ja, sofern es aktuell gehalten wird. Flattening wandelt include:-Ketten in statische IP-Bereiche um – wenn ein Anbieter seine Versand-IPs rotiert und nicht erneut geflattert wird, werden dessen E-Mails abgelehnt. Die meisten Organisationen nutzen einen verwalteten Flattening-Service, der IP-Änderungen überwacht, statt es manuell zu pflegen.

Mein SPF ist seit Jahren so – warum schlägt es plötzlich fehl? Weil Anbieter ihre SPF-Einträge aktualisiert haben, nicht der eigene. Jedes Mal, wenn eine SaaS-Plattform einen neuen IP-Bereich hinzufügt oder ein weiteres Include verschachtelt, steigen die Kettenkosten – ohne jede Änderung auf der eigenen Seite. Das 10-Lookup-Limit wird live bei der Nachrichtenempfang ausgewertet, sodass eine Anbieteränderung an einem Dienstagmorgen SPF bis zum Dienstagnachmittag brechen kann.

Verbessert die Reparatur von SPF die E-Mail-Zustellbarkeit? Es beseitigt eine Quelle von Authentifizierungsfehlern, was eine Voraussetzung für konsistente Zustellung ist – insbesondere da Google und Yahoo jetzt DMARC-Ausrichtung für Massen-Absender erzwingen. SPF allein ist nicht das ganze Bild: Kombinieren mit DKIM und DMARC für vollständige E-Mail-Authentifizierung.

SPF kostenlos prüfen

Wer nicht sicher ist, ob der SPF-Eintrag über dem Lookup-Limit liegt – oder zu schwach gesetzt ist, um die Domain zu schützen – kann eine kostenlose Prüfung durchführen. Diese wertet die vollständige aufgelöste Kette aus und zeigt genau, wo das Budget verbraucht wird.

Domain prüfen → · SPF reparieren → · Der SPF-PermError-Bericht → · SPF-Fehlkonfigurationsbericht → · Das SPF-Adoptions-Reifegradmodell → · DMARC reparieren → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.