Ein SPF-Record, der mehr als zehn DNS-Lookups braucht, ist kaputt, aber nicht so, wie es die meisten Leitfäden beschreiben. Die Auswertung hält beim ersten Mechanismus an, der zum verbindenden Server passt, ein Absender, der beim zweiten Term passt, erreicht den zwölften also nie. Über dem Limit heißt, dass der Record einen permanenten Fehler zurückgeben kann, und es für jeden Absender tut, der nicht früher gepasst hat. Die Reihenfolge entscheidet, wen es trifft.
Dieser Unterschied zählt, weil er die Lösung verändert. Würde das Limit jede Nachricht brechen, wüssten Sie es sofort. Stattdessen bricht es die Absender am Ende des Records, und das ist üblicherweise die Plattform, die Sie zuletzt hinzugefügt haben und am seltensten prüfen.
include sagt dem Empfänger, er soll einen anderen Record nachschlagen
Der Mechanismus include kopiert nicht den Record einer anderen Domain in Ihren. Er sagt dem empfangenden Server, er soll den SPF-Record dieser anderen Domain als eigene Prüfung auswerten und das Ergebnis verwenden: Besteht die verbindende IP dort, passt das include und die Auswertung hält an.
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Dieser Record sagt: Prüfe Googles Liste, dann SendGrids Liste, und wende dann ~all auf alles an, was zu keiner von beiden passte. Jedes include reicht dem Empfänger einen frischen Record zum Parsen, der selbst weitere include-Terms enthalten kann, und genau dorthin geht das Budget.
Das Wort führt in einem bestimmten Punkt in die Irre. include liefert nur ein Bestehen oder ein Nicht-Passen. Ein -all innerhalb eines eingebundenen Records weist Ihre Mail nicht ab; es heißt nur, dass dieser Record nicht gepasst hat, und die Auswertung läuft mit Ihrem nächsten Term weiter. Nur das all in Ihrem eigenen Record entscheidet das Ergebnis.
Fünf Mechanismen verbrauchen das Budget, drei sind kostenlos
RFC 7208 Abschnitt 4.6.4 begrenzt eine SPF-Auswertung auf zehn Terms, die DNS abfragen. Darüber zu liegen ist ein permanenter Fehler auf MUST-Ebene, keine weiche Warnung.
| Term | Kostet einen Lookup |
|---|---|
include | Ja, samt allem darin |
a | Ja |
mx | Ja |
ptr | Ja, und er ist veraltet |
exists | Ja |
ip4 | Nein |
ip6 | Nein |
all | Nein |
exp | Nein |
Zwei Details dieser Tabelle werden häufig falsch wiedergegeben. Ein mx-Term kostet einen Lookup für den Term, nicht einen pro zurückgegebenem MX-Record, und ein Record, der hundert IP-Adressen mit ip4 auflistet, verbraucht überhaupt nichts. Dieser zweite Punkt ist die gesamte Grundlage des SPF-Flattening.
Das Makro %{p} wird demselben Budget von zehn angelastet, weil seine Auflösung einen Reverse-Lookup verlangt.
Gezählt werden ausgewertete Terms, nicht genannte Domains
Das ist die Regel, die einen Record mehr kosten lässt, als er aussieht. Das Limit zählt jeden DNS-abfragenden Term, den ein Empfänger während einer Prüfung auswertet, und eine über zwei verschiedene Zweige erreichte Domain wird zweimal ausgewertet.
Bindet Ihr Record zwei Anbieter ein und binden beide dieselbe gemeinsame Infrastruktur-Domain ein, wird deren gesamter Teilbaum zweimal bezahlt. Unterschiedliche Domainnamen zu zählen ergibt eine niedrigere Zahl als die, die ein Empfänger erreicht, und deshalb kann ein Record, der auf dem Papier nach sechs Lookups aussieht, in der Praxis permerrorn.
Zwei verwandte Fälle haben denselben Charakter:
- Eine Schleife ist ein permanenter Fehler, kein zu überspringender Zweig. Bindet A B ein und B A, hält ein Empfänger nicht still an, sondern lässt den Record durchfallen.
- Terms nach
allwerden nie ausgewertet.allpasst immer, alles dahinter ist also toter Code und kostet nichts. Einredirectneben einemallist aus demselben Grund wirkungslos.
Über dem Limit scheitern die Absender am Ende Ihres Records
Ein Empfänger wertet Ihre Terms der Reihe nach aus und hält beim ersten Treffer an. Daraus ergeben sich aus einem einzigen kaputten Record drei verschiedene Ausgänge, je nachdem, wer sendet.
- Ein Absender, der vor dem Aufbrauchen des Budgets passt, besteht normal. Für ihn ist nichts kaputt, und in Ihren Logs taucht nichts auf.
- Ein Absender, der nach dem zehnten Lookup passt, bekommt einen permanenten Fehler. Die meisten Empfänger behandeln einen Permerror als Fehlschlag und nicht als fehlenden Record, DMARC sieht also kein SPF-Bestehen.
- Ein Absender, der gar nicht in Ihrem Record steht, trifft auf Ihren
all-Term, genau wie vorgesehen, sofern die Auswertung so weit kommt.
Das praktische Symptom ist also, dass die Mail einer Plattform plötzlich an der Authentifizierung scheitert, während alles andere gut aussieht. Wurde diese Plattform ans Ende des Records gesetzt, fällt sie als erste über die Kante.
Das heißt auch, dass eine Abhilfe umsonst sein kann. Ihren volumenstärksten Absender an den Anfang des Records zu ziehen senkt die Summe nicht, sorgt aber dafür, dass dieser Absender passt, bevor das Budget verbraucht ist. Das kauft Zeit, es löst nichts.
Wie Sie die echte Zahl finden
Von Hand zu zählen ist unzuverlässig, weil Sie nicht in den Record eines Anbieters sehen können, ohne ihn aufzulösen, und Anbieter ändern ihren ohne Sie zu informieren. Schicken Sie die Domain durch einen kostenlosen SPF-Checker, der den ganzen Baum abläuft, jedes include rekursiv auflöst und die Summe meldet, die ein Empfänger tatsächlich erreichen würde, statt der Zahl der Terms, die Sie getippt haben.
Worauf Sie im Ergebnis achten:
- Die Summe gegen das Limit von zehn. Alles darüber heißt, der Record kann permerrorn.
- Welcher Zweig teuer ist. Meist verantwortet ein Anbieter den Großteil der Kosten, und die Anbieter unterscheiden sich enorm.
- Doppelte Teilbäume. Zweimal erreichte gemeinsame Infrastruktur ist die häufigste versteckte Überschreitung.
- Leere Lookups. Ein Term, der auf nichts auflöst, hat sein eigenes separates Budget, und ein
include, das auf eine Domain ohne SPF-Record zeigt, ist schon beim ersten Auftreten ein permanenter Fehler. - Alles hinter
all. Tote Terms sind harmlos, aber meist ein Zeichen dafür, dass mehrere Leute den Record bearbeitet haben, ohne ihn zu lesen.
Über die Domains, die wir für den Unspam 2026 Email Deliverability Benchmark testen, veröffentlichen 93 % einen gültigen SPF-Record, der übliche Fehler in diesem Bereich ist also nicht ein fehlender Record, sondern einer, der still über sein Budget hinausgewachsen ist.
Vier Wege zurück unter zehn
Grob in der Reihenfolge, in der Sie sie bevorzugen sollten.
Entfernen Sie, was Sie nicht mehr nutzen. Die meisten überschrittenen Records tragen einen Anbieter, über den seit zwei Jahren niemand mehr sendet. Das ist kostenlos, dauerhaft und fast immer verfügbar.
Ersetzen Sie ein include durch ip4-Bereiche, wo der Anbieter stabile veröffentlicht. Ein ip4-Term kostet nichts. Der Haken: Die Pflege gehört jetzt Ihnen. Wechselt der Anbieter die IPs, scheitert Ihre Mail und niemand sagt es Ihnen. Tun Sie das nur, wo der Anbieter einen stabilen Bereich dokumentiert und zusagt, Änderungen anzukündigen.
Verlagern Sie den Versand auf eine Subdomain. Ihre Marketingplattform kann von mail.example.com senden, mit eigenem SPF-Record und eigenem Budget von zehn. Das ist die strukturelle Lösung, sie skaliert, und sie trennt nebenbei die Reputationen.
Flatten Sie den Record mit einem Dienst. SPF-Flattening löst jedes include auf und veröffentlicht die entstehende IP-Liste für Sie, automatisch aktualisiert. Es funktioniert, und es macht die Verfügbarkeit eines Dritten zu einer Abhängigkeit Ihrer Mail-Authentifizierung. Behandeln Sie es als letzte Option, nicht als erste.
Wenn Sie einen Record bauen statt reparieren, erzeugt ein SPF-Record-Generator einen korrekten Startrecord, und unser Leitfaden zu SPF-Records behandelt die Syntax vollständig.
Was zu prüfen ist, sobald der Record unter dem Limit liegt
Dass SPF besteht, ist notwendig, reicht allein aber nicht, denn DMARC braucht die Übereinstimmung der SPF-Domain mit der Adresse in Ihrem From-Header, und SPF bricht beim Weiterleiten, so aufgeräumt der Record auch ist. Unser Leitfaden zur E-Mail-Authentifizierung behandelt, wie die drei Records voneinander abhängen und warum DKIM und nicht SPF das ist, was eine Mailingliste übersteht.
Prüfen Sie die Summe erneut, wann immer Sie eine Versandplattform hinzufügen, und ein paar Monate später noch einmal, auch wenn Sie nichts geändert haben, denn die Zählung schließt die Records der Anbieter ein, und die bewegen sich unter Ihnen. Um zu sehen, wie eine echte Nachricht bei einem Empfänger aussieht, mit dem SPF-Ergebnis neben allem anderen, was die Platzierung entscheidet, machen Sie einen kostenlosen Spam-Test.
