Zu viele SPF-Referenzen: PermError erkennen und beheben

Zu viele DNS-Referenzen in SPF wirken zunächst wie ein kleines Problem. Sobald Nachrichten scheitern, können die Folgen jedoch erheblich sein. Überschreitet Ihre Domain das SPF-Abfragelimit, können Empfänger PermError zurückgeben und den SPF-Eintrag nicht mehr erfolgreich auswerten. Rechnungen, Antworten, Warnmeldungen und Anwendungsnachrichten können dann die SPF-Prüfung nicht bestehen.

Wenn Sie bereits an der Zustellbarkeit und einer professionellen Geschäftsmail-Konfiguration arbeiten, gehört dies zur selben Aufgabe. TrekMails Leitfaden zur Geschäftsmail für kleine Unternehmen erklärt die Gesamtstruktur. Hier geht es dagegen um den konkreten Fehler durch zu viele DNS-Referenzen in SPF und seine Behebung, ohne benötigte Absender auszuschließen.

Kurz gesagt: SPF erlaubt bei der Auswertung höchstens 10 DNS-auslösende Terme. Die Zählung umfasst auch rekursiv ausgewertete Verweise. Ihre Anbieter zählen ebenso wie deren Unteranbieter. Auch fehlerhafte oder veraltete includes können beteiligt sein. Wird die Grenze überschritten, sind zu viele DNS-Referenzen in SPF ein echtes Authentifizierungsproblem und keine ignorierbare Warnung.

Was bedeutet „zu viele DNS-Referenzen in SPF“?

Zu viele DNS-Referenzen in SPF bedeutet, dass der Empfangsserver bei der SPF-Auswertung mehr als 10 DNS-auslösende Terme verarbeiten müsste. Gemäß RFC 7208 muss dies PermError ergeben. Die SPF-Verarbeitung endet dann mit einem Fehler statt dem erwarteten Authentifizierungsergebnis.

Die Regel soll missbräuchliche oder aufwendige DNS-Rekursion begrenzen. Sie ist verbindlich. RFC 7208 verlangt bei Überschreitung PermError. Auch Microsofts SPF-Dokumentation warnt davor, dass zu viele Referenzen die SPF-Prüfung scheitern lassen.

Deshalb tritt das Problem so oft bei Domains auf, deren Toollandschaft über Jahre gewachsen ist: Google Workspace, Microsoft 365, CRM, Ticketsystem, Newsletterplattform und vielleicht ein Weiterleitungs- oder Relaydienst. Jedes include wirkt einzeln unproblematisch. Entscheidend ist jedoch die Kette.

„Nur drei includes“ sind also keine Entwarnung. Ein include kann weitere Referenzen nach sich ziehen. Zu viele DNS-Referenzen in SPF betreffen die vollständigen Auswertungspfade, nicht nur die oberste Zeile im DNS.

Welche SPF-Mechanismen zählen zum Limit?

Nur bestimmte SPF-Mechanismen lösen DNS-Auflösung aus. Diese Unterscheidung ist wichtig: Oft lassen sich zu viele DNS-Referenzen in SPF am schnellsten durch einfachere, passende Absenderfreigaben reduzieren. Für eine belastbare Prüfung müssen Sie wissen, was zählt. Die Tabelle vereinfacht den Aufwand; sie zählt keine einzelnen DNS-Pakete.

Mechanismus	Abfragebedarf	Hinweise
`include:`	1	Häufige Ursache, weil die rekursive Auswertung weitere Referenzen umfasst.
`a`	1	Löst A- oder AAAA-Einträge auf.
`mx`	1+	Löst MX-Einträge auf; zusätzliche MX-Untergrenzen können greifen.
`ptr`	1+	Ausdrücklich nicht empfohlen. Nicht verwenden.
`exists`	1	Kommt in komplexeren oder makrogestützten Konfigurationen vor.
`redirect=`	1	Leitet die SPF-Auswertung an einen anderen Eintrag weiter.
`ip4` / `ip6`	0	Statische Angaben ohne DNS-Auflösung während der Auswertung.
`all`	0	Nur abschließende Richtlinie, ohne Abfragebedarf.

Eine weitere Falle: RFC 7208 empfiehlt höchstens zwei leere Abfragen, also Antworten mit NXDOMAIN oder ohne Daten. Dadurch kann die Fehlersuche bei zu vielen DNS-Referenzen in SPF zusätzlich erschwert werden: Der Eintrag kann scheitern, obwohl Sie vermeintlich unter 10 geblieben sind.

Beispiel: Der Tippfehler in include:spf.trekmaill.net kann eine leere Abfrage verursachen. Bei zwei ungültigen Domains in der Kette sollten Sie nach weiteren leeren Abfragen suchen. Wird die vom Empfänger angewandte Obergrenze überschritten, kann PermError entstehen, noch bevor das allgemeine Abfragelimit zum Hauptproblem wird.

Wie prüfen Sie zu viele DNS-Referenzen in SPF?

Beginnen Sie beim SPF-Haupteintrag, verfolgen Sie jedes include und zählen Sie die DNS-auslösenden Mechanismen auf den tatsächlichen Auswertungspfaden. Verlassen Sie sich weder auf Schätzungen noch auf alte Screenshots. Fragen Sie den aktuellen Eintragsbaum im DNS ab.

Beginnen Sie mit dem Haupteintrag:

dig +short txt example.com

Lösen Sie anschließend jedes gefundene include auf:

dig +short txt _spf.google.com

# or

dig +short txt spf.protection.outlook.com

dig +short txt spf.trekmail.net

Zählen Sie unterwegs jedes ausgewertete include, a, mx, exists und redirect, einschließlich verschachtelter Einträge. Hat ein Anbieter kürzlich sein SPF geändert, kann ein zuvor unauffälliger Eintrag jetzt das Limit überschreiten, ohne dass Sie selbst etwas geändert haben.

Eine kurze Prüfliste:

Den aktuellen SPF-TXT-Eintrag der Domain abrufen.
Alle eingebundenen Domains rekursiv auflösen.
DNS-auslösende Mechanismen auf den vollständigen Auswertungspfaden zählen.
Nach Tippfehlern, stillgelegten Anbietern und leeren Antworten suchen.
Doppelte Dienste entfernen, bevor Sie komplexere Maßnahmen ergreifen.

Richten Sie zugleich eine neue Domain ein, zeigt TrekMails Leitfaden zu den erforderlichen DNS-Einträgen die übersichtliche Grundstruktur, die Sie beibehalten sollten.

Was verursacht meist zu viele DNS-Referenzen in SPF?

Meist entsteht das Problem durch eine wachsende Anbieterlandschaft statt eines einzelnen gravierenden Fehlers. Über Monate oder Jahre kommt ein include nach dem anderen hinzu. Fehlt eine gemeinsame Verantwortung für die Richtlinie, wächst sie bis zur fehlerhaften Auswertung.

Die typischen Ursachen sind unspektakulär:

Alte Anbieter bleiben nach einer Migration eingetragen. Marketingtools nutzen dieselbe Hauptdomain wie die Geschäftsmail. Mehrere Teams erlauben Absender ohne gemeinsames Verzeichnis. Oder jemand kopiert einen SPF-Beispieleintrag, ohne dessen verschachtelte includes zu prüfen.

Auch eigene SMTP-Konfigurationen tragen häufig dazu bei. Mehrere Versanddienste auf einer Hauptdomain erhöhen das Risiko. Verwaltetes TrekMail-SMTP kann die Konfiguration durch einen gemeinsamen include-Einstieg vereinfachen; Unterverweise müssen trotzdem geprüft werden. Bei BYO SMTP verwalten Sie den SPF-Bedarf jedes Providers selbst.

Agenturen betrifft dies häufig stärker als Unternehmen mit nur einer Domain. Alte Konfigurationen verteilen sich auf viele Kundenzonen, und ein vergessener include kann jahrelang bestehen bleiben.

Ein sinnvoller Ansatz: Versandströme auf Subdomains aufteilen

Eine übersichtliche Lösung für zu viele DNS-Referenzen in SPF ist die Trennung unterschiedlicher Versandströme auf Subdomains. Jede Subdomain erhält einen eigenen SPF-Eintrag und ein eigenes Abfragebudget. So bleibt die Hauptdomain schlank, während umfangreiche Versanddienste getrennt arbeiten.

Beispiel:

# Root domain for staff and transactional mail
example.com. TXT "v=spf1 include:spf.trekmail.net -all"

# Marketing subdomain for bulk mail
news.example.com. TXT "v=spf1 include:servers.mcsv.net include:spf.mailvendor.com -all"

SPF prüft den Envelope-Absender und nicht einfach das sichtbare From-Feld. Deshalb müssen Supportpostfach und Newslettertool nicht dasselbe SPF-Budget nutzen.

Diesen Ansatz würde ich bei zu vielen DNS-Referenzen in SPF zuerst prüfen. Er kann den Umfang betroffener Systeme begrenzen und die Hauptdomain entlasten. Auch eine Trennung reputationsrelevanter Versandströme ist möglich, wobei Subdomains allein keine vollständige Reputationsisolation garantieren.

Für angrenzende Aufgaben bei klareren Domaingrenzen helfen diese TrekMail-Artikel: E-Mail mit eigener Domain erstellen und E-Mail-Hosting für mehrere Domains.

Sollten Sie SPF zur Entlastung flach auflösen?

Flattening kann zu viele DNS-Referenzen in SPF reduzieren, indem include-Ketten durch direkte ip4- und ip6-Angaben ersetzt werden. Statische IP-Mechanismen benötigen bei der SPF-Auswertung keine DNS-Auflösung. Der Nachteil ist die Pflege: Ändert der Provider seine Infrastruktur, können die Angaben veralten.

Vor dem Flattening:

v=spf1 include:spf.example-vendor.com -all

Nach dem Flattening:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.12 -all

Flattening kann sinnvoll sein, wenn:

Der Provider stabile IP-Bereiche veröffentlicht.
Eine Automatisierung den Eintrag aktualisiert.
Sie eine akute Störung vorübergehend beheben müssen.

Flattening ist riskant, wenn:

Der Anbieter seine IP-Adressen häufig ändert.
Sie viele Domains manuell verwalten.
Keine Überwachung Abweichungen erkennt.

Flattening kann also das SPF-Abfragelimit entlasten, ist aber nicht automatisch die richtige Dauerlösung. Ohne Wartung ersetzen Sie eine Fehlerquelle durch eine andere.

Alter und neuer Umgang mit zu vielen DNS-Referenzen in SPF

Viele Teams reagieren mit weiteren DNS-Änderungen und hoffen, dass nichts scheitert. Sinnvoller ist, Abhängigkeiten zu reduzieren: weniger Absender, klarere Domaingrenzen und eine gemeinsame Plattform für alltägliche Geschäftsmail. Das klingt weniger spektakulär als „fortgeschrittene SPF-Optimierung“, ist aber oft leichter zu betreiben.

Alter Ansatz	Neuer Ansatz
Immer weitere Drittanbieter-includes auf der Hauptdomain	Hauptdomain schlank halten und Massenversender auf Subdomains verlagern
Eine eigene Mailplattform für jeden Arbeitsablauf	Alltägliche Geschäftsmail auf einer Plattform bündeln
Einträge manuell flach auflösen und nicht mehr aktualisieren	Nach Möglichkeit verwalteten Versand nutzen und Flattening nur automatisiert pflegen
Das SPF-Problem erst bei schlechterer Zustellung untersuchen	Abfragebedarf bei jeder Anbieteränderung prüfen

Hier kann TrekMail passen. Ein SPF-include ist für übliche Unternehmens- und Agenturkonfigurationen einfacher zu pflegen als ein Geflecht alter Anbieter, solange die zugrunde liegende Auswertung geprüft wird. Das beschriebene Angebot umfasst eigene Domains, IMAP-Postfächer, Catch-all, Weiterleitung, ein Migrationstool, API-Zugriff und BYO SMTP oder enthaltenes SMTP in kostenpflichtigen Tarifen. Starter wird ab $3.50 pro Monat bei jährlicher Abrechnung beschrieben; kostenpflichtige Tarife bieten laut Beschreibung eine 14-tägige Testphase mit erforderlicher Kreditkarte. Nano wird als kostenlos ohne erforderliche Karte angeboten. Prüfen Sie die aktuellen Leistungen und Konditionen.

Wenn Sie vorhandene Post umziehen möchten, statt eine unübersichtliche Altplattform weiter zu pflegen, erläutert TrekMails Überblick zur IMAP-Migration die Migration.

Was Sie bei einer aktuellen SPF-Störung sofort tun sollten

Beeinträchtigen zu viele DNS-Referenzen in SPF gerade den Versand, priorisieren Sie die wichtigsten Versandströme und stellen Sie deren gültige SPF-Konfiguration wieder her. Meist bedeutet das: ungenutzte includes entfernen, Marketingversand trennen und den Haupteintrag auf tatsächlich benötigte Geschäftsmail-Absender beschränken.

Alle aktiven Absender der Domain erfassen.
Includes gekündigter oder doppelter Dienste löschen.
Massen- oder Anwendungsversand nach Möglichkeit auf eine Subdomain verschieben.
Den Haupteintrag kurz und nachvollziehbar halten.
Nach jeder Änderung erneut prüfen. Änderungen nicht ungeprüft bündeln.

Ein übersichtlicher Haupteintrag für von TrekMail verwalteten Versand sieht so aus:

v=spf1 include:spf.trekmail.net -all

Mit einem weiteren Absender könnte der Eintrag so aussehen:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Beachten Sie dabei: Pro Domain darf nur ein SPF-TXT-Eintrag veröffentlicht werden. Zwei getrennte SPF-Einträge verursachen einen anderen Fehler.

Beobachten Sie nach der Bereinigung einige Tage lang DMARC- und Authentifizierungsergebnisse. Zu viele DNS-Referenzen in SPF sind häufig Teil eines umfassenderen Pflegeproblems. Ein einzelner grüner Prüfstatus ist deshalb noch kein Abschluss.

Fazit: zu viele DNS-Referenzen in SPF langfristig vermeiden

Eine tragfähige Lösung ist eine einfachere Architektur, nicht komplizierteres DNS. Halten Sie die Hauptdomain schlank, nutzen Sie Subdomains für Massenversand und bündeln Sie Absender, wo es sinnvoll ist. Flattening braucht laufende Pflege. Prüfen Sie bei jedem neuen Anbieter den vollständigen include-Baum.

Das ist der Kern des Vorgehens. Fehlt die Verantwortung für das Absenderverzeichnis, wächst das SPF-Problem. Ein aktuelles Verzeichnis macht die Behebung deutlich übersichtlicher.

Als einfacherer Ausgangspunkt beschreibt TrekMail Mehrdomain-E-Mail-Hosting mit geringem DNS-Verwaltungsaufwand, gemeinsamem Speicher, integrierter IMAP-Migration und ohne Gebühren pro Nutzer. Prüfen Sie den kostenlosen Tarif oder vergleichen Sie die aktuellen kostenpflichtigen Angebote unter TrekMail-Preise. Für weitere Bereinigung hilft auch E-Mail-Weiterleitung einrichten und Fehler beheben.

Zu viele DNS-Referenzen in SPF lassen sich beheben. Behandeln Sie sie nicht als kosmetische Warnung, sondern als fehlerhafte Authentifizierung.

Quellen: RFC 7208 und Microsofts SPF-Leitfaden.