spFlat! logospFlat!
AnmeldenKostenlos testen
Zurück zur Startseite
← Alle Beiträge

Zu viele DNS-Lookups: SPF PermError für Google, Microsoft 365 & SendGrid beheben

Veröffentlicht am 11. September 2026 · 6 Min. Lesezeit · spFlat!

„Zu viele DNS-Lookups“ ist weiterhin der häufigste Grund, warum SPF-Prüfungen bei der Auswertung fehlschlagen. Das 10-Lookup-Limit in RFC 7208 ist eine harte Grenze: Der 11. DNS-Term beendet die Auswertung mit einem PermError. Das ist nicht dasselbe wie ein SPF-Fail, aber viele Empfänger (einschließlich Gmail) behandeln ihn so streng, dass die E-Mail-Zustellbarkeit leidet.

Die Falle: die include:-Tokens zu zählen, die Sie selbst eingetippt haben. Empfänger zählen die ganze Kette. Google Workspace und Microsoft 365 haben ihre eigenen Einträge kürzlich abgeflacht, die beiden kosten also wenig. Kommen SendGrid, Mailgun oder ein CRM dazu, liegt die Summe über 10, ohne dass jemand den offensichtlichen Teil des TXT-Eintrags geändert hat.

Warum „zu viele DNS-Lookups“ entstehen

Jeder Term include:, a, mx, ptr, exists und redirect= zählt als DNS-Lookup. Verschachtelte Includes zählen ebenfalls. Direkte ip4:- und ip6:-Mechanismen zählen nicht. Der erste Lookup Ihres eigenen SPF-TXT-Eintrags zählt auch nicht.

Ein Eintrag mit fünf Includes bedeutet nicht fünf Lookups:

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

Heute aufgelöst liegt dieses Setup typischerweise bei 11 Lookups und damit bereits über dem Limit:

  • _spf.google.com: Google veröffentlicht jetzt IP-Bereiche direkt: 1 Lookup
  • spf.protection.outlook.com: Microsoft 365 ist ebenfalls eine flache IP-Liste: 1 Lookup
  • sendgrid.net verschachtelt weiterhin include:ab.sendgrid.net: 2 Lookups
  • mailgun.org fächert über _spf.mailgun.org → _spf1/_spf2 plus den EU-Eintrag auf: 5 Lookups
  • _spf.salesforce.com nutzt zusätzlich exists:: 2 Lookups
Die Zahlen der Anbieter ändern sich. Google bestand früher aus vier verschachtelten Netblock-Includes und hat selbst abgeflacht. Das „Outlook kostet 3 Lookups“ vom letzten Jahr gilt dieses Jahr nicht mehr. Prüfen Sie die aktuelle Kette, statt sich auf eine alte Tabelle zu verlassen.

Anbieter für Anbieter

Google Workspace

Ihr Google-Include ist eine Zeile:

v=spf1 include:_spf.google.com ~all

2026 ist dieser Eintrag eine Liste von ip4:/ip6:-Bereichen und kostet 1 Lookup. Früher lief er über _netblocks.google.com, _netblocks2 und _netblocks3 (etwa 4 Lookups). Die alten Netblock-Namen existieren noch, aber der SPF-Eintrag von Google auf oberster Ebene bindet sie nicht mehr ein. Für sich genommen günstig, aber trotzdem 1 Ihrer 10 Lookups.

Microsoft 365

Exchange Online nutzt include:spf.protection.outlook.com. Dieser Eintrag ist derzeit ebenfalls eine flache IP-Liste: 1 Lookup. Die Falle ist alles, was eine Microsoft-Umgebung als Nächstes hinzufügt: Marketing-Plattform, Dynamics, Security-Gateway oder ein zweiter Tenant-Include. Das sind zusätzliche Lookups in einem Budget, das schon teilweise verbraucht ist.

SendGrid

SendGrid verschachtelt weiterhin:

include:sendgrid.net

sendgrid.net veröffentlicht eine lange IP-Liste und include:ab.sendgrid.net. Voll aufgelöst sind das 2 Lookups. Zusammen mit Google, Outlook, Mailgun und einem CRM sind Sie bereits über 10.

So erkennen Sie es (bevor E-Mails als nicht authentifiziert gelten)

Option 1: Der spFlat!-Checker (kostenlos, keine Anmeldung)

Gehen Sie zu spflat.cloud, geben Sie Ihre Domain ein und klicken Sie auf Prüfen. spFlat! löst die vollständige Kette inklusive verschachtelter Includes auf und zeigt die Lookup-Anzahl, die ein Empfänger verwenden würde, nicht die Anzahl der Tokens auf der obersten Ebene.

Option 2: Manuell mit dig

dig TXT yourdomain.com +short | grep -o 'include:[^ ]*' | while read inc; do
  dig TXT ${inc#include:} +short
done

Das ergibt eine grobe Zählung, übersieht aber tiefer verschachtelte Includes, sofern Ihr Skript nicht rekursiv weiter auflöst. Genau dort verstecken sich die zusätzlichen Lookups.

🔴 Der Haken: Manche DNS-Validatoren stoppen bei 10 Lookups und zeigen den Rest der Kette nicht. Ihr Eintrag kann im Dashboard „fast in Ordnung“ wirken und beim Empfänger trotzdem PermError liefern.

So beheben Sie es

Der harte Weg: manuelles Flattening

  1. Lösen Sie jedes include:, a: und mx: in Ihrem Eintrag auf
  2. Sammeln Sie alle resultierenden IP-Adressen und CIDR-Bereiche
  3. Erstellen Sie einen neuen Eintrag nur mit ip4: und ip6:-Mechanismen
  4. Veröffentlichen Sie ihn und hoffen Sie, dass die Anbieter ihre Bereiche nicht ändern
⚠️ Das Problem: Google, Microsoft und SendGrid ändern ihre IP-Bereiche. Ein manuell abgeflachter Eintrag veraltet, und Sie merken es erst, wenn E-Mails zurückkommen. Alle CIDRs in den TXT-Eintrag der eigenen Domain zu packen, sprengt außerdem DNS-Größenlimits; siehe das 255-Zeichen- bzw. TXT-Größenproblem.

Der einfache Weg: spFlat!

spFlat! hält den Eintrag, den ein Empfänger auswertet, unter dem 10-Lookup-Limit und aktuell:

  1. Prüfen Sie Ihre Domain und sehen Sie sofort die echte Lookup-Anzahl
  2. Fügen Sie Ihre Versanddienste hinzu (Google, Microsoft 365, SendGrid, Mailgun und was Sie tatsächlich nutzen)
  3. Veröffentlichen Sie einen Include, typischerweise v=spf1 include:_yourdomain.spf.spflat.cloud ~all (ein Lookup). spFlat! überwacht IP-Änderungen der Anbieter rund um die Uhr und aktualisiert den abgeflachten Eintrag hinter diesem Include.

Prävention

  • Fügen Sie neue Dienste über spFlat! hinzu, statt den TXT-Eintrag direkt zu ändern
  • Prüfen Sie nach jeder Anbieter-Änderung erneut: Ein neuer Include kann Sie unbemerkt über das Limit bringen
  • Überwachen Sie DMARC-Berichte: Ein plötzlicher Rückgang der SPF-Alignment-Rate ist oft das erste Anzeichen einer fehlerhaften Kette

🔍 Prüfen Sie Ihre Domain jetzt

Zehn Sekunden. Kostenlos. Sehen Sie genau, wie viele Lookups Ihr SPF-Eintrag verbraucht, einschließlich aller verschachtelten Includes. Über 10? Flachen Sie mit spFlat! in der 14-Tage-Testversion ab.

Prüfen Sie Ihren SPF-Eintrag
Oder starten Sie Ihre kostenlose 14-Tage-Testversion →

Häufig gestellte Fragen

Wie viele SPF-DNS-Lookups brauchen Google Workspace und Microsoft 365?

2026 für sich allein aufgelöst typischerweise je 1 Lookup: _spf.google.com und spf.protection.outlook.com veröffentlichen flache IP-Listen. Früher waren mehr verschachtelte Includes nötig, ältere Tabellen in Blogartikeln sind daher überholt. Jeder Include verbraucht trotzdem 1 Ihrer 10 Lookups, bevor Marketing- oder CRM-Plattformen dazukommen.

Warum überschreitet Google plus Microsoft 365 plus SendGrid das SPF-Limit von 10 Lookups?

Empfänger zählen die gesamte verschachtelte Kette, nicht die Include-Tokens, die Sie eintippen. Google und Outlook kosten je 1 Lookup, aber SendGrid verschachtelt weiterhin (etwa 2), und Mailgun oder Salesforce können mehrere weitere hinzufügen. Ein übliches Google + Outlook + SendGrid + Mailgun + CRM-Setup liegt bei etwa 11 Lookups und löst bereits PermError aus.

Wie behebe ich zu viele DNS-Lookups für Google, Microsoft 365 und SendGrid?

Hören Sie auf, jeden Anbieter-Include auf Ihrer Domain zu stapeln. Flachen Sie nur dann selbst in ip4:/ip6: ab, wenn Sie die Liste aktuell halten, oder veröffentlichen Sie einen Include auf einen automatisierten Flattening-Dienst, der IP-Änderungen der Anbieter überwacht. Prüfen Sie nach jedem neuen Absender erneut, denn die Lookup-Zahlen der Anbieter ändern sich mit der Zeit.