SPF too many lookups: Das 10-Lookup-Limit verstehen und lösen

Woher das Limit kommt

RFC 7208 legt fest, dass ein Empfänger bei der Auswertung eines SPF-Records höchstens zehn DNS-Abfragen auslösen darf, die durch Mechanismen oder Modifier entstehen. Das Limit schützt die Empfänger vor Records, die beliebig tief verschachtelt sind und bei jeder eingehenden Mail Dutzende Abfragen verursachen würden. Wird es überschritten, ist das Ergebnis permerror, und die Domain gilt praktisch als ohne SPF.

Das Limit gilt pro Auswertung, also für den gesamten Baum aus dem Record der Domain und allen darin eingebundenen Records. Ein include, das selbst drei weitere includes enthält, kostet dich also nicht einen Lookup, sondern vier.

Welche Mechanismen zählen

Nur Mechanismen, für die der Empfänger DNS befragen muss, zählen zum Limit. Die Adressmechanismen ip4 und ip6 sowie all kosten nichts, weil die Information direkt im Record steht. Zusätzlich gibt es ein zweites Limit: Höchstens zwei Lookups dürfen ein leeres Ergebnis liefern (void lookups), etwa ein include auf einen Hostnamen ohne SPF-Record. Danach darf der Empfänger ebenfalls mit permerror abbrechen.

• include: ein Lookup plus alle Lookups des eingebundenen Records
• a: ein Lookup (A- oder AAAA-Abfrage)
• mx: ein Lookup für die MX-Liste; die Adressabfragen der einzelnen Mailserver sind auf zehn pro mx begrenzt und zählen nicht zum Gesamtlimit
• ptr: ein Lookup, veraltet und von vielen Empfängern ignoriert
• exists: ein Lookup
• redirect=: ein Lookup plus alle Lookups des Zielrecords
• ip4, ip6, all: kein Lookup

Was typische Dienste kosten

Die Kosten eines includes hängen davon ab, wie der Anbieter seinen eigenen Record aufgebaut hat. Sie können sich ändern, wenn der Anbieter umbaut, deshalb lohnt sich eine regelmäßige Prüfung mit dem SPF Checker. Die folgenden Werte sind Erfahrungswerte zum Zeitpunkt des Schreibens.

• Microsoft 365: include:spf.protection.outlook.com kostet in der Regel zwei Lookups
• Google Workspace: include:_spf.google.com kostet drei Lookups, weil der Record drei Netblock-Records einbindet
• Mailchimp: include:servers.mcsv.net, meist ein bis zwei Lookups
• SendGrid: include:sendgrid.net, ein bis zwei Lookups
• HubSpot, Zendesk, Salesforce: jeweils zwischen einem und vier Lookups, je nach Region und Produkt

Rechnest du das zusammen, ist ein Record mit Microsoft 365, Google Workspace, einem Newsletter-Tool, einem CRM und einem Ticketsystem schon bei zehn oder mehr Lookups, bevor der alte Hoster überhaupt dazukommt.

Strategie 1: Aufräumen und ip4/ip6 nutzen

Der wirksamste Schritt ist der langweiligste: Prüfe, welche Dienste tatsächlich noch Mails im Namen der Domain versenden. Der Hoster von vor drei Jahren, das Newsletter-Tool, das der Kunde gekündigt hat, und der Testaccount eines Entwicklers sind Klassiker. DMARC-Aggregate-Reports zeigen dir zuverlässig, welche Quellen in den letzten Wochen aktiv waren.

Dienste mit festen IP-Adressen, etwa ein eigener Mailserver oder ein Relay im Rechenzentrum, bindest du direkt per ip4 oder ip6 ein. Das kostet keinen Lookup. Wichtig: Nur bei Adressen, die du selbst kontrollierst. Die IP-Adressen großer Anbieter abzuschreiben ist Flattening durch die Hintertür.

Vorher, 12 Lookups:
v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:mail.zendesk.com include:spf.alter-hoster.de mx -all

Nachher, 5 Lookups:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mail.zendesk.com ip4:203.0.113.10 -all

Strategie 2: Subdomains pro Absender

Jede Domain und jede Subdomain hat ihr eigenes Lookup-Limit. Massenversender wie Newsletter-Tools, CRM-Systeme oder Transaktionsmail-Dienste müssen nicht von der Hauptdomain senden. Richte newsletter.beispiel.de oder crm.beispiel.de mit einem eigenen SPF-Record ein und lass den Dienst diese Subdomain als Envelope-From verwenden.

Das entlastet nicht nur den Record der Hauptdomain, sondern trennt auch die Reputation: Ein Newsletter mit hoher Beschwerderate zieht die Transaktionsmails nicht mit runter. Bei DMARC musst du dann nur darauf achten, dass die Subdomain über sp= oder einen eigenen DMARC-Record abgedeckt ist.

beispiel.de:
v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 -all

newsletter.beispiel.de:
v=spf1 include:servers.mcsv.net -all

crm.beispiel.de:
v=spf1 include:_spf.salesforce.com -all

Strategie 3: Flattening und SPF-Makros

Flattening ersetzt alle includes durch die aufgelösten IP-Netze. Der Record hat dann null Lookups, wächst aber schnell auf mehrere hundert Zeichen. Das eigentliche Problem: Sobald ein Anbieter seine Adressen ändert, ist dein Record falsch, und du merkst es erst, wenn Mails im Spam landen. Ohne einen automatisierten Prozess, der den Record täglich neu erzeugt, ist Flattening ein Wartungsrisiko.

SPF-Makros sind ein Mittel für Spezialfälle. Mit exists:%{i}._spf.beispiel.de wird pro Absender-IP genau eine Abfrage gestellt, deren Antwort du in deiner eigenen Zone steuerst. Das reduziert den Record auf einen Lookup, verlagert die Komplexität aber in DNS-Automatisierung, die du selbst betreiben oder einkaufen musst. Für die meisten Agenturkunden ist Aufräumen plus Subdomains die bessere Wahl.

So gehst du vor

In dieser Reihenfolge löst du das Problem in den meisten Fällen innerhalb einer Stunde.

1. Record durch den SPF Checker laufen lassen und die Lookup-Zahl pro include notieren.
2. Mit dem Kunden klären, welche Dienste in den letzten zwölf Monaten Mails gesendet haben. DMARC-Reports als Beleg heranziehen.
3. Nicht mehr genutzte includes entfernen, ptr und überflüssige mx- oder a-Mechanismen streichen.
4. Eigene Server per ip4 oder ip6 eintragen.
5. Massenversender auf Subdomains mit eigenem SPF-Record umziehen.
6. Neuen Record veröffentlichen, TTL kurz halten und nach einigen Tagen die DMARC-Reports prüfen.

Häufige Fragen

Zählt ein include, wenn es nie erreicht wird?

Ja. Empfänger werten den Record zwar von links nach rechts aus und stoppen beim ersten Treffer, aber das Limit bezieht sich auf die Abfragen, die bis dahin nötig waren. Bei einer Spoofing-Mail, die auf keinen Mechanismus passt, werden alle Mechanismen ausgewertet. Deshalb musst du mit dem gesamten Baum rechnen.

Warum zeigt mein Tool neun Lookups, ein anderes elf?

Die Records der Anbieter ändern sich, und manche Tools zählen mx oder void lookups anders. Maßgeblich ist die Zählung nach RFC 7208. Wenn du an der Grenze liegst, solltest du auf jeden Fall Reserve einplanen, weil ein Anbieter jederzeit ein include ergänzen kann.

Kann ich das Limit auf mehr als zehn erhöhen?

Nein. Das Limit wird vom Empfänger durchgesetzt, nicht von dir. Es gibt keinen Modifier, mit dem du es anheben könntest.