SPF-Record optimieren: Fehler beheben und unter dem 10-Lookup-Limit bleiben

Ein vorhandener SPF-Record ist nicht gleichbedeutend mit einem funktionierenden SPF-Record. Viele Organisationen richten SPF einmalig ein – und merken erst durch sinkende Zustellraten oder DMARC-Fehlerberichte, dass der Record längst veraltet, überladen oder falsch konfiguriert ist. Dieser Leitfaden zeigt Ihnen, wie Sie Ihren SPF-Record systematisch optimieren: vom 10-Lookup-Limit bis zum Alignment mit DMARC.

Warum SPF-Optimierung wichtig ist – SPF-Fehler = DMARC-Fehler

SPF und DMARC sind eng miteinander verzahnt. Wenn SPF für eine Nachricht fehlschlägt – sei es durch ein permerror, ein fail oder ein Alignment-Problem – kann DMARC seine SPF-Komponente nicht als bestanden werten. Das bedeutet: Selbst wenn DKIM korrekt konfiguriert ist, trägt SPF nichts zur DMARC-Pass-Rate bei.

Für Organisationen mit vielen sendenden Diensten ist ein defekter SPF-Record oft der Hauptgrund dafür, dass DMARC-Reports hohe Fehlerquoten zeigen. Die gute Nachricht: Die meisten SPF-Probleme lassen sich mit gezielten Maßnahmen dauerhaft beheben.

Unter dem 10-DNS-Lookup-Limit bleiben

RFC 7208 schreibt vor, dass die Auswertung eines SPF-Records maximal 10 DNS-Lookups auslösen darf. Mechanismen, die einen Lookup verursachen, sind:

• include – jede eingebundene Drittdomain zählt als ein Lookup, plus alle verschachtelten Includes innerhalb dieser Domain
• a – löst einen A- oder AAAA-Record-Lookup auf
• mx – löst MX-Records auf (jeder MX-Eintrag kann wiederum Lookups auslösen)
• ptr – sehr teuer, veraltet und von der Nutzung abgeraten
• exists – löst einen A-Record-Lookup aus

IP-basierte Mechanismen wie ip4 und ip6 verursachen dagegen keine Lookups. Wenn das 10-Lookup-Limit überschritten wird, gibt der auswertende Mailserver ein permerror zurück. Ein permerror gilt für DMARC wie ein SPF-Fehler – die Nachricht kann die DMARC-Richtlinie nicht über SPF erfüllen.

Ein typischer SPF-Record, der das Limit leicht überschreiten kann:

v=spf1 include:_spf.google.com include:amazonses.com include:servers.mcsv.net include:_spf.salesforce.com include:mail.zendesk.com include:spf.protection.outlook.com ip4:203.0.113.5 ~all

Jedes include löst einen Lookup aus – und jede dieser Domains hat ihrerseits verschachtelte Includes. Sechs include-Mechanismen können schnell 12 oder mehr tatsächliche Lookups erzeugen.

SPF-Record flattenen

SPF-Flattening bezeichnet das Ersetzen von include-Mechanismen durch die konkreten IP-Adressen, auf die sie letztlich zeigen. Statt include:_spf.google.com enthält der Record dann direkt die IP-Ranges von Google – zum Beispiel ip4:35.190.247.0/24 und weitere.

Der Vorteil: Die Anzahl der DNS-Lookups sinkt drastisch, da ip4- und ip6-Einträge keine Lookups auslösen. Der Trade-off: IP-Ranges von ESPs ändern sich. Ein manuell geflatteneter Record kann schnell wieder veralten, wenn ein Anbieter neue IPs hinzufügt – und dann schlagen legitime E-Mails an SPF.

Alternativen zum manuellen Flattening:

• Verwaltete SPF-Dienste (z. B. dmarcian SPF Surveyor, AutoSPF, Valimail) pflegen geflattenete Records automatisch und aktualisieren sie bei Änderungen der Anbieter-IPs.
• Makro-basierte SPF-Records sind eine fortgeschrittene Technik, die das Lookup-Limit durch dynamische Auflösung umgeht – erfordert jedoch Unterstützung durch den DNS-Anbieter.

Ungenutzte Includes entfernen

Mit der Zeit häufen sich in SPF-Records Einträge für E-Mail-Dienste, die längst nicht mehr genutzt werden: ein alter Marketing-Anbieter, eine abgekündigte Transaktionsmail-Plattform, ein CRM, das vor zwei Jahren abgelöst wurde. Jeder dieser Einträge verbraucht wertvolle Lookup-Kapazität.

So prüfen Sie, welche Includes noch benötigt werden:

1. Exportieren Sie die Quelldaten aus Ihren DMARC-Aggregate-Reports – welche sendenden IPs tauchen tatsächlich auf?
2. Gleichen Sie diese IPs mit den IP-Ranges ab, die jeder include-Mechanismus abdeckt.
3. Einträge, denen keine aktive sendende IP gegenübersteht, können sicher entfernt werden.
4. Entfernen Sie einen Eintrag zunächst probeweise in einer Testumgebung oder beobachten Sie nach der Änderung einige Tage lang die DMARC-Reports, bevor Sie weitere Bereinigungen vornehmen.

DMARCFlow zeigt in der sendenden-Quellen-Übersicht genau, welche IP-Adressen E-Mails im Namen Ihrer Domain versenden – das macht die Analyse erheblich einfacher als das manuelle Auswerten von XML-Reports.

Alignment-Probleme beheben

Ein häufiges Missverständnis: SPF pass bedeutet nicht DMARC pass. Für DMARC muss nicht nur SPF bestehen – die durch SPF authentifizierte Domain muss auch mit der sichtbaren Header-From-Adresse alignieren.

SPF arbeitet auf der MAIL FROM-Adresse (auch Envelope-From oder Return-Path genannt) – das ist die Adresse, die beim SMTP-Verbindungsaufbau übertragen wird und die Empfänger im E-Mail-Client in der Regel nicht sehen. Viele E-Mail-Dienstleister (ESPs) verwenden für den MAIL FROM ihre eigene Domain, nicht Ihre:

Die Lösung für Alignment-Probleme: Konfigurieren Sie beim ESP einen Custom Return-Path (auch benutzerdefinierte Bounce-Domain genannt), der Ihrer eigenen Domain zugeordnet ist – zum Beispiel bounce.ihredomain.de. Dieser CNAME-Eintrag in Ihrem DNS verweist auf die Bounce-Infrastruktur des ESPs, aber die MAIL FROM-Domain lautet ihredomain.de – und damit ist SPF-Alignment mit Ihrem Header-From erfüllt.

Die meisten großen ESPs unterstützen diese Konfiguration. Im Zweifel hilft ein Blick in die Dokumentation des Anbieters unter den Stichworten „custom return path", „custom bounce domain" oder „branded sending domain".

-all statt ~all verwenden

~all (Softfail) ist für die Einrichtungsphase gedacht – es signalisiert empfangenden Mailservern, dass nicht autorisierte Absender wahrscheinlich keine Berechtigung haben, ohne sofort eine harte Ablehnung zu erzwingen. Das gibt Spielraum, den Record zu vervollständigen, ohne legitime E-Mails zu blockieren.

Sobald Sie sicher sind, dass alle legitimen sendenden Dienste im SPF-Record erfasst sind und Ihre DMARC-Reports keine unerwarteten SPF-Fehler mehr für eigene Quellen zeigen, sollten Sie zu -all (Fail) wechseln. Der Unterschied:

• ~all – nicht autorisierte Absender erhalten ein Softfail. Viele Mailserver stellen solche Nachrichten trotzdem zu, oft mit einem Spam-Score-Abzug.
• -all – nicht autorisierte Absender erhalten ein Hard-Fail. Empfangssysteme, die SPF hart durchsetzen, lehnen diese Nachrichten ab.

Wann der Wechsel sicher ist:

1. Ihre DMARC-Reports zeigen seit mindestens zwei Wochen keine unerwarteten SPF-Fehler für legitime Quellen mehr.
2. Sie haben alle aktiven ESPs, transaktionalen Mailsysteme und internen Mailserver im SPF-Record erfasst.
3. Die DMARC-Richtlinie ist mindestens auf quarantine gesetzt – bei none hat -all praktisch keine zusätzliche Schutzwirkung.

Wie DMARCFlow hilft

SPF-Optimierung erfordert Einblick in das, was tatsächlich in Ihren E-Mail-Strömen passiert. Ohne DMARC-Reporting-Daten ist es schwierig zu wissen, welche Quellen wirklich aktiv sind, ob Alignment stimmt und ob permerror-Fälle auftreten.

DMARCFlow unterstützt die SPF-Optimierung konkret auf mehreren Ebenen:

• permerror-Erkennung. DMARCFlow erkennt permerror-Ergebnisse in DMARC-Reports und kennzeichnet betroffene Datensätze. So sehen Sie sofort, ob das 10-Lookup-Limit in der Praxis überschritten wird – nicht nur theoretisch.
• Alignment-Insight je Datensatz. Jeder Datensatz in jedem DMARC-Aggregate-Report wird einzeln auf SPF-Alignment analysiert. DMARCFlow unterscheidet fünf Szenarien: alignierter MAIL FROM-Pass, nicht-alignierter MAIL FROM-Pass, nur HELO-Pass, kein SPF-Pass und keine relevanten SPF-Ergebnisse – und macht damit sichtbar, welche ESPs Alignment-Probleme verursachen.
• Sendende-Quellen-Übersicht. Die Zusammenfassung aller sendenden IP-Adressen und Domains hilft dabei, ungenutzte include-Mechanismen zu identifizieren und den Record gezielt zu bereinigen.
• Empfehlungs-Engine. Basierend auf Ihren tatsächlichen Report-Daten generiert DMARCFlow priorisierte Handlungsempfehlungen – inklusive konkreter Hinweise, wenn ein ESP einen Custom Return-Path benötigt oder wenn das Lookup-Limit kritisch nahe ist.
• Security Score und Maturity Level. SPF-Alignment ist ein direkter Faktor im Security Score und im DMARC-Reifegrad. DMARCFlow zeigt transparent, wie sich SPF-Optimierungen auf beide Kennzahlen auswirken.

Fazit

Ein SPF-Record, der einmal funktioniert hat, ist keine Garantie dafür, dass er heute noch korrekt arbeitet. ESPs ändern ihre IP-Ranges, neue Dienste kommen hinzu, alte bleiben im Record stehen – und schleichend nähert sich der Record dem 10-Lookup-Limit oder verliert das Alignment mit DMARC.

Die vier wichtigsten Optimierungsmaßnahmen zusammengefasst: Lookups reduzieren (durch Flattening oder Entfernen ungenutzter Includes), Alignment sicherstellen (durch Custom Return-Path beim ESP), auf -all wechseln (sobald alle legitimen Quellen erfasst sind) und die Ergebnisse regelmäßig mit DMARC-Report-Daten abgleichen.

DMARCFlow gibt Ihnen die nötigen Daten, um all das nicht blind, sondern datengetrieben zu tun. Statt zu raten, welche Includes aktiv sind oder ob Alignment stimmt, sehen Sie es direkt in Ihren Reports – und erhalten konkrete Empfehlungen, was als nächstes zu tun ist.