SPF-Abfragelimit: Ursachen prüfen und Versand trennen

Das SPF-Abfragelimit ist ein DNS-Thema, das zunächst harmlos wirkt. Ein weiterer Absender, ein zusätzliches CRM, noch ein Helpdesk: Schon kann eine gewöhnliche Nachricht beanstandet, verzögert oder abgewiesen werden, weil die SPF-Auswertung eine feste Protokollgrenze überschreitet.

Für den größeren Zusammenhang zwischen SPF und Ihrer Einrichtung beginnen Sie mit geschäftlicher E-Mail. SPF ist keine bloße Markeneinstellung, sondern ein Teil der Authentifizierung, die Empfänger in ihre Bewertung einbeziehen.

Dieser Leitfaden erklärt das SPF-Abfragelimit, welche Terme zählen, warum Flattening zusätzliche Verantwortung erzeugt und wie Sie eine längerfristig wartbare Konfiguration entwickeln.

Was ist das SPF-Abfragelimit?

Das SPF-Abfragelimit begrenzt die bei einer SPF-Auswertung berücksichtigten Mechanismen und Modifikatoren, die DNS-Abfragen erfordern. Nach RFC 7208 liegt diese Grenze bei 10; eine Überschreitung führt zu permerror statt zu einem erfolgreichen Ergebnis.

Kurz gesagt hat SPF ein Budget. Werden mehr als 10 DNS-abfragende Terme ausgewertet, muss die Implementierung die Auswertung mit einem permanenten Fehler beenden. Das ist keine Besonderheit von Gmail, sondern eine Vorgabe des SPF-Standards.

RFC 7208 nennt die budgetrelevanten Terme ausdrücklich: include, a, mx, ptr, exists und redirect. ip4, ip6 und all benötigen während ihrer Auswertung keine solchen Abfragen.

Diese Unterscheidung ist wichtig, weil oft nur die Länge des Eintrags betrachtet wird. Ein kurzer SPF-Eintrag kann scheitern, ein längerer erfolgreich sein. Entscheidend ist der Aufwand des tatsächlich ausgewerteten Pfads.

Was zählt zum SPF-Abfragelimit?

Beim SPF-Abfragelimit zählen DNS-abfragende Mechanismen und Modifikatoren, nicht einfach Wörter im TXT-Eintrag. Verschachtelte Includes zählen mit. Deshalb zeigt die eigene DNS-Oberfläche oft weniger relevante Terme, als der Empfänger insgesamt auswerten muss.

Diese Terme belasten das Budget:

1. include: wertet den SPF-Eintrag einer anderen Domain aus; ein pass dort kann den Include-Mechanismus erfüllen.
2. a: löst einen Hostnamen zu IP-Adressen auf und vergleicht diese mit der Verbindungs-IP.
3. mx: löst MX-Einträge und anschließend deren Adressen auf.
4. ptr: prüft rückwärts aufgelöste Namen; seine Nutzung wird nicht empfohlen.
5. exists: prüft, ob die vorgeschriebene A-Abfrage für eine Domain ein Ergebnis liefert.
6. redirect: übergibt die Auswertung an eine andere SPF-Richtlinie, wenn kein Mechanismus passt.

Diese Terme beanspruchen bei ihrer SPF-Auswertung kein Abfragebudget:

• ip4
• ip6
• all

Die Falle liegt in der Rekursion. Enthält Ihr Eintrag Microsoft und dessen SPF wiederum weitere Einträge, werden die relevanten nachgelagerten Terme mitgezählt. Die SPF-Struktur der Anbieter wird damit Teil Ihrer eigenen Abhängigkeiten.

Sie meinen, 6 Absender ergänzt zu haben. Durch Verschachtelung kann der Empfänger jedoch 11 oder 12 relevante Terme auswerten müssen. So überschreiten Teams das SPF-Abfragelimit, obwohl sie sich noch unter 10 wähnen.

Warum wachsende Teams das Limit überschreiten

Probleme mit dem SPF-Abfragelimit treten häufig nach dem Hinzufügen von Werkzeugen auf, nicht nur nach einem Hosterwechsel. Marketingplattformen, Supportsysteme, Recruiting-Apps, CRMs und Transaktionsversender verlangen jeweils ein include im SPF der verwendeten Envelope-Domain, die oft die Hauptdomain ist.

Anfangs ist der Eintrag einfach. Die folgenden Anbieterwerte sind illustrative Beispiele; prüfen Sie aktuelle Vorgaben, bevor Sie sie übernehmen:

v=spf1 include:_spf.google.com ~all

Dann wächst die Werkzeuglandschaft:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

Sie verwalten nun nicht nur eine Absenderrichtlinie, sondern eine Abhängigkeitskette, die sich außerhalb Ihrer direkten Kontrolle ändern kann.

Deshalb wirkt das SPF-Abfragelimit im Betrieb manchmal zufällig. Ihr DNS blieb unverändert, aber ein Anbieter hat seine interne SPF-Struktur angepasst. Eine Nachricht, die gestern erfolgreich geprüft wurde, kann heute permerror erhalten.

Wenn das Zustellproblem über SPF hinausgeht, hilft TrekMails Anleitung warum E-Mails im Spam landen bei weiteren Prüfungen. Authentifizierung und Reputation können gleichzeitig problematisch sein.

Was passiert beim Überschreiten des Limits?

Wird das SPF-Abfragelimit überschritten, liefert die Auswertung permerror. Empfänger behandeln solche Nachrichten nicht zwangsläufig identisch, erhalten aber keinen sauberen SPF-Erfolg, sondern ein fehlerhaftes Authentifizierungssignal.

Das wird im Betrieb leicht unterschätzt. Ein fast eingehaltenes Budget wird nicht als Teilerfolg gewertet.

Googles Absendervorgaben beziehen korrekte Authentifizierung und Alignment ein. Wer umfangreich an Gmail sendet, sollte SPF und DKIM anhand der jeweils anwendbaren Anforderungen überwachen. Eine erfolgreiche Prüfung garantiert keine Posteingangsplatzierung. Siehe Googles Absenderrichtlinien.

Daneben sind zwei verwandte Grenzen wichtig:

1. Leere Abfrageergebnisse, sogenannte void lookups. RFC 7208 empfiehlt Implementierungen, diese auf zwei zu begrenzen. Ein Tippfehler in einem include oder eine nicht mehr existierende Anbieterdomain kann zu permerror beitragen.
2. DNS-Antwortgröße. Große Antworten können abgeschnitten werden und einen Transportwechsel erfordern. Bei fehlerhaften Netzwerken sind temporäre Fehler oder Zeitüberschreitungen möglich.

Warum SPF-Flattening nicht immer die passende Lösung ist

Das SPF-Abfragelimit macht Flattening attraktiv: Includes werden durch direkte IP-Angaben ersetzt und beanspruchen dann kein entsprechendes Abfragebudget. Damit entsteht aber eine neue Pflegeaufgabe.

Manuelles Flattening sieht beispielsweise so aus:

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

Für die SPF-Auswertung ist das günstig. Anbieter ändern jedoch Infrastruktur, ergänzen Adressbereiche oder wechseln Dienstleister. Ist der abgeflachte Eintrag veraltet, kann legitime Mail nicht mehr autorisiert sein; entfernte Bereiche können umgekehrt zu lange erlaubt bleiben.

Ein wenig wartbarer Ansatz besteht darin, alle Anbieter im Hauptdomain-SPF zu sammeln und den Eintrag bei jedem Engpass erneut manuell abzuflachen.

Ein strukturierterer Ansatz verteilt Versandfunktionen auf passende Subdomains, hält Richtlinien begrenzt und nutzt ausgerichtetes DKIM. Das setzt tatsächliche separate Envelope-Domains voraus, nicht nur unterschiedliche sichtbare From-Adressen. Dadurch werden Zuständigkeiten klarer; eine vollständige Trennung der Reputation ist nicht garantiert.

Bei TrekMail kann diese Architektur je nach Tarif leichter zu verwalten sein. Nach aktueller Dokumentation gibt es eigene Domains, IMAP-Postfächer, Catch-all, Migrationswerkzeuge, Weiterleitung und BYO SMTP oder verwaltetes SMTP. Ob BYO SMTP im kostenlosen Plan und verwaltetes SMTP in bezahlten Plänen enthalten sind, ist anhand der aktuellen Bedingungen zu prüfen. Funktionen und Abrechnung unterscheiden sich nach Plan. DNS erklärt die Anleitung erforderliche DNS-Einträge, Versandoptionen die Dokumentation eigenes SMTP (BYO).

Eine nachhaltige Lösung für das SPF-Abfragelimit

Eine sinnvolle langfristige Strategie gegen das SPF-Abfragelimit ist Segmentierung. Unternehmenspost, Marketing, Support und Transaktionsmail können getrennte Envelope-Subdomains nutzen, damit ihre SPF-Auswertung eigene Budgets erhält. Prüfen Sie dabei DMARC-Alignment: relaxed kann passende organisatorische Domains berücksichtigen, strict verlangt genaue Domainübereinstimmung. Reputationswirkungen müssen dennoch überwacht werden.

Ein mögliches Modell:

1. Hauptdomain für persönliche Geschäftspost, etwa alice@company.com.
2. Marketing-Subdomain, etwa newsletter.company.com.
3. Support-Subdomain, etwa support.company.com.
4. Transaktions-Subdomain, etwa updates.company.com.

Beispielhafte Einträge:

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

Jede tatsächlich separat ausgewertete Envelope-Domain erhält ihr eigenes Budget von 10 relevanten Termen. So kann das gemeinsame SPF-Abfragelimit als Fehlerquelle reduziert werden. Jeder einzelne Eintrag muss weiterhin geprüft werden.

Die Trennung erleichtert außerdem die Reputationsanalyse. Schlechte Marketingpraktiken können trotzdem andere Ströme beeinflussen, etwa über gemeinsame IPs oder übergeordnete Domainbewertungen; eine Reputations-Firewall entsteht nicht automatisch.

Für neue Domains helfen TrekMails Anleitung Domain hinzufügen und DNS-Prüfung. Beim Wechsel von alten Anbietern kann die integrierte IMAP-Funktion aus der IMAP-Migrationsübersicht Mailboxdaten kopieren. DNS, Anwendungseinstellungen und Versandpfade werden nicht automatisch mitgenommen; ein unterbrechungsfreier Wechsel ist nicht garantiert.

Das SPF-Abfragebudget prüfen

Das SPF-Abfragelimit sollten Sie messen statt schätzen. Lesen Sie zuerst den SPF-TXT-Eintrag und verfolgen Sie Includes und verschachtelte Einträge, bis der Aufwand der möglichen Auswertungspfade bekannt ist.

Beginnen Sie mit dig:

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

Zählen Sie anschließend alle relevanten DNS-abfragenden Terme im ausgewerteten Pfad, auch in eingebundenen Einträgen. Die Auswertung kann bei einem Treffer enden; deshalb sind die tatsächlich genutzten Versand-IPs mitzuprüfen.

Ein praktischer Ablauf:

1. SPF-TXT der tatsächlichen Envelope-Domain oder Subdomain abrufen.
2. Alle include, a, mx, exists und redirect erfassen; auch verwendete veraltete PTR-Mechanismen berücksichtigen.
3. Verschachtelte SPF-Einträge auflösen und die Untersuchung fortsetzen.
4. Werkzeuge entfernen, die nachweislich keine Mail mehr senden.
5. Geeignete Versandströme auf echte Envelope-Subdomains verteilen, bevor manuelles Flattening erwogen wird.

Achten Sie auch auf mehrere SPF-Einträge für denselben Host. TrekMail empfiehlt, autorisierte Quellen in einem SPF-TXT-Eintrag zusammenzuführen, statt mehrere SPF-Einträge zu veröffentlichen. Ein einzelner TXT-Eintrag kann technisch mehrere Zeichenketten enthalten. Zur weiteren Untersuchung helfen E-Mail mit einer Domain erstellen, Multi-Domain-E-Mail-Hosting und imapsync.

TrekMail als Teil einer übersichtlicheren Konfiguration

TrekMail hebt das SPF-Abfragelimit nicht auf. Ein Hostingdienst kann eine Protokollgrenze nicht beseitigen. Er kann aber je nach Funktionsumfang eine Architektur erleichtern, die mit dieser Grenze arbeitet.

Das ist für zwei Gruppen relevant.

Einzelgründer und kleine Teams können persönliche Post auf einer einfachen Hauptdomain-Richtlinie halten und BYO SMTP oder verwaltetes SMTP nach Bedarf einsetzen. Agenturen und MSPs können Kundenströme trennen und Domains zentral einrichten. Ob dabei Kosten oder Verwaltungsaufwand sinken, hängt vom Tarif und der Nutzung ab.

Traditioneller und strukturierter Ansatz:

Traditionell: Geschäftspost, Aliase, Apps und Marketing werden aus Kostengründen im selben Dienst und SPF-Eintrag gebündelt.

Strukturiert: Eine Multi-Domain-Plattform bündelt IMAP-Postfächer, während tatsächliche Envelope-Subdomains die Versandströme trennen und SPF auch nach Anbieteränderungen geprüft wird.

Nach den hier genannten Bedingungen beginnt Starter bei $3.50 pro Monat. Der kostenlose Plan wird mit $0, 10 Domains, 5GB gemeinsamem Speicher und BYO SMTP beschrieben. Bezahlte Pläne können verwaltetes SMTP, höhere Grenzen und zusätzliche Automatisierung bieten. Prüfen Sie die aktuellen Bedingungen und rechnen Sie Ihre Architektur auf der Seite TrekMail-Preise durch.

Fazit: Das SPF-Abfragelimit als Konstruktionsgrenze behandeln

Das SPF-Abfragelimit ist keine seltene Ausnahme, sondern eine feste Vorgabe des Protokolls. Wächst Ihre Werkzeuglandschaft, sollten Sie den Auswertungsaufwand regelmäßig prüfen und nicht erst bei einer Überschreitung reagieren.

Warten Sie nicht auf permerror. Erfassen Sie Absender, entfernen Sie nicht mehr benötigte Includes und trennen Sie geeignete Ströme über passende Envelope-Subdomains. Halten Sie die Hauptdomain möglichst übersichtlich. Das reduziert Risiken für wichtige Geschäftspost, ohne Zustellung zu garantieren.

Für diese Architektur über eine oder viele Domains bietet TrekMail nach aktuellen Plänen eigene Domains, IMAP-Postfächer, gemeinsamen Speicher, Migration und verschiedene SMTP-Optionen. Kosten und Grenzen sind tarifabhängig. Prüfen Sie den kostenlosen Einstieg bei trekmail.net oder vergleichen Sie Pläne bei trekmail.net/pricing.