Stand: Juli 2026

Zusammenfassung: Der include-Mechanismus in einem SPF-Record bindet die SPF-Konfiguration einer anderen Domain ein. Er ist gezielt dafür gedacht, externen Dienstleistern den Versand in deinem Namen zu erlauben, verbraucht jedoch bei jeder Prüfung DNS-Lookups.

Wenn deine E-Mails nicht nur über deinen eigenen Mailserver oder deinen Webhoster verketten, sondern auch über Newsletter-Tools, CRM-Systeme oder Cloud-Dienste laufen, musst du diese Versandwege in deinem SPF-Record (Sender Policy Framework) autorisieren. Genau dafür gibt es den include-Mechanismus.

Wie der include-Mechanismus funktioniert

Laut RFC 7208 löst ein include eine rekursive Prüfung aus: Der empfangende Mailserver unterbricht die Auswertung deines eigenen Records und führt eine vollständige check_host()-Auswertung des SPF-Records der angegebenen Ziel-Domain durch.

Ein typischer SPF-Record mit include sieht so aus:

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

Oder, wenn mehrere externe Dienste autorisiert werden sollen:

v=spf1 include:_spf.example.com include:spf.example.net ~all

Liefert die Prüfung der eingebundenen Domain ein pass (weil die IP-Adresse des einliefernden Servers im externen Record gelistet ist), gilt das auch für deinen Record als Treffer – die E-Mail wird als autorisiert akzeptiert. Liefert der eingebundene Record hingegen kein pass, prüft der Server einfach die nächsten Mechanismen in deinem Eintrag weiter, bis er am Ende beim ~all oder -all ankommt.

Wann du include nutzen solltest (und wann nicht)

Der include-Mechanismus ist laut Standard primär dafür konzipiert, administrative Grenzen zu überschreiten. Wenn ein externer Anbieter (zum Beispiel ein E-Mail-Marketing-Dienst oder ein Cloud-Workspace wie Microsoft 365) Server betreibt, deren IP-Adressen sich regelmäßig ändern, pflegt dieser Anbieter einen eigenen SPF-Eintrag. Über include verweist du auf diesen dynamisch gepflegten Eintrag, ohne deine eigene DNS-Zone bei jeder Serveränderung des Dienstleisters manuell aktualisieren zu müssen.

Innerhalb einer einzigen administrativen Zone (wenn du also deine eigenen Server verwaltest) ist include meist nicht die beste Wahl. Um die eigenen IP-Adressen direkt zu strukturieren, sind Mechanismen wie ip4 oder ip6 effizienter und zuverlässiger.

Das 10-Lookup-Limit und permerror

Ein kritischer Punkt bei der Verwendung von include ist das DNS-Lookup-Limit. Laut RFC 7208 verbrauchen bestimmte SPF-Terme bei der Auswertung DNS-Abfragen – konkret sind das die Mechanismen include, a, mx, ptr und exists sowie der Modifier redirect.

SPF-Implementierungen müssen die Gesamtzahl dieser Abfragen pro E-Mail-Prüfung strikt auf maximal 10 Lookups begrenzen, um das Domain Name System vor Überlastung zu schützen. Wird dieses Limit überschritten, bricht der empfangende Server die Prüfung ab und gibt einen permanenten Fehler (permerror) zurück. In der Folge wird deine E-Mail oft abgelehnt oder landet im Spam.

Da jeder include mindestens eine DNS-Abfrage verbraucht – und die eingebundene Domain selbst wiederum weitere include-Anweisungen enthalten kann –, ist das 10-Lookup-Limit schneller erreicht als gedacht. Mechanismus-Arten wie ip4, ip6 und all verursachen hingegen keine DNS-Abfragen und verbrauchen deshalb keine Lookups.

Die richtige Konfiguration prüfen

Da eine Domain niemals mehrere separate SPF-Records besitzen darf (was ebenfalls sofort zu einem permerror führt), musst du alle benötigten include-Anweisungen in einen einzigen TXT-Record zusammenführen.

Prüfe deine Konfiguration am besten mit dem kostenlosen MXAudit-Scanner. Das Tool zeigt dir nicht nur, ob dein SPF-Record syntaktisch korrekt ist, sondern schlüsselt auch präzise auf, wie viele DNS-Lookups deine verschachtelten include-Anweisungen insgesamt verbrauchen.

Wenn du den Record für deinen spezifischen Anbieter aufsetzen willst, findest du im SPF-Hub alle Grundlagen sowie konkrete Schritt-für-Schritt-Anleitungen wie beispielsweise SPF bei IONOS einrichten.