SPF: zu viele DNS-Lookups – so beheben Sie das 10er-Limit und den PermError

Was „zu viele DNS-Lookups“ bedeutet

Prüft ein empfangender Server SPF, liest er auf der Domain des Envelope-Absenders (der MAIL FROM-Adresse, später als Return-Path sichtbar) den TXT-Eintrag, der mit v=spf1 beginnt, und wertet seine Terme von links nach rechts aus. Manche Terme lösen eine weitere DNS-Abfrage aus. RFC 7208, Abschnitt 4.6.4, begrenzt diese Terme auf 10 pro Prüfung, einschließlich derer in jedem eingebundenen Eintrag. Braucht die Auswertung einen elften, muss der Empfänger abbrechen und permerror liefern, das Ergebnis für veröffentlichte Einträge, die sich nicht korrekt auswerten ließen.

Meist fällt das an einer von drei Stellen auf: im Authentication-Results-Header einer zugestellten Nachricht (RFC 8601), etwa spf=permerror smtp.mailfrom=example.com, in einer Bounce-Nachricht, die zu viele Lookups erwähnt, oder als SPF-Fehler in Ihren DMARC-Sammelberichten.

Zwei Details machen den Fehler verwirrend. Empfänger zählen die Abfragen während der Auswertung, und die Auswertung endet beim ersten Term, der zutrifft. Mail eines Dienstes, der früh im Eintrag steht, kann weiterhin bestehen, während Mail eines Dienstes, dessen Include erst nach der zehnten Abfrage folgt, permerror erhält; das Problem wirkt dadurch sporadisch. Außerdem ist permerror kein fail: SPF hilft schlicht nicht mehr. DMARC besteht, wenn SPF oder DKIM für eine Domain besteht, die zur From-Adresse passt (Alignment, RFC 9989). Eine Nachricht mit passender DKIM-Signatur besteht also weiterhin, eine, die sich allein auf SPF stützte, nicht. Wie ein Empfänger darüber hinaus mit permerror umgeht, entscheidet er selbst.

Welche SPF-Terme zum Limit zählen und welche nicht

Das Budget gilt für die gesamte Auswertung, nicht für einen einzelnen Eintrag. Ein Include kostet eine Abfrage für sich selbst und dazu alles, was der Eintrag dahinter kostet, bis zur letzten Verschachtelungsebene. Anbieter ändern ihre eigenen Einträge, etwa wenn sie ihre Adressbereiche auf mehr verschachtelte Includes verteilen. Ihre Summe kann sich also ändern, ohne dass Sie etwas anfassen.

Das Limit gibt es, weil SPF-Einträge Empfänger dazu bringen, im Auftrag des Veröffentlichenden DNS-Abfragen zu stellen; Abschnitt 11.1 von RFC 7208 beschreibt, wie ein Angreifer das sonst nutzen könnte, um das DNS eines Dritten zu überlasten. Der RFC empfiehlt außerdem ein Zeitlimit für die gesamte Prüfung von mindestens 20 Sekunden. Wird es überschritten, lautet das Ergebnis temperror, ein vorübergehender Fehler, nicht permerror.

Das zweite Limit: höchstens zwei Void-Lookups

RFC 7208 ergänzt ein eigenes Limit für Abfragen, die leer zurückkommen: eine Antwort ohne Einträge (NOERROR mit null Antworten) oder ein Name Error (NXDOMAIN, der Name existiert nicht). Man nennt sie Void-Lookups. Implementierungen SOLLEN höchstens zwei zulassen, und auch ein Überschreiten dieser Grenze führt zu permerror, selbst wenn die Gesamtzahl noch unter 10 liegt. So kann ein SPF-Eintrag Empfänger nicht hinter langen Listen nicht existierender Namen herschicken.

Void-Lookups stammen meist aus Altlasten:

• a:old-web.example.com, nachdem der DNS-Name des alten Servers gelöscht wurde.
• mx oder mx:example.org auf einem Namen ohne MX-Einträge. Der Mechanismus darf nicht auf den A-Eintrag des Namens ausweichen und findet daher schlicht nichts.
• a auf der Hauptdomain, nachdem die Website zu einem Hoster umgezogen ist, der nur unter www antwortet.

Bei include: ist die Regel strenger. Existiert der eingebundene Name nicht oder veröffentlicht er keinen SPF-Eintrag, zählt das Include nicht bloß als Void-Lookup, sondern macht das gesamte Ergebnis sofort zu permerror (Abschnitt 5.2). Genau das passiert, wenn ein Anbieter, den Sie nicht mehr nutzen, die Domain stilllegt, die Ihr Eintrag noch einbindet. Fragen Sie jeden Namen ab, auf den Ihr Eintrag verweist; ein Name ohne Antwort gehört korrigiert oder entfernt.

So zählen Sie Ihre SPF-Lookups von Hand

Beginnen Sie bei der Domain des Envelope-Absenders, die Sie im Return-Path-Header einer von Ihnen gesendeten Nachricht sehen, und gehen Sie den Eintrag rekursiv durch:

1. Eintrag lesen: dig +short TXT example.com oder unter Windows nslookup -type=TXT example.com.
2. Für jedes include, a, mx, ptr, exists und redirect 1 notieren, für ip4, ip6 und all 0.
3. Für jedes Include und jeden Redirect den Zieleintrag lesen und genauso bewerten, bis zur tiefsten Ebene.
4. Alles addieren und jeden Namen festhalten, der keine Einträge geliefert hat.

Ein hypothetischer Eintrag mit auf den ersten Blick nur fünf abfragenden Termen:

example.com.  TXT  "v=spf1 mx include:_spf.mail.example.net include:spf.crm.example.org include:news.example.net a -all"

Die Summe ist der ungünstigste Fall. Ein Absender, auf den das erste Include zutrifft, braucht höchstens fünf Lookups und besteht. Ein Absender, auf den vorher nichts zutrifft, erreicht das abschließende a, den elften Lookup; gefälschte Mail erhält deshalb permerror statt des fail, das -all bewirken sollte. Zählen Sie neu, sobald Sie einen Versanddienst hinzufügen, und auch sonst in regelmäßigen Abständen, denn eingebundene Einträge ändern sich ohne Ankündigung.

So kommen Sie wieder unter zehn, ohne Mail zu verlieren

• Nicht mehr genutzte Includes entfernen. Ein früherer Mailanbieter, ein gekündigtes Newsletter-Tool, ein CRM, das Sie nur ein paar Wochen getestet haben. DMARC-Sammelberichte zeigen, welche Quellen tatsächlich in Ihrem Namen senden, und helfen so, überflüssige Includes zu finden. Sprechen Sie vor dem Entfernen mit den Verantwortlichen des jeweiligen Dienstes.
• Prüfen, ob ein Include überhaupt ausgewertet wird. SPF wird gegen die Domain des Envelope-Absenders geprüft. Zeigen die Nachrichten eines Dienstes dessen eigene Domain im Return-Path, prüfen Empfänger den SPF-Eintrag dieser Domain, nicht Ihren, und Ihr Include bewirkt für diese Mail nichts. Klären Sie das anhand der Dokumentation des Anbieters, bevor Sie es streichen.
• a und mx durch ip4 und ip6 ersetzen, wo Sie die Server selbst betreiben. Sendet Ihr eigener Server von 192.0.2.10, kostet ip4:192.0.2.10 nichts, a dagegen einen Lookup. Fragen Sie sich, ob mx überhaupt hineingehört: Die Server, die Ihre Mail empfangen, versenden nicht unbedingt auch, und gehören sie Ihrem Mailanbieter, deckt dessen Include seine Versandserver womöglich schon ab. Passen Sie die Adresse an, wenn der Server umzieht.
• Jedem Versender mit hohem Volumen eine eigene Subdomain geben. Lassen Sie einen Newsletter- oder Ticketdienst eine Bounce-Domain wie news.example.com als Envelope-Absender verwenden, mit eigenem SPF-Eintrag und eigenem Limit von 10. SPF wird nicht vererbt, die Subdomain braucht diesen Eintrag also. Mit dem standardmäßigen Relaxed Alignment von DMARC passt news.example.com weiterhin zu einer From-Adresse unter example.com. Viele Dienste nennen das eine eigene Return-Path- oder Bounce-Domain.
• ptr streichen. Laut RFC 7208 SOLL er NICHT veröffentlicht werden: Er ist langsam, hängt vom Reverse-DNS ab, das der Inhaber der verbindenden IP-Adresse kontrolliert, und verbraucht Lookups. Ersetzen Sie ihn durch ip4/ip6 oder das Include des Anbieters.
• Umsortieren ist keine Lösung. Steht der Versender mit dem meisten Volumen vorn, erreichen weniger Nachrichten den elften Lookup, aber für alles weiter hinten bleibt der Eintrag kaputt, auch für gefälschte Mail, die eigentlich auf -all treffen sollte.

Auch DKIM nimmt Druck heraus. DMARC braucht nur ein bestandenes Ergebnis mit Alignment, und DKIM übersteht Weiterleitungen in der Regel, SPF nicht. Sorgen Sie dafür, dass jeder Dienst mit Ihrer Domain signiert, und kürzen Sie danach den SPF-Eintrag.

SPF-Flattening: weniger Lookups, mehr Pflege

Beim Flattening ersetzen Sie ein Include durch die ip4- und ip6-Bereiche, in die es heute aufgelöst wird. Die Zahl der Lookups sinkt, aber Ihr Eintrag enthält nun eine Kopie fremder Daten, und diese Kopie aktualisiert sich nicht von selbst.

Automatische Flattening-Dienste lösen die Includes regelmäßig auf und schreiben Ihren Eintrag neu. Das behebt veraltete Bereiche, gibt aber einem Dritten eine Rolle in Ihrem DNS, und ein fehlgeschlagenes Update legt Ihr SPF lahm. Nutzen Sie zuerst die anderen Wege. Wenn Sie doch flatten, halten Sie fest, welches Include Sie wann ersetzt haben, gleichen Sie regelmäßig mit den veröffentlichten Bereichen des Anbieters ab und testen Sie SPF nach jeder Änderung (Microsoft Learn gibt seinen Kunden denselben Rat).

Ein SPF-Eintrag pro Name, richtig aufgeteilt

Ein Name darf genau einen TXT-Eintrag haben, der mit v=spf1 beginnt. Bei zweien kann der Empfänger nicht wählen und liefert permerror (RFC 7208, Abschnitt 4.5). Das passiert oft, wenn die Einrichtungsanleitung eines neuen Dienstes sagt „Fügen Sie diesen TXT-Eintrag hinzu“ und jemand einen zweiten SPF-Eintrag anlegt, statt den ersten zu bearbeiten. Ein zweiter Eintrag verdoppelt das Budget also nicht; führen Sie beide zusammen:

# Falsch: zwei SPF-Einträge auf einem Namen
example.com.  TXT  "v=spf1 include:_spf.mail.example.net -all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

# Richtig: ein Eintrag
example.com.  TXT  "v=spf1 include:_spf.mail.example.net include:spf.crm.example.org -all"

Andere TXT-Einträge auf demselben Namen, etwa Verifizierungs-Token, stören nicht; es zählen nur Einträge, die mit v=spf1 beginnen. Eine einzelne Zeichenkette in einem TXT-Eintrag fasst höchstens 255 Zeichen. Ein längerer SPF-Eintrag bleibt ein einziger TXT-Eintrag aus mehreren Zeichenketten in Anführungszeichen, die Empfänger ohne Leerzeichen zusammenfügen (Abschnitt 3.3). Beenden Sie eine Zeichenkette daher mit einem Leerzeichen, wo ein Term endet:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.mail.example.net " "include:spf.crm.example.org -all"

Weitere Fehler führen zum selben permerror: ein Syntaxfehler an beliebiger Stelle im Eintrag, etwa include= statt include: (Abschnitt 4.6), oder ein Include auf eine Domain ohne SPF-Eintrag. SPF-Einträge werden auch nicht vererbt: Jeder Name, der als Envelope-Absender dient, braucht seinen eigenen Eintrag, und jeder hat sein eigenes Limit von 10.

Was der kostenlose SPF- und DMARC-Checker zählt

Der kostenlose Snapshot führt ohne Anmeldung acht passive Prüfungen an einer öffentlichen Domain aus; eine davon liest Mail-Einträge im DNS. Er ist kein Penetrationstest und nicht das Audit mit sechs Bereichen, und er versendet keine Mail.

• Exakter Hostname. Er liest den SPF-Eintrag des eingegebenen Namens, ohne Rückgriff auf die übergeordnete Domain. Geben Sie die Domain des Envelope-Absenders selbst ein, also zum Beispiel example.com statt www.example.com.
• Zählung auf oberster Ebene. Er zählt die DNS-abfragenden Terme in diesem Eintrag (include, a, mx, ptr, exists und redirect) und meldet mehr als zehn als mittleres Risikosignal.
• Nicht verfolgt. include: und redirect= verfolgt er nicht, Void-Lookups zählt er nicht, und einen zweiten SPF-Eintrag auf demselben Namen meldet er nicht. Das Beispiel mit fünf Termen oben besteht diese Zählung, obwohl Empfänger elf Lookups brauchen. Zählen Sie deshalb zusätzlich selbst rekursiv.
• Weitere SPF-Signale. +all wird als hohes Risiko gemeldet, ?all als niedriges; ein fehlender SPF- oder DMARC-Eintrag wird gemeldet, wenn der Host MX-Einträge hat.

Wenn Sie die Mail-DNS-Prüfung zuerst sehen möchten, nutzen Sie den kostenlosen SPF- und DMARC-Checker: Er führt denselben Snapshot aus und zeigt diese Prüfung über den anderen sieben. Den Rest des Eintrags, von ~all oder -all bis zum Weg von DMARC none zu reject, behandelt der Leitfaden zu SPF und DMARC.