Der SPF-PermError-Report: 100× mehr Domains reißen das 10-Lookup-Limit, als Oberflächen-Zählungen zeigen (2026)

Q: Wie reduziere ich meine SPF-Lookup-Zahl?

Entfernen Sie ungenutzte Includes und ptr, flachen Sie Ihre eigene Infrastruktur zu ip4:/ip6: ab, verschieben Sie Massenversender auf Subdomains und zählen Sie nach jedem neuen Tool erneut. Der Fix-Leitfaden führt Sie hindurch.

Veröffentlicht 2026-07-03

Zahlen mit Stand 2026-06-29 · Methodik v7, plus ein Ketten-Bepreisungsdurchlauf vom 2026-07-03. Aus dem Zensus von 261 Millionen benoteten Domains haben wir jedes SPF-include:-Ziel aufgelöst, das 100 oder mehr Mal referenziert wird — 10.842 Ziele, die 95,2% aller Include-Referenzen abdecken — und jede in einer Domain verbliebene Kette gegen diese Karte bepreist. Nicht aufgelöste Rand-Ziele zählten als null, und die Ketteninhalte spiegeln den Auflösungstag wider; die Schlagzeile ist also eine konservative, nach unten verzerrte Annäherung: Wir sagen „mindestens”. Nur Aggregat; niemals der Eintrag eines einzelnen Unternehmens. Siehe wie wir benoten.

Wie viele Domains reißen das SPF-10-Lookup-Limit?

Mindestens 797.263 — weil SPF eine Selbstzerstörung im Standard eingebaut hat und der Auslöser dort versteckt ist, wo Inhaber ihn nicht sehen können. RFC 7208 §4.6.4 begrenzt eine SPF-Prüfung auf 10 DNS-Lookups; jenseits der zehn stoppt der Empfänger und gibt PermError zurück, und ein PermError-Eintrag schützt nichts. Zählt man nur die im Eintrag selbst sichtbaren Lookups — wie es die meisten Tools tun und wie es auch unser eigener Zensus bis zu diesem Report tat — findet man rund 8.000 Übertreter (genau 7.958). Bepreist man die include:-Ketten, die diese Einträge tatsächlich hereinziehen, erreicht die Zahl 797.263: etwa 100 Mal so viel.

Warum können Inhaber es nicht kommen sehen?

Weil das Budget von den Einträgen anderer Leute verbraucht wird. include:onetool.example.com liest sich als eine Zeile in Ihrem DNS-Panel — aber der Empfänger muss auch diesen Eintrag abrufen und jeden darin enthaltenen Lookup-Mechanismus rekursiv mitzählen. Ein Eintrag mit drei Includes kann elf kosten. In Ihrer eigenen Zone hat sich an dem Tag, an dem Sie über das Limit gerieten, nichts geändert; ein Provider hat einen weiteren Include verschachtelt, und Ihr SPF starb ohne Vorwarnung.

Schlimmer noch: DMARC behandelt einen PermError als Fehlschlag auf der SPF-Seite — eine Domain, die ihr SPF auf diese Weise zerbrochen hat, scheitert nun an der Hälfte ihrer eigenen Authentifizierung.

Was die Ketten-Bepreisung ergab

Befund	Domains
Über dem 10-Lookup-Limit, Ketten bepreist	797.263
Über dem Limit, nur sichtbare Mechanismen gezählt	7.958
Über dem Limit und dabei mit striktem `-all` endend	112.215
Bei genau 9–10 Lookups — die Klippenkante	2.119.539

Zwei Geschichten in dieser Tabelle — die dritte, die Klippenkante, bekommt weiter unten einen eigenen Abschnitt:

Oberflächen-Zählungen übersehen ~99% des Bruchs. Die Zählung sichtbarer Mechanismen findet 7.958; die Bepreisung der Ketten findet 797.263. Fast der gesamte Schaden wird von dem geerbt, was die Includes einschließen.
112.215 der zerbrochenen Einträge enden auf -all. Ihre Inhaber haben alles richtig gemacht — die Mauer erklommen, das strikte Ende gewählt — und ein Include zu viel hat das Ganze ungültig gemacht. Strikt aussehend und zerbrochen ist der härteste Fehlermodus in der E-Mail-Sicherheit.

2,1 Millionen Domains sind ein Tool von der Klippe entfernt

Die Zahl, die Leser beunruhigen sollte, denen es derzeit gut geht: 2.119.539 Domains lösen sich zu genau 9 oder 10 Lookups auf — heute unter dem Limit, tot an dem Tag, an dem jemand eine weitere Plattform anschließt. Das ist etwa 1 von 66 aller SPF-Publisher, und es passt zur Form der Verteilung: Der SPF-Eintrag im 99. Perzentil liegt bereits bei 9 Lookups. Melden Sie sich für ein weiteres Marketing-Tool an, fügen Sie dessen „einfach diesen Include hinzufügen”-Zeile ein, und ein Eintrag, der beim Frühstück noch unter dem Limit war, ist zum Mittagessen ungültig.

Wessen Schuld ist es? Zunehmend die des Stacks

Die größten Provider haben ihr SPF still und leise abgeflacht — Googles _spf.google.com und Microsofts spf.protection.outlook.com expandieren nun zu reinen IP-Listen, die keine internen Lookups kosten (wir haben beide während dieser Analyse gegen Live-DNS verifiziert). Die Explosionen kommen von anderswoher: Hosting-Panel-Ketten, die drei Ebenen tief verschachteln, regionale Provider, deren Include für sich allein 7–10 Lookups kostet, und die ehrliche Anhäufung von SaaS — Postfach plus Newsletter plus CRM plus Helpdesk, jeweils „nur ein Include”. Fast niemand fügt den elften Lookup absichtlich hinzu. Er kommt als Summe vernünftiger Entscheidungen.

So prüfen und reparieren Sie Ihren — kostenlos

Zählen Sie Ihre echte Gesamtzahl — unsere kostenlose Prüfung löst Ihre Kette auf, oder verwenden Sie einen beliebigen SPF-Lookup-Zähler.
Beschneiden Sie totes Gewicht: Tools, die Sie nicht mehr verwenden, doppelte Includes und den veralteten ptr-Mechanismus.
Flachen Sie nur das ab, was Sie kontrollieren. Einen tiefen Include durch seine IP-Blöcke zu ersetzen funktioniert für Ihre eigene Infrastruktur; IPs von Dritten ändern sich ohne Ankündigung.
Geben Sie Massenversendern eine Subdomain. Newsletter von news.yourdomain.com bekommen ihren eigenen Eintrag und ihr eigenes 10-Lookup-Budget.

Häufig gestellte Fragen

Was ist das SPF-10-DNS-Lookup-Limit? RFC 7208 §4.6.4 erlaubt höchstens 10 DNS-Lookups zur Auswertung eines SPF-Eintrags — wobei die Lookups innerhalb jedes include: rekursiv mitgezählt werden. Ein Überschreiten gibt PermError zurück: Der Eintrag wird als ungültig behandelt und bietet keinen Schutz.

Was bedeutet SPF PermError? Ein permanenter Auswertungsfehler — der Empfänger konnte Ihren Eintrag nicht verarbeiten (zu viele Lookups, mehrere Einträge oder fehlerhafte Syntax) und behandelt Ihre Domain, als hätte sie kein nutzbares SPF. DMARC zählt es als Fehlschlag auf der SPF-Seite.

Wie viele Domains überschreiten das SPF-Lookup-Limit? Mindestens 797.263 von 139 Millionen SPF-Publishern, gemäß unserem Ketten-Bepreisungsdurchlauf — etwa 100× so viele wie die 7.958, die ohne Auflösung der Ketten sichtbar sind. Weitere 2.119.539 liegen bei 9–10 Lookups, einen Include vom Limit entfernt.

Verhindert ein PermError, dass meine E-Mail zugestellt wird? Meist nicht — Empfänger fahren ohne SPF fort, und Ihre Post reitet auf DKIM und Reputation. Was aufhört zu funktionieren, ist der Schutz: Fälscher werden nicht mehr abgewiesen, und jede DMARC-Prüfung Ihrer Post verliert ihre SPF-Seite. Es ist unsichtbar, bis es teuer wird.

Wie reduziere ich meine SPF-Lookup-Zahl? Entfernen Sie ungenutzte Includes und ptr, flachen Sie Ihre eigene Infrastruktur zu ip4:/ip6: ab, verschieben Sie Massenversender auf Subdomains und zählen Sie nach jedem neuen Tool erneut. Der Fix-Leitfaden führt Sie hindurch.

Finden Sie Ihre echte Zahl heraus

Die Mechanismen, die Sie sehen können, sind nicht Ihre Lookup-Zahl — die aufgelöste Zahl ist die, die Empfänger berechnen, und es ist eine 30-Sekunden-Prüfung.

Prüfen Sie Ihre Domain → · SPF reparieren → · Das SPF-Reifegradmodell → · Zwei SPF-Einträge = keiner → · Die ptr-Falle → · Nur Aggregatdaten. Daten in der EU gespeichert und verarbeitet.