Warum das Limit existiert
RFC 7208 deckelt die Auswertung eines SPF-Records auf 10 DNS-abfragende Mechanismen. Ohne diese Grenze könnte ein einzelner Record über verschachtelte include:-Ketten hunderte Abfragen bei jedem Empfänger auslösen — ein bequemer Verstärker für Denial-of-Service-Angriffe.
Gezählt werden a, mx, ptr, exists, include und redirect. Nicht gezählt werden ip4: und ip6: — die brauchen keine Abfrage.
Der Denkfehler: das Budget ist rekursiv
Die Zählung endet nicht bei deinem Record. Jedes include: wird aufgelöst, und was dort an Mechanismen steht, zählt mit — über beliebig viele Ebenen. Drei sichtbare includes können sich so leicht auf zwölf tatsächliche Lookups summieren:
Deshalb hilft bloßes Nachzählen im eigenen Eintrag nicht. Du brauchst die Summe über die ganze Kette — und die ändert sich, wenn ein Anbieter seinen Record erweitert, ganz ohne Zutun deinerseits.
Kürzen, ohne Absender zu verlieren
- Ungenutzte includes entfernen. In fast jedem gewachsenen Record steht ein Dienst, der seit Jahren nicht mehr sendet. Das ist der billigste Gewinn.
aundmxersetzen. Beide kosten je einen Lookup und lösen oft auf feste Adressen auf. Alsip4:eingetragen kosten sie null.- Kleine includes auflösen. Wenn ein Anbieter nur zwei feste IPs hat, ersetze das
include:durch die IPs direkt. Vorsicht: dann pflegst du sie selbst und musst Änderungen des Anbieters mitbekommen. - Subdomains für Massenversand. Der sauberste Weg bei vielen Dienstleistern: Newsletter über
news.deinedomain.demit eigenem SPF-Record versenden. Jede Subdomain hat ihr eigenes 10er-Budget. ptrersatzlos streichen. Der Mechanismus ist langsam, unzuverlässig und wird von RFC 7208 ausdrücklich abgeraten.
Was nicht funktioniert
Ein zweiter SPF-Record für dieselbe Domain ist keine Lösung, sondern ein weiterer permerror: pro Domain ist genau ein v=spf1-Record zulässig. Auch redirect= umgeht nichts — es zählt ebenfalls als Lookup.