SPF PermError „too many DNS lookups“: das 10-Lookup-Limit lösen

„SPF PermError: too many DNS lookups“ (zu viele DNS-Lookups) bedeutet, dass die Prüfung des SPF-Eintrags deiner Domain mehr als 10 DNS-Abfragen braucht, die feste Obergrenze aus RFC 7208. Der empfangende Server bricht die Auswertung ab und meldet einen dauerhaften Fehler statt „pass“, sodass jede Mail, deren Return-Path diese Domain nutzt, SPF verliert. Die Lösung: Lookups zählen, auch die verschachtelten in jedem include:, tote Einträge entfernen, eigene Server als ip4:/ip6: eintragen und Drittanbieter auf eigene Subdomains verlegen.

Was zählt zum SPF-Limit von 10 DNS-Lookups?

Sechs Begriffe zählen: die Mechanismen include, a, mx, ptr und exists sowie der Modifikator redirect. Braucht die Auswertung mehr als 10 davon, muss das Ergebnis permerror lauten. ip4, ip6 und all kosten nichts (RFC 7208, Abschnitt 4.6.4).

Das Limit gilt für die gesamte Auswertung, nicht für die eine Zeile in deinem DNS-Panel. Microsoft formuliert es klar: Ein include, das auf einen Eintrag mit drei weiteren includes zeigt, kostet vier Lookups, also garantieren weniger als 10 include:-Einträge nicht weniger als 10 DNS-Lookups (Microsoft Learn: SPF einrichten). Googles Hilfeseite vereinfacht das zu „bis zu 10 include-Tags“, was nur stimmt, wenn keines davon weiter verschachtelt ist (Google Workspace: SPF einrichten).

Stand: November 2026, nach RFC 7208.

Das zweite Limit: zwei leere Lookups

RFC 7208 empfiehlt außerdem, sogenannte Void Lookups, also Abfragen ohne Eintrag oder auf einen nicht existierenden Namen, auf zwei zu begrenzen; auch das Überschreiten ergibt permerror. In der Praxis trifft das Domains, die includes längst gekündigter Dienste behalten: Der Anbieter löscht den DNS-Namen, und dein Eintrag zeigt ins Leere. Ein include, dessen Ziel keinen SPF-Eintrag hat, ist schon allein ein permerror (so auch Microsoft).

Ein Eintrag pro Name

Ein Name darf nur einen TXT-Eintrag haben, der mit v=spf1 beginnt. Zwei Einträge, meist entstanden, weil ein neuer Anbieter als zweiter Eintrag statt zusammengeführt angelegt wurde, ergeben ebenfalls permerror. Lange Einträge kannst du in mehrere Zeichenketten in Anführungszeichen innerhalb eines TXT-Eintrags aufteilen; Empfänger fügen sie ohne Leerzeichen zusammen (RFC 7208, 3.3). Die DNS-Oberflächen von Hetzner, IONOS oder Strato sehen unterschiedlich aus, die Regel ist dieselbe.

Wie zählst du deine SPF-Lookups?

Frag deinen eigenen TXT-Eintrag mit dig ab, zähle die sechs Lookup-Begriffe darin, frag dann jedes Ziel von include: und redirect= ab und wiederhole das, bis du bei Einträgen nur mit ip4/ip6 ankommst. Die Summe über alle Ebenen ist die Zahl, die Empfänger sehen.

# 1. Your own record (exactly one line must start with v=spf1)
dig +short TXT example.com

# 2. Every include: in it, then every include: inside those
dig +short TXT mailgun.org
dig +short TXT _spf.mailgun.org

Von Hand wird das ab der zweiten Ebene mühsam, deshalb hier ein kurzes Bash-Skript, das den Baum durchläuft und ausgibt. Es nutzt nur dig, sed und tr und läuft unter Linux und macOS:

#!/usr/bin/env bash
# spf-count.sh: count the SPF terms that cost a DNS lookup, following include: and redirect=
# Usage: ./spf-count.sh example.com
spf() { dig +short TXT "$1" | sed 's/" "//g; s/"//g' | grep -i '^v=spf1'; }

count() {
  local domain=$1 depth=$2 n=0 term lterm rec
  rec=$(spf "$domain")
  printf '%*s%s: %s\n' $((depth * 2)) '' "$domain" "${rec:-NO SPF RECORD}" >&2
  for term in $rec; do
    term=${term#[+~?-]}
    lterm=$(printf '%s' "$term" | tr 'A-Z' 'a-z')
    case $lterm in
      include:*)  n=$((n + 1 + $(count "${term#*:}" $((depth + 1))))) ;;
      redirect=*) n=$((n + 1 + $(count "${term#*=}" $((depth + 1))))) ;;
      a|a:*|a/*|mx|mx:*|mx/*|ptr|ptr:*|exists:*) n=$((n + 1)) ;;
    esac
  done
  echo "$n"
}

total=$(count "$1" 0)
echo "Lookups: $total of 10"

chmod +x spf-count.sh
./spf-count.sh mailgun.org

Ausgabe, gekürzt:

mailgun.org: v=spf1 include:_spf.mailgun.org include:_spf.eu.mailgun.org -all
  _spf.mailgun.org: v=spf1 include:_spf1.mailgun.org include:_spf2.mailgun.org ~all
    _spf1.mailgun.org: v=spf1 ip4:159.135.224.0/20 ip4:69.72.32.0/20 ...
    _spf2.mailgun.org: v=spf1 ip4:161.38.192.0/20 ip4:143.55.224.0/21 ...
  _spf.eu.mailgun.org: v=spf1 ip4:141.193.32.0/23 ip4:159.135.140.80/29 ...
Lookups: 4 of 10

Die Summe ist, was ein include dieses Namens darunter kostet; das include selbst kommt noch hinzu. include:mailgun.org kostet in deinem Eintrag also 5 Lookups. Das Skript ist bewusst einfach: Es löst keine Makros auf (exists:%{i}… zählt als eins, was korrekt ist) und zählt nicht die A-Abfragen pro Host hinter mx.

Wie viel kostet das include der einzelnen Anbieter?

Wir haben das Skript gegen die includes laufen lassen, die Anbieter ihren Kunden vorgeben. Die Unterschiede sind groß, und ein einziges Helpdesk kann mehr als die Hälfte deines Budgets belegen.

Stand: November 2026, gemessen mit dem Skript oben am 14. November 2026. Anbieter ändern ihre Einträge ohne Ankündigung, also lass es erneut laufen, bevor du dich auf eine Zahl verlässt.

Wie behebst du „too many DNS lookups“?

Arbeite dich von der billigsten zur tiefgreifendsten Änderung vor: Unnötiges löschen, Lookups auf eigene Infrastruktur durch Adressen ersetzen und Massenversender auf Subdomains verlegen. Die meisten Domains kommen unter 10, bevor Flattening überhaupt nötig wird.

Nimm diesen Eintrag, der dem ähnelt, was viele kleine Firmen nach ein paar Jahren mit immer neuen Tools haben:

; Before: 17 lookups, every message gets spf=permerror
example.com.  3600  IN  TXT  "v=spf1 a mx include:_spf.google.com include:mailgun.org include:email.freshdesk.com include:_spf.salesforce.com ~all"

Das sind 1 (a) + 1 (mx) + 1 (Google) + 5 (Mailgun) + 7 (Freshdesk) + 2 (Salesforce) = 17 Lookups. Empfänger, die den ganzen Eintrag auswerten, melden für jede Mail von example.com permerror, auch für die normale Post der Mitarbeitenden.

1. Prüfe, welche Absender deine Domain wirklich im Return-Path verwenden

   SPF prüft die Domain im Envelope-Absender (MAIL FROM, in einer zugestellten Mail als Return-Path sichtbar), nicht die From-Adresse. Schick von jedem Tool eine Testmail an ein Gmail-Konto und öffne „Original anzeigen“. Steht im Return-Path bounces+123@vendor-mail.com, wird dein Eintrag für dieses Tool nie geprüft, und sein include ist Ballast. Viele Helpdesk-, CRM- und Newsletter-Tools arbeiten so und bestehen DMARC über DKIM mit deiner Domain.

2. Entferne includes von Tools, die du nicht mehr nutzt

   Gekündigte Dienste sind die häufigste Ursache sowohl für zu viele als auch für leere Lookups. Wenn niemand weiß, wofür ein include ist, schau es mit dig nach; gehört es zu einem Dienst, den du verlassen hast, lösche es.

3. Streiche ptr und hinterfrage a und mx

   ptr ist langsam, und RFC 7208 rät von der Veröffentlichung ab. a hilft nur, wenn der Webserver selbst Mails verschickt; mx nur, wenn deine Eingangsserver auch ausgehend senden. Bei Google Workspace oder Microsoft 365 sind die MX-Hosts schon im include des Anbieters enthalten, mx ist dann ein verschwendeter Lookup.

4. Trage eigene Server als ip4:/ip6: ein

   Für einen Server unter deiner Kontrolle, etwa einen Anwendungsserver, einen NetSendo-MTA oder ein Büro-Relay, schreib die Adresse direkt: ip4:203.0.113.10. Das kostet nichts und ändert sich nur, wenn du den Server wechselst.

5. Verlege Massen- und Marketingversender auf Subdomains

   Richte Mailgun auf mg.example.com ein, Amazon SES mit eigener MAIL-FROM-Domain wie bounce.example.com und so weiter. Jede Subdomain hat ihren eigenen SPF-Eintrag und ihr eigenes Limit von 10. Warum DMARC trotzdem besteht, erklärt der nächste Abschnitt.

6. Flache den Rest nur ab, wenn es sein muss

   Bringt dich ein Anbieter, der auf der Hauptdomain bleiben muss, immer noch über das Limit, ersetze sein include durch seine veröffentlichten Adressbereiche und trag dir einen Prüftermin in den Kalender ein.

Nach den Schritten 1–5 sieht dieselbe Domain so aus:

; After: each name has its own budget of 10
example.com.     3600  IN  TXT  "v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all"
mg.example.com.  3600  IN  TXT  "v=spf1 include:mailgun.org ~all"
bounce.example.com.  3600  IN  TXT  "v=spf1 include:amazonses.com ~all"
bounce.example.com.  3600  IN  MX   10 feedback-smtp.eu-west-1.amazonses.com.

Der Eintrag der Hauptdomain kostet jetzt 3 Lookups, mg.example.com 5 und bounce.example.com 1, jeweils mit Luft im eigenen Limit. Freshdesk ist von der Hauptdomain verschwunden, weil sein Return-Path in diesem Beispiel die Domain des Anbieters war. Der MX-Eintrag auf der SES-Subdomain ist von Amazon SES für eine eigene MAIL-FROM-Domain vorgeschrieben, der SPF-Eintrag dort ist genau der von SES dokumentierte (Amazon SES: eigene MAIL-FROM-Domain). Verwende im MX-Host die Region deines SES-Kontos, etwa eu-central-1 für Frankfurt.

⚠️ Achtung: Entferne kein include, bevor du an einer echten Mail bestätigt hast, wohin der Return-Path des Tools zeigt. Nimmst du einen Absender heraus, dessen Envelope deine Hauptdomain nutzt, wird sein SPF-Ergebnis zu fail; DMARC besteht dann nur noch, wenn das Tool auch mit DKIM für deine Domain signiert.

Ist SPF-Flattening eine gute Idee?

Flattening ersetzt ein include durch die IP-Bereiche, auf die es gerade aufgelöst wird, sodass der Absender keinen Lookup mehr kostet. Das funktioniert, aber du übernimmst eine Aufgabe, die der Anbieter bisher für dich erledigt hat: zu bemerken, wenn sich seine Adressen ändern.

; Flattened by hand: 0 lookups for this sender, but the list goes stale when the vendor adds a range
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ip4:198.51.100.0/24 ip4:203.0.113.0/25 ~all"

Microsofts Empfehlung ist eine gute Faustregel: Flache nur Anbieter mit stabilen, dokumentierten Bereichen ab, nie Microsoft 365 selbst, dessen Versandadressen sich häufig ändern. Wenn du abflachst, dokumentiere, was du ersetzt hast, verfolge die Doku des Anbieters, prüfe die Einträge mindestens vierteljährlich und teste nach jeder Änderung (Microsoft Learn).

Statisches vs. automatisches Flattening

Statisches Flattening ist das Beispiel oben: Du kopierst die Adressen einmal. Das ist kostenlos und durchschaubar, bricht aber lautlos an dem Tag, an dem der Anbieter einen Bereich hinzufügt, denn Mails aus dem neuen Bereich fallen bei SPF durch, während im DNS-Panel alles gut aussieht. Dienste für automatisches Flattening lösen die includes regelmäßig neu auf und veröffentlichen das Ergebnis, meist über ein include oder einen CNAME auf ihre eigene Zone. Die Liste bleibt aktuell, aber du hast eine bezahlte Abhängigkeit in deiner Mail-Authentifizierung; fällt der Dienst aus, fällt auch dein SPF.

Warum löst eine Versand-Subdomain das Problem?

Weil SPF für genau die Domain im Envelope-Absender ausgewertet wird und jeder Name seinen eigenen Eintrag und sein eigenes Budget von 10 Lookups hat. Microsoft schreibt ausdrücklich, dass jede Subdomain ihr eigenes Budget von 10 Lookups hat, und empfiehlt Subdomains für E-Mail-Dienste, die du nicht selbst kontrollierst (Microsoft Learn).

DMARC sorgt dafür, dass das auch für die sichtbare From-Adresse funktioniert. DMARC nutzt nur das SPF-Ergebnis für die MAIL-FROM-Identität, und diese muss zur From-Domain passen (Alignment) (RFC 9989, 4.4.2). Standardmäßig ist das Alignment entspannt (aspf=r), also teilen bounce.example.com und news@example.com die Organisationsdomain example.com und gelten als aligned. Du kannst weiter von news@example.com senden, während SPF auf der Subdomain geprüft wird.

Das passt auch zu dem, was Gmail von jedem Absender verlangt: SPF und DKIM für deine Domain, auf Ebene der Organisationsdomain aufeinander abgestimmt (Google: Richtlinien für E-Mail-Absender). Eine eigene Subdomain fürs Marketing hat einen zweiten Vorteil: Bounces und Beschwerden aus Kampagnen landen auf einem Namen, den du getrennt beobachten kannst. Eine vollständige Anleitung zu SPF, DKIM, DMARC und Warm-up für eigene Server findest du in unserem Leitfaden zur Zustellbarkeit für Self-Hoster (auf Englisch).

💡 Tipp: Setzt dein DMARC-Eintrag aspf=s (strikt), ist ein Envelope auf der Subdomain nicht aligned, und SPF zählt für DMARC nicht mehr. Prüf deinen Eintrag mit dig +short TXT _dmarc.example.com, bevor du Absender verlegst.

Soll der Eintrag mit ~all oder -all enden?

Sobald DMARC aktiv ist, funktioniert beides, denn DMARC wertet sowohl ~all (Softfail) als auch -all (Fail) als SPF-Fehlschlag. Google empfiehlt ~all (Google Workspace); Microsoft empfiehlt -all für Microsoft-365-Domains, die auch DKIM und DMARC nutzen (Microsoft Learn).

Der Unterschied liegt darin, was passiert, bevor DMARC überhaupt läuft. RFC 9989 warnt, dass manche Empfänger SPF früh in der SMTP-Sitzung prüfen; -all kann dann eine Mail abweisen, die über eine passende DKIM-Signatur DMARC bestanden hätte, und solche Ablehnungen tauchen nie in deinen DMARC-Aggregatberichten auf (RFC 9989, 7.1). Das betrifft Weiterleitungen und Mailinglisten. Eine praktische Regel:

• Solange du includes aufräumst und Absender verlegst, nimm ~all.
• Für eine Subdomain mit nur einem Absender, etwa mg.example.com, ist -all risikoarm: Nichts anderes sollte von dort senden.
• Für die Hauptdomain mit Mitarbeiterpost bietet ~all plus DMARC mit p=quarantine oder p=reject Durchsetzung ohne frühe SPF-Ablehnungen.

Keine der beiden Varianten behebt einen permerror: Bei zu vielen Lookups wird das all am Ende nie erreicht.

Wie prüfst du, ob die Korrektur wirkt?

Prüf den veröffentlichten Eintrag von außerhalb deines Netzes, zähl die Lookups erneut, schick dann eine echte Mail und lies den Header Authentication-Results. Nach Ablauf der TTL des alten Eintrags solltest du spf=pass für die Envelope-Domain sehen.

# The record the world sees (ask a public resolver, not your cache)
dig +short TXT example.com @1.1.1.1

# Exactly one SPF record per name
dig +short TXT example.com @1.1.1.1 | grep -c 'v=spf1'

# The count after the change
./spf-count.sh example.com 2>/dev/null

Schick danach von jedem Tool eine Mail an ein Gmail- oder Outlook.com-Postfach und sieh dir die Header an. Ein kaputter Eintrag sieht so aus, wobei DKIM das DMARC-Ergebnis noch rettet:

Authentication-Results: mx.receiver.example;
       spf=permerror smtp.mailfrom=news@example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Nach der Korrektur willst du spf=pass und ein smtp.mailfrom auf der geplanten Domain sehen. Bekommst du dmarc=fail, weil SPF und DKIM beide scheitern, hilft unser Artikel zum Gmail-Fehler 550-5.7.26 (unauthenticated).

Beobachte deine DMARC-Aggregatberichte (rua) zwei Wochen nach der Änderung: Eine Quelle, die plötzlich SPF fail zeigt, ist meist ein Absender, von dem du nichts wusstest und der von der Hauptdomain sendet.

SPF-Lookups beim Versand mit NetSendo

NetSendo veröffentlicht kein eigenes SPF-include und hängt deshalb nie eine verschachtelte Kette an deinen Eintrag. Was dein SPF braucht, hängt davon ab, wie ein Postfach versendet:

• NetSendo MTA (seit 2.11.0 in jeder Installation): Der Eintrag der Absenderdomain muss die öffentliche Adresse des Servers oder die dedizierte IP des Postfachs als ip4:/ip6: enthalten. Das kostet keinen Lookup. Das Panel zeigt den genauen Eintrag an.
• SMTP-Relays: NetSendo erkennt Amazon SES, SendGrid, Google Workspace, Microsoft 365 und Mailgun am SMTP-Host. Für Amazon SES und SendGrid fügt es kein include hinzu, weil diese Relays mit ihrer eigenen Envelope-Domain senden (oder der eigenen MAIL-FROM-Domain, die du dort einrichtest).
• Return-Path: Ist für ein Postfach die Bounce-Verarbeitung aktiv, setzt NetSendo den Return-Path auf dessen Bounce-Adresse; eine Bounce-Adresse auf einer Subdomain verlegt die SPF-Prüfung also dorthin. Die Einrichtung steht in der Konfigurationsdokumentation.

Mit GOLD prüft das Deliverability-Modul SPF, DKIM und DMARC jeder Domain, und sein SPF-Generator behält deinen bestehenden Eintrag und fügt nur die includes hinzu, die deine NetSendo-Postfächer brauchen. Er zeigt die Anzahl der Lookups und markiert Einträge über 8. Diese Zahl umfasst die Begriffe im Eintrag selbst und löst verschachtelte includes nicht auf; bei einem Eintrag voller Drittanbieter-includes lass deshalb zusätzlich das Skript aus diesem Artikel laufen. Für den Einstieg folge dem Schnellstart.

Häufig gestellte Fragen

Quellen

• RFC 7208: Sender Policy Framework (SPF)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain
• Google Workspace Admin Help: Set up SPF
• Google: Email sender guidelines
• Amazon SES: Using a custom MAIL FROM domain