SPF: Zu viele DNS-Lookups (PermError) beheben

Eintrag mit dem Domain-Check prüfen

Geben Sie Ihre Domain in unseren kostenlosen SPF-, DKIM- und DMARC-Check ein. Er löst alle include- und redirect-Angaben rekursiv auf und zeigt das Ergebnis als „x von 10 erlaubten DNS-Lookups“. Ab 8 warnt er, dass ein weiterer Dienst den Eintrag kippen kann. Eingebundene Domains ohne gültigen SPF-Eintrag listet er separat auf.

Warum nachzählen statt schätzen: Die Werte ändern sich, sobald ein Anbieter seinen eigenen Eintrag umbaut. Ältere Anleitungen nennen deshalb teils andere Zahlen als heute.

Jedem Eintrag einen Versender zuordnen

Schreiben Sie zu jedem include, a und mx auf, welcher Dienst oder Server damit gemeint ist und ob er heute noch mit Ihrer Domain versendet. Zur Orientierung: So viele Lookups kosten gängige Einbindungen, von uns am 16. Oktober 2026 per DNS rekursiv nachgezählt (einschließlich des include selbst):

Die meisten großen Anbieter listen ihre IP-Bereiche inzwischen direkt auf und kosten nur einen Lookup. Teuer sind vor allem Dienste mit verschachtelten Einträgen wie Mailgun (fünf) – und die Summe vieler kleiner Posten. Ein typischer gewachsener Eintrag:

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

Das sind 1 + 1 + 1 + 1 + 5 + 2 + 2 = 13 Lookups – drei zu viel.

Warum der Blick auf jeden Eintrag lohnt: In gewachsenen Einträgen steht fast immer etwas, das niemand mehr braucht: der Newsletter-Dienst von vor drei Jahren, das alte Ticketsystem, das nackte mx aus der Hoster-Vorlage. Die SPF-Angabe für Mailgun nennt Mailgun in seiner Dokumentation zur Domain-Verifizierung.

Ungenutzte Dienste entfernen

Streichen Sie jedes include, zu dem es keinen aktiven Versender mehr gibt. Das ist die sauberste Lösung, weil sie nichts kostet und keine Wartung nach sich zieht. Sind Sie unsicher, ob ein Dienst noch sendet, helfen DMARC-Berichte (rua=): Sie zeigen, welche Server tatsächlich mit Ihrer Domain verschicken.

Warum zuerst: Microsoft nennt das Konsolidieren der Dienste ausdrücklich als Strategie. Ein entfernter Eintrag beseitigt außerdem mögliche Void Lookups, falls der alte Dienst seine SPF-Domain inzwischen abgeschaltet hat.

a, mx und ptr prüfen

a erlaubt die IP-Adresse, auf die Ihre Domain zeigt (meist der Webserver), mx die Server, die Ihre eingehende Post annehmen. Beide kosten je einen Lookup und sind oft nur aus einer Vorlage übernommen. Prüfen Sie: Versendet der Webserver selbst Mails mit Ihrer Domain? Verschicken Ihre MX-Server auch ausgehende Post, und sind sie nicht schon über das include des Hosters abgedeckt? Wenn nein, kann der Mechanismus weg. ptr sollte laut RFC 7208 grundsätzlich nicht mehr verwendet werden.

Vorsicht beim Hoster-Standard: Manche Hoster legen a und mx selbst an, ALL-INKL etwa v=spf1 a mx include:spf.kasserver.com ~all. Entfernen Sie die beiden nur, wenn Sie wissen, dass Ihre Mails (einschließlich Kontaktformular) über die im include genannten Server laufen. Testen Sie anschließend mit dem E-Mail-Spam-Test.

Massenversand auf eine Unterdomain verlegen

Newsletter-, Marketing- und Transaktionsdienste müssen nicht über die Hauptdomain laufen. Versenden Sie stattdessen über eine Unterdomain wie news.firma.de oder mg.firma.de. Jede Unterdomain hat ihren eigenen SPF-Eintrag – und damit ein eigenes Budget von 10 Lookups.

Im Beispiel von oben fallen damit a und mx weg (Lösung 2) und Mailgun zieht auf die Unterdomain um. Aus 13 Lookups werden 6 auf der Hauptdomain.

Warum Microsoft das empfiehlt: Laut Microsoft sollen Dienste, die Sie nicht direkt kontrollieren, über eine Unterdomain versenden, damit Probleme beim Massenversand nicht die Reputation der Mails Ihrer Mitarbeitenden belasten. Die Einhaltung des Lookup-Limits nennt Microsoft als weiteren Grund. DMARC deckt Unterdomains automatisch ab, solange dort kein eigener DMARC-Eintrag steht.

Auf DKIM setzen, wo SPF ohnehin nicht greift

SPF prüft nicht die sichtbare Absenderadresse, sondern die Rücklaufadresse (Return-Path, „MAIL FROM“). Viele Newsletter-Dienste versenden mit einer Rücklaufadresse auf ihrer eigenen Domain. Dann fragt der Empfänger den SPF-Eintrag des Dienstes ab, nicht Ihren. Ein include für diesen Dienst in Ihrem Eintrag wird bei solchen Mails nie ausgewertet und kostet nur einen Lookup.

DMARC besteht in diesem Fall über DKIM: Signiert der Dienst mit Ihrer Domain, passt die Signatur zur Absenderadresse. So arbeitet zum Beispiel Brevo – wie Sie die DKIM-Einträge dort anlegen, zeigt unsere Brevo-Anleitung.

So prüfen Sie es: Schicken Sie eine Mail des Dienstes an unseren E-Mail-Spam-Test. Der Bericht zeigt für SPF und DKIM jeweils, ob sie zu Ihrer Domain passen. Besteht DKIM mit Ihrer Domain, während SPF für eine Domain des Dienstes geprüft wird, ist das include in Ihrem SPF überflüssig. Fordert der Dienst es in seiner Hilfe trotzdem, fragen Sie dort nach, wofür es gebraucht wird.

Letzter Ausweg: SPF-Flattening

Beim „Flattening“ ersetzen Sie ein include durch die IP-Bereiche, die darin stehen – ip4: und ip6: kosten keinen Lookup. Das senkt die Zahl sofort, hat aber einen Haken: Ändert der Anbieter seine Adressen, steht in Ihrem Eintrag eine veraltete Liste, und legitime Mails fallen bei SPF durch, ohne dass Sie es merken.

• Nur für stabile Anbieter: Microsoft hält Flattening für vertretbar bei Diensten mit dokumentierten, selten geänderten IP-Bereichen.
• Nie für Microsoft 365: spf.protection.outlook.com soll laut Microsoft nicht abgeflacht werden, weil sich die Sende-IPs häufig ändern. Dasselbe gilt für Clouddienste mit wechselnden Adressen.
• Dokumentieren und pflegen: Notieren Sie, welche Einträge Sie ersetzt haben, und gleichen Sie sie laut Microsoft mindestens vierteljährlich mit den Angaben des Anbieters ab.

Warum zuletzt: Die Lösungen 1 bis 4 beseitigen die Ursache, Flattening verschiebt das Problem in die Wartung. Automatische Flattening-Dienste nehmen diese Arbeit ab, machen Ihren SPF-Eintrag aber von einem weiteren Anbieter abhängig.