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-Einträge zur Laufzeit 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 es so streng, dass die Zustellbarkeit leidet.

Die Falle: die include:-Tokens zählen, die Sie selbst getippt haben. Empfänger zählen die ganze Kette. Google Workspace und Microsoft 365 haben ihre eigenen Einträge kürzlich abgeflacht - die beiden sind günstig. 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" entsteht

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

Ein Eintrag mit fünf Includes ist 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 - 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 nestet 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

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; das Top-Level-SPF von Google inkludiert sie nicht mehr. Für sich genommen günstig - trotzdem 1 von Ihren 10.

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 zweites Tenant-Include. Das sind extra Lookups in einem Budget, das schon teilweise verbraucht ist.

SendGrid

SendGrid nestet 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 Mail als unauthentifiziert gilt)

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 verschachtelte Rekursionen, sofern Sie nicht tiefer schleifen - und genau dort verstecken sich die zusätzlichen Lookups.

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

Der clevere 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 - sehen Sie die echte Lookup-Anzahl sofort
2. Fügen Sie Ihre Versanddienste hinzu (Google, Microsoft 365, SendGrid, Mailgun und was Sie tatsächlich nutzen)
3. Veröffentlichen Sie ein 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 neues Include kann Sie still über das Limit drücken
• Überwachen Sie DMARC-Berichte - ein plötzlicher Rückgang der SPF-Alignment-Rate ist oft das erste Zeichen einer kaputten Kette