SPF-Include-Ketten erklärt (mit Beispielen)

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

Die meisten SPF-Einträge wirken harmlos. Vier include:-Anweisungen, am Ende ein ~all, und ein DNS-Tool bestätigt gültige Syntax. Dann behandelt Gmail Ihre E-Mails als nicht authentifiziert, und in den Logs steht SPF PermError.

Was fehlt, ist die Include-Kette: Jedes include: ist eine DNS-Abfrage eines anderen SPF-Eintrags, und dieser Eintrag enthält in der Regel weitere Includes. Empfangende Server zählen den ganzen Baum, nicht die vier Token, die Sie eingetippt haben.

In diesem Leitfaden erklären wir, wie Include-Ketten funktionieren, gehen drei konkrete Beispiele durch und zeigen, warum ein Eintrag, der „nur vier Includes“ hat, trotzdem das Limit von 10 DNS-Lookups aus RFC 7208 überschreiten kann.

Was ist eine SPF-Include-Kette?

Ein SPF-Eintrag ist ein TXT-Eintrag, der autorisierte Absender auflistet. Der Mechanismus include: kopiert keine IP-Adressen in Ihren Eintrag. Er sagt dem empfangenden Server: schlagen Sie den SPF-Eintrag dieser anderen Domain nach und werten Sie ihn als Teil meines Eintrags aus.

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

Diese eine Zeile sind nicht „die IPs von Google“. Es ist ein Zeiger. Der Empfänger holt _spf.google.com, liest dessen SPF-Eintrag und folgt jedem Mechanismus, den er dort findet. Wenn Googles Eintrag drei weitere Domains einbindet, zählen auch diese. Dieser verschachtelte Durchlauf ist die Include-Kette.

Wie der 10-Lookup-Zähler wirklich funktioniert

RFC 7208 begrenzt die Zahl der DNS-abfragenden Terme auf 10 pro SPF-Prüfung. Die initiale Abfrage Ihres eigenen SPF-TXT zählt nicht. Alles, was dieser Eintrag verursacht, schon.

Sobald der 11. Lookup nötig wäre, stoppt die Auswertung mit einem PermError. Weitere Includes werden nie geprüft. Ein syntaktisch perfekter Eintrag kann zur Laufzeit trotzdem hart fehlschlagen.

Beispiel 1: Ein Include, der in Wirklichkeit vier Lookups ist

Beginnen wir mit dem kleinsten realistischen Eintrag, nur Google Workspace:

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

Auf dem Papier ist das ein Include. Die Kette, die der Empfänger tatsächlich abläuft, sieht so aus:

yourdomain.com
└── include:_spf.google.com                 (+1)
    ├── include:_netblocks.google.com       (+1)
    ├── include:_netblocks2.google.com      (+1)
    └── include:_netblocks3.google.com      (+1)

Der SPF-Eintrag von Google auf oberster Ebene ist selbst ein Bündel von Includes. Diese verschachtelten Einträge veröffentlichen dann ip4:- und ip6:-Bereiche, die keine weiteren Lookups hinzufügen. Die Rechnung für „nur Gmail“ liegt typischerweise bei 4 Lookups, nicht bei 1.

Die genauen Zahlen der Anbieter ändern sich. Entscheidend ist die Form des Baums: Ein Token in Ihrem Eintrag kann mehrere Lookups verbergen, die Sie nie selbst geschrieben haben.

Beispiel 2: Microsoft 365 wirkt flach, bis man es auflöst

Ein Microsoft-365-Include ist die andere klassische Annahme „das sollte günstig sein“:

v=spf1 include:spf.protection.outlook.com ~all

Der Outlook-Eintrag hat historisch direkte IP-Blöcke mit weiteren include:-Anweisungen für zusätzliche Netblöcke gemischt. Vereinfacht sieht die Kette so aus:

yourdomain.com
└── include:spf.protection.outlook.com      (+1)
    └── include:spfa.protection.outlook.com (+1)
        └── weitere Includes / MX je nach Veröffentlichung

Je nachdem, wie Microsoft den Eintrag aktuell veröffentlicht, sind das oft 2-3 Lookups statt einem. Zusammen mit Google aus Beispiel 1 liegen Sie bereits bei etwa 6-7 Lookups, bevor ein einziges Marketing- oder CRM-Tool dazukommt.

Beispiel 3: Ein typischer Firmeneintrag, der still 10 überschreitet

Jetzt der Eintrag, den die meisten mittelständischen Teams tatsächlich veröffentlichen:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com ~all

Vier Includes. Viele DNS-Dashboards zeigen sogar einen grünen Haken. Löst man die Kette mit typischen verschachtelten Zahlen auf, ändert sich das Bild:

Als Baum:

yourdomain.com
├── include:_spf.google.com                      (+1)
│   ├── include:_netblocks.google.com            (+1)
│   ├── include:_netblocks2.google.com           (+1)
│   └── include:_netblocks3.google.com           (+1)
├── include:spf.protection.outlook.com           (+1)
│   └── include:spfa.protection.outlook.com      (+1)
├── include:servers.mcsv.net                     (+1)
│   └── verschachtelte Mailchimp-Includes        (+1-2)
└── include:_spf.salesforce.com                  (+1)
    └── verschachtelte Salesforce-Includes       (+1-3)

Der 11. Lookup wird nie ausgewertet. Steht Salesforce am Ende des Eintrags, kann ein Teil der CRM-Mails an einem Glückstag noch durchkommen, während spätere Mechanismen übersprungen werden — oder die ganze Prüfung schlägt fehl, je nachdem, wo das Limit greift. In beiden Fällen haben Sie keine verlässliche Richtlinie mehr.

Eine kurze Kette, die Sie per Hand zählen können

Wenn Sie das an einer Domain nachvollziehen wollen, die Sie kontrollieren, beginnen Sie oben und gehen rekursiv vor:

1. Schlagen Sie den TXT-Eintrag Ihrer Domain nach und finden Sie die Zeichenkette v=spf1.
2. Listen Sie jedes include:, a, mx, ptr, exists und redirect= auf.
3. Für jedes Include schlagen Sie den SPF-Eintrag dieser Domain nach und wiederholen den Schritt.
4. Hören Sie auf, wenn ein Eintrag nur noch ip4: / ip6: (und all) enthält. Diese Blätter fügen keine Lookups hinzu.

dig TXT yourdomain.com +short
dig TXT _spf.google.com +short
dig TXT _netblocks.google.com +short

Das vollständig per Hand zu tun ist mühsam - deshalb unterzählen die meisten. Online-Validatoren, die bei 10 Lookups abbrechen, machen es schlimmer: Sie melden einen Fehler, ohne den Rest des Baums zu zeigen, sodass Sie nie sehen, welcher Anbieter Sie über das Limit gebracht hat.

Was Flattening mit der Kette macht

SPF Flattening löst den Baum einmal auf und veröffentlicht die resultierenden IP-Bereiche direkt. Die Include-Kette schrumpft auf einen kurzen Eintrag, der Empfänger nicht mehr zwingt, bei jeder eingehenden Nachricht durch Google, Microsoft, Mailchimp und Salesforce zu rekursieren.

Vorher (vier Includes, 10+ Lookups):

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com ~all

Nachher nach dem Flattening (ein Include, ein Lookup):

v=spf1 include:_yourdomain.spf.spflat.cloud ~all

Hinter diesem einen Include hält ein automatisierter Flattener die IP-Liste aktuell. Wenn Google oder Microsoft ihre Bereiche drehen, aktualisiert sich der abgeflachte Eintrag. Sie müssen die Anbieterkette nicht erneut in Ihrem eigenen DNS ablaufen, und Empfänger zahlen nicht die Kosten der verschachtelten Lookups.

Manuelles Flattening kann dieselbe IP-Liste einmal erzeugen. Es kann die Liste nicht wahr halten. Das ist der Unterschied zwischen einer einmaligen dig-Sitzung und einem Flattening-Dienst.

So prüfen Sie Ihre eigene Include-Kette

Nutzen Sie den kostenlosen Checker auf spflat.cloud. Er löst verschachtelte Includes auf und zeigt die Lookup-Anzahl so, wie ein empfangender Server sie zählen würde - nicht so, wie Ihr TXT-Eintrag im DNS-Panel aussieht.

Liegt die Zahl bei 8 oder 9, sind Sie ein neues SaaS-Tool vom PermError entfernt. Liegt sie bereits bei 10 oder mehr, ist Flattening die Lösung - nicht noch ein Include.