SPF-Abfragelimit: das Problem mit DNS-Referenzen lösen

Das SPF-Abfragelimit ist einfach erklärt: Benötigt die Auswertung Ihrer SPF-Richtlinie mehr als 10 DNS-auslösende SPF-Terme, können Empfänger die Verarbeitung abbrechen und einen dauerhaften Fehler zurückgeben. Eine im DNS-Panel unauffällige Konfiguration kann also im Betrieb an der Authentifizierung scheitern. Wenn Sie Ihre Domain-E-Mail ohnehin aufräumen, beginnen Sie mit geschäftlicher E-Mail für kleine Unternehmen und beheben Sie anschließend hier den Teil, der häufig erst später Probleme verursacht.

Das passiert vielen Teams. Erst kommt Google Workspace, dann Microsoft 365, dann Mailchimp, ein CRM und ein Helpdesk. Jeder Anbieter sagt: „Fügen Sie einfach unser include hinzu.“ Ein paar Monate später ist der SPF-Eintrag syntaktisch gültig, im Betrieb aber fehleranfällig. Nachrichten landen im Spam oder werden abgewiesen. Die Ursache bleibt unklar, weil der Eintrag auf den ersten Blick normal aussieht.

Die gute Nachricht: Meist hilft schlichtes Aufräumen. Entfernen Sie nicht mehr benötigte Einträge. Verwenden Sie `mx` nur, wenn es tatsächlich erforderlich ist. Verlagern Sie Marketing-E-Mails auf eine Subdomain. Halten Sie die Hauptdomain übersichtlich.

Was ist das SPF-Abfragelimit?

Das SPF-Abfragelimit ist die im RFC festgelegte Obergrenze für SPF-Terme, die bei der Auswertung DNS-Abfragen auslösen. Empfänger dürfen im gesamten SPF-Baum höchstens 10 solcher Terme auf dem tatsächlich ausgewerteten Pfad verarbeiten, einschließlich verschachtelter `include`-Ketten. Überschreitet Ihre Richtlinie diese Grenze, kann SPF `permerror` zurückgeben. Damit fehlt der Nachricht ein wichtiges Authentifizierungssignal.

RFC 7208 legt diese Regel fest. Sie soll verhindern, dass SPF übermäßig viele DNS-Abfragen auslöst und zur DNS-Verstärkung missbraucht wird. Es handelt sich nicht um eine optionale Empfehlung, sondern um eine Protokollgrenze.

Häufig übersehen wird, dass das SPF-Abfragelimit kumulativ gilt. Es stehen nicht 10 Abfragen im Haupteintrag und weitere 10 in jedem include zur Verfügung. Für den gesamten Auswertungspfad gilt ein gemeinsames Budget.

Warum das SPF-Abfragelimit scheinbar funktionierende Einträge scheitern lässt

Das SPF-Abfragelimit betrifft auch übersichtlich aussehende Einträge. SPF bewertet nicht das Erscheinungsbild des TXT-Haupteintrags, sondern die DNS-auslösenden Terme, die der Empfänger auf dem tatsächlichen Auswertungspfad verarbeitet. Die Tabellenwerte sind eine vereinfachte Darstellung, keine Zählung einzelner DNS-Pakete.

Ein Beispiel:

Sie veröffentlichen `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` und rechnen mit drei Abfragen. Tatsächlich können Googles und Microsofts Einträge jeweils weitere Abfragen nach sich ziehen. Der sichtbare Eintrag ist kurz, seine vollständige Auswertung nicht unbedingt.

Deshalb wird das SPF-Abfragelimit oft erst später zum Problem. Ändern Anbieter ihre eigenen SPF-Bäume, kann Ihr Abfragebedarf steigen, ohne dass Sie Ihre DNS-Konfiguration anfassen.

Eine weitere Falle sind leere Abfragen, sogenannte Void Lookups. RFC 7208 empfiehlt Implementierungen, sie auf zwei zu begrenzen. Dabei liefert die DNS-Abfrage keine Antwortdaten oder `NXDOMAIN`. Ein einzelner Tippfehler in einem include führt nicht zwangsläufig zum Ausfall. Zwei ungültige Verweise können jedoch problematisch werden. Dann entsteht neben dem SPF-Abfragelimit ein `permerror`-Risiko, obwohl Sie noch unter 10 liegen.

Auch Googles dokumentierte Absendervorgaben verdeutlichen die Folgen: Fehlende oder fehlerhafte Authentifizierung kann bei Massenversendern zur Spam-Einstufung oder Ablehnung führen. Google verlangt für diese Absender SPF, DKIM und DMARC; Nachrichten, die die Absendervorgaben nicht erfüllen, können abgewiesen oder in Spam einsortiert werden. Siehe Googles FAQ zu den Absendervorgaben.

So berechnen Sie den Verbrauch des SPF-Abfragebudgets

Um das SPF-Abfragelimit zu prüfen, beginnen Sie beim SPF-Haupteintrag und zählen alle DNS-auslösenden Mechanismen entlang der tatsächlich ausgewerteten Pfade im rekursiven Baum. Dazu gehören Ihre eigenen Terme ebenso wie die darunterliegenden Verweise Ihrer Anbieter. Liegt die Summe auf einem Auswertungspfad über 10, kann die Prüfung im Betrieb scheitern.

Beginnen Sie beim Haupteintrag:

dig +short txt example.com

Beispielausgabe:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Prüfen Sie anschließend jede referenzierte Domain:

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

Verfolgen Sie die Ketten, bis nur noch `ip4`, `ip6` oder abschließende Richtlinienterme übrig bleiben.

Gehen Sie beim Zählen so vor:

1. Zählen Sie jedes tatsächlich ausgewertete include, a, mx, ptr, exists und redirect.
2. Zählen Sie auch tatsächlich ausgewertete verschachtelte Terme in eingebundenen Einträgen.
3. Zählen Sie ip4, ip6 und all nicht mit.
4. Markieren Sie include-Ziele, die keine Daten zurückgeben. Sie können zu Problemen mit leeren Abfragen führen.

Für eine kurze DNS-Plausibilitätsprüfung beim Einrichten einer Domain in TrekMail eignen sich die Dokumentationen zur Prüfung des DNS-Status und zu den erforderlichen DNS-Einträgen.

Häufige Fehler beim SPF-Abfragelimit

Probleme mit dem SPF-Abfragelimit gehen meist auf dieselben Ursachen zurück: zu viele Anbieter auf einer Hauptdomain, alte Provider im Eintrag, `mx` als Abkürzung und manuelles Flattening ohne Wartungsprozess. Das sind keine exotischen Sonderfälle, sondern Folgen einer unzureichend gepflegten DNS-Konfiguration.

Besonders häufig sind diese Fehler:

Teams verwechseln dabei oft sichtbare und tatsächliche Komplexität. Ein einzelnes Anbieter-include kann nach seiner Auflösung mehrere Abfragen beanspruchen. Deshalb ist „nur noch ein weiterer Absender“ beim SPF-Abfragelimit keine verlässliche Planung.

Auch die Entscheidung zwischen Weiterleitung, Alias und eigenem Postfach hängt stärker mit der Absenderkonfiguration zusammen, als häufig angenommen wird. Weiterführend: Domain-E-Mail-Alias oder Postfach und Weiterleitung mit E-Mail-Alias.

Das SPF-Abfragelimit beheben, ohne den Versand unnötig zu gefährden

Der risikoärmere Weg beim SPF-Abfragelimit ist weniger SPF-Komplexität statt weiterer Behelfslösungen. Entfernen Sie zunächst ungenutzte Absender. Verlagern Sie danach versandintensive Systeme auf Subdomains. Flattening ist nur sinnvoll, wenn Sie automatische Aktualisierungen sicherstellen können.

1. Überflüssiges entfernen.

Löschen Sie nicht mehr genutzte Anbieter. Entfernen Sie `ptr`. Ersetzen Sie `mx` durch die tatsächlich benötigte Absenderfreigabe. Häufig bringt schon ein gründliches Aufräumen fehlerhafte Richtlinien wieder unter das SPF-Abfragelimit.

2. Versand nach Subdomains aufteilen.

Für wachsende Teams ist das oft der praktikabelste Ansatz.

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

Jede Subdomain hat eine eigene SPF-Richtlinie mit eigenem Abfragebudget. Das kann die Hauptdomain entlasten und die Verwaltung des SPF-Abfragelimits erheblich erleichtern.

3. Flattening nur als letzte Option.

Beim Flattening werden includes durch direkte IP-Bereiche ersetzt:

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

Dadurch sinkt der Abfragebedarf auf nahezu null, doch es entsteht Wartungsaufwand. Anbieter ändern IP-Adressen; ein veralteter Eintrag kann dann den Versand beeinträchtigen. Automatisieren Sie die Pflege, wenn Sie Flattening einsetzen.

Alter und neuer Ansatz: das SPF-Abfragelimit mit TrekMail verwalten

Beim alten Umgang mit dem SPF-Abfragelimit sammeln sich Postfachanbieter, Marketingplattformen und Relays auf einer Hauptdomain, bis die DNS-Konfiguration nur noch schwer nachvollziehbar ist. Der neue Ansatz reduziert Abhängigkeiten und trennt die Rollen der Absender von Anfang an.

Alter Ansatz: ein überladener SPF-Haupteintrag, verbliebene Altanbieter, Marketing- und Postfachverkehr im selben Versandstrom sowie unklare Zuständigkeiten für Absenderfreigaben.

Neuer Ansatz: übersichtliches Postfachhosting, isolierte Massenversender auf Subdomains und eine kurze SPF-Richtlinie für die Hauptdomain mit ausreichendem Spielraum.

Hier kann TrekMail helfen. Wenn Sie den verwalteten Versand in einem kostenpflichtigen Tarif nutzen, sehen die beschriebenen DNS-Einstellungen `include:spf.trekmail.net` als Teil des SPF-Eintrags vor. Dieses include zählt als eine Abfrage; prüfen Sie zusätzlich mögliche Unterverweise. Das beschriebene Angebot beginnt bei $3.50 pro Monat und umfasst eigene Domains, IMAP-Postfächer, Catch-all, Postfachweiterleitung, ein integriertes Migrationstool und API-Zugriff. Für kostenpflichtige Tarife wird eine 14-tägige Testphase mit erforderlicher Kreditkarte beschrieben. Nano wird als dauerhaft kostenloser Tarif ohne Testphase mit BYO SMTP angeboten. Prüfen Sie die aktuellen Konditionen vor der Einrichtung.

Im Nano-Tarif kann TrekMail die Postfächer bereitstellen, während SES, Mailgun oder ein anderes Relay den Versand übernimmt. Trennen Sie die Versandströme sorgfältig über Subdomains, damit die Hauptrichtlinie das SPF-Abfragelimit nicht überschreitet. Die TrekMail-Dokumentationen zu eigenem SMTP (BYO), verwaltetem TrekMail-SMTP und zum Start einer Migration im Dashboard erläutern die Einrichtung.

Bei der Zusammenführung von Domains helfen außerdem E-Mail-Hosting für mehrere Domains und E-Mail auf der eigenen Domain einrichten.

Fazit: unter dem SPF-Abfragelimit bleiben

Um unter dem SPF-Abfragelimit zu bleiben, halten Sie SPF möglichst schlicht. Nutzen Sie auf der Hauptdomain nur die benötigten Absender. Verlagern Sie Massen- und Anwendungsversand auf Subdomains. Prüfen Sie Anbieter-includes erneut, sobald ein neues Tool hinzukommt. Liegt die Richtlinie nahe bei 10, planen Sie bereits eine Entlastung ein.

Das SPF-Abfragelimit ist kein theoretischer RFC-Randfall, sondern eine feste betriebliche Grenze. Mit jedem zusätzlichen Anbieter wird seine Einhaltung anspruchsvoller. Halten Sie den Eintrag kurz und die DNS-Zuständigkeiten eindeutig. Fünf Anbieter auf einem gemeinsamen Authentifizierungspfad können sonst dazu führen, dass Sie noch um 2 Uhr nachts Mailheader untersuchen.

Für eine übersichtlichere Konfiguration beschreibt TrekMail E-Mail-Hosting für mehrere Domains zum Pauschalpreis ohne Gebühren pro Nutzer, gemeinsamen Speicher, integrierte IMAP-Migration und die Wahl zwischen BYO SMTP und verwaltetem TrekMail-SMTP. Prüfen Sie die aktuellen Leistungen und Konditionen unter TrekMail-Preise oder direkt bei TrekMail.