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üsstest du es sofort. Stattdessen bricht es die Absender am Ende des Records, und das ist üblicherweise die Plattform, die du zuletzt hinzugefügt hast und am seltensten prüfst.
include sagt dem Empfänger, er soll einen anderen Record nachschlagen
Der Mechanismus include kopiert nicht den Record einer anderen Domain in deinen. 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 deine Mail nicht ab; es heißt nur, dass dieser Record nicht gepasst hat, und die Auswertung läuft mit deinem nächsten Term weiter. Nur das all in deinem 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 dein 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 deines Records
Ein Empfänger wertet deine 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 deinen 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 deinem Record steht, trifft auf deinen
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. Deinen 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 du die echte Zahl findest
Von Hand zu zählen ist unzuverlässig, weil du nicht in den Record eines Anbieters sehen kannst, ohne ihn aufzulösen, und Anbieter ändern ihren ohne dich zu informieren. Schick 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 du getippt hast.
Worauf du im Ergebnis achtest:
- 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 du sie bevorzugen solltest.
Entferne, was du nicht mehr nutzt. Die meisten überschrittenen Records tragen einen Anbieter, über den seit zwei Jahren niemand mehr sendet. Das ist kostenlos, dauerhaft und fast immer verfügbar.
Ersetze ein include durch ip4-Bereiche, wo der Anbieter stabile veröffentlicht. Ein ip4-Term kostet nichts. Der Haken: Die Pflege gehört jetzt dir. Wechselt der Anbieter die IPs, scheitert deine Mail und niemand sagt es dir. Tu das nur, wo der Anbieter einen stabilen Bereich dokumentiert und zusagt, Änderungen anzukündigen.
Verlagere den Versand auf eine Subdomain. Deine 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.
Lass den Record von einem Dienst flatten. SPF-Flattening löst jedes include auf und veröffentlicht die entstehende IP-Liste für dich, automatisch aktualisiert. Es funktioniert, und es macht die Verfügbarkeit eines Dritten zu einer Abhängigkeit deiner Mail-Authentifizierung. Behandle es als letzte Option, nicht als erste.
Wenn du einen Record baust, statt ihn zu 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 deinem 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üf die Summe erneut, wann immer du eine Versandplattform hinzufügst, und ein paar Monate später noch einmal, auch wenn du nichts geändert hast, denn die Zählung schließt die Records der Anbieter ein, und die bewegen sich unter dir. Um zu sehen, wie eine echte Nachricht bei einem Empfänger aussieht, mit dem SPF-Ergebnis neben allem anderen, was die Platzierung entscheidet, mach einen kostenlosen Spam-Test.
