SPF und die 255-Zeichen-Grenze: Strings und Aufteilung

Von Thomas · virtueller CISO · 24. August 2026

„Der Eintrag überschreitet 255 Zeichen." Die Meldung erscheint beim Einfügen eines etwas längeren SPF-Eintrags in die Weboberfläche eines DNS-Hosters, und sie löst fast immer dieselbe Sorge aus: Die Liste der Versanddienstleister passt nicht mehr — muss also einer geopfert werden? Die Antwort lautet nein — vorausgesetzt allerdings, es ist klar, was die Grenze wirklich misst. Denn diese Grenze gehört gar nicht zu SPF, sondern zum DNS. Und sie gilt nicht für den Eintrag als Ganzes, sondern für jeden einzelnen Zeichen-String, aus dem er besteht.

Die Nuance ist alles andere als akademisch, sie ändert alles. Ein SPF-Eintrag mit 400 Zeichen ist vollkommen standardkonform, sofern er in mehrere Strings von höchstens 255 Bytes aufgeteilt wird, die der Prüfmechanismus beim Lesen wieder zusammensetzt. Das eigentliche Problem liegt woanders: Zwischen dem, was die RFCs erlauben, und dem, was die Webformulare der DNS-Hoster akzeptieren, klafft eine Lücke — glatte Ablehnungen, automatische Aufteilung im Glücksfall und vor allem stilles Abschneiden, das einen gültigen Eintrag in einen permanenten Fehler verwandelt.

Dieser Artikel zerlegt die Mechanik: woher die Grenze kommt (das Binärformat des DNS), wie die Aufteilung in mehrere Strings funktioniert, wo es in der Praxis bricht, warum die Größe der UDP-Antworten einen zweiten Grund zur Kürze liefert und wie sich ein aufgeblähter Eintrag abspecken lässt — ohne diese Byte-Grenze mit der Grenze der zehn DNS-Abfragen zu verwechseln, die eine völlig andere Geschichte ist.

Eine DNS-Grenze, keine SPF-Grenze

RFC 1035, die das Format der DNS-Nachrichten seit 1987 festlegt, beschreibt den Inhalt eines TXT-Eintrags als Folge von einem oder mehreren „character-strings". Jeder String wird auf dem Draht mit einem einzelnen Längen-Byte kodiert, das seine Länge ankündigt. Ein Byte kann nur von 0 bis 255 zählen: Das ist der exakte — und einzige — Ursprung der berühmten Grenze. Weder eine Entscheidung von SPF noch eine Laune eines Hosters, sondern eine Eigenschaft des Übertragungsformats des Protokolls, unverändert seit fast vierzig Jahren.

Die direkte Konsequenz: Die Grenze gilt pro String, niemals pro Eintrag. Ein TXT-Eintrag kann mehrere Strings hintereinander enthalten, und seine Gesamtgröße wird nur durch die Größe der DNS-Nachricht begrenzt — theoretisch bis zu 65 535 Bytes an Daten, praktisch deutlich weniger, wie weiter unten zu sehen ist. Der Satz „SPF ist auf 255 Zeichen begrenzt", in unzähligen Foren wiederholt, ist so formuliert schlicht falsch. Die korrekte Fassung passt in einen Satz: Jeder String eines TXT-Eintrags ist auf 255 Bytes begrenzt, und ein SPF-Eintrag darf mehrere davon enthalten.

Ein letzter Vokabelpunkt: Gezählt werden Bytes, nicht „Zeichen" im visuellen Sinn. Für SPF, das nur aus ASCII besteht, fallen beide exakt zusammen; das Zählen in Bytes bleibt trotzdem der richtige Reflex, denn bei anderen Verwendungen von TXT-Einträgen gehen die Werte auseinander.

Aufteilung in mehrere Strings: Syntax und Zusammenfügen

In einer Zonendatei wird die Aufteilung durch nebeneinandergestellte Strings in Anführungszeichen geschrieben:

beispiel.de.  IN  TXT  ( "v=spf1 ip4:192.0.2.0/28 ip4:198.51.100.0/26 include:_spf.google.com "
                         "include:spf.protection.outlook.com include:sendgrid.net ~all" )

RFC 7208, die SPF definiert, legt in Abschnitt 3.3 genau fest, was der Prüfmechanismus tut: Er verkettet die Strings ohne Leerzeichen einzufügen. Die beiden Strings oben werden wieder zu einem einzigen logischen Eintrag, gelesen, als hätte der Schnitt nie existiert. Der Schnittpunkt darf dabei überall liegen, auch mitten in einem Mechanismus: "…include:_spf.goo" "gle.com ~all" bleibt nach dem Zusammenfügen gültig, weil die Verkettung Byte für Byte erfolgt. Die Lesbarkeit spricht freilich dafür, an einer Termgrenze zu schneiden.

Die klassische Falle steckt genau in diesem „ohne Leerzeichen einzufügen". Das Leerzeichen zwischen zwei Mechanismen muss innerhalb eines der Strings existieren — am Ende des ersten oder am Anfang des zweiten. Wird es vergessen, verschweißt das zwei Mechanismen zu einem einzigen ungültigen Token, include:sendgrid.netinclude:spf.mailjet.com, und der gesamte Eintrag wird syntaktisch falsch: permerror bei jeder Auswertung, für sämtliche Mailflüsse der Domain.

Eine weitere Verwechslung gehört gleich ausgeräumt: Mehrere Strings in einem Eintrag haben nichts mit mehreren TXT-Einträgen zu tun, die jeweils mit v=spf1 beginnen. Der erste Fall ist vom Standard ausdrücklich vorgesehen; der zweite ist ein Fehler, der ebenfalls mit einem permanenten Fehler bestraft wird und in was bei mehreren SPF-Einträgen passiert seziert wird.

Wo es in der Praxis bricht: DNS-Oberflächen und Copy-Paste

Konfrontiert mit einem Wert von mehr als 255 Zeichen, zerfallen die Oberflächen der DNS-Hoster in drei Familien. Die erste lehnt glatt ab: eine explizite Fehlermeldung, der Wert wird nicht gespeichert. Ärgerlich, aber gesund — der Fehlschlag ist sichtbar und in einer Minute behoben, indem von Hand aufgeteilt wird. Die zweite Familie teilt automatisch auf: Die Oberfläche akzeptiert den langen Wert und segmentiert ihn beim Erzeugen der Zone in konforme Strings. Cloudflare verfährt so, und es ist das ideale Verhalten: Der Wert wird am Stück eingefügt, die Resolver erhalten einen korrekten Eintrag.

Die dritte Familie ist die gefährliche: Oberflächen, die still abschneiden oder verfälschen. Ein Formularfeld mit unsichtbarem maxlength amputiert den eingefügten Wert beim 255. Zeichen, oft mitten in einem Mechanismus — der veröffentlichte Eintrag endet dann auf include:_spf.beispiel- und danach nichts. Das Ergebnis: syntaktisch ungültiges SPF, permerror bei jeder Prüfung. Unter DMARC kommt ein SPF-permerror dem völligen Fehlen von SPF gleich: Die gesamte Authentifizierung ruht dann auf DKIM, und Flüsse, die nur SPF mitbringen — manche Fachanwendungen, betagte Applikationsserver — scheitern schlicht.

Copy-Paste legt eine eigene Schicht von Fallen darüber: ein Zeilenumbruch, den ein Mailprogramm oder eine Textverarbeitung eingefügt hat, typografische Anführungszeichen, die eine Autokorrektur den geraden untergeschoben hat, eine Oberfläche, die den nackten Wert erwartet und die Anführungszeichen als Literale speichert. Keine dieser Verfälschungen löst bei der Eingabe einen Alarm aus; sie zeigen sich erst bei der Prüfung von außen, nach der Propagation — daher der dig-Reflex, der weiter unten beschrieben wird.

Antwortgröße: UDP, EDNS und Robustheit

Die Grenze pro String ist nicht der einzige Grund, das Gewicht eines SPF-Eintrags im Auge zu behalten. Das DNS transportiert seine Antworten historisch über UDP, mit einer Obergrenze von 512 Bytes pro Nachricht aus RFC 1035. Die Erweiterung EDNS0 hat diese Obergrenze angehoben — die meisten Resolver kündigen heute 1 232 Bytes an, den seit dem DNS Flag Day 2020 empfohlenen Wert —, doch der Rückfallmechanismus ist derselbe geblieben: Eine zu große Antwort wird als abgeschnitten markiert (TC-Bit), und der Client muss es über TCP erneut versuchen. Alte Firewalls blockieren jedoch nach wie vor Port 53 über TCP, und manche Zwischengeräte misshandeln große UDP-Pakete. Eine aufgeblähte Antwort wird dann zur verlorenen Antwort: Der Prüfmechanismus liefert temperror, und die legitime Nachricht wird zurückgestellt oder ohne Authentifizierung bewertet.

Ein Detail verschärft die Rechnung: Eine TXT-Abfrage liefert alle TXT-Einträge des Namens zurück, nicht nur den SPF-Eintrag. Die über die Jahre angesammelten Verifikations-Token — google-site-verification=…, MS=…, Validierungen längst vergessener SaaS-Werkzeuge — teilen sich dieselbe Antwort und blähen deren Größe auf. Ein SPF von 300 Bytes in einer Antwort, die bereits 600 Bytes an Token trägt, überschreitet die Schwelle deutlich früher als gedacht. RFC 7208 empfiehlt ausdrücklich, die Antwort bescheiden zu halten: Die Robustheit spricht für Kürze, selbst wenn die Aufteilung in Strings die Länge formal „legal" macht.

Einen aufgeblähten SPF-Eintrag abspecken

Vor dem Aufteilen kommt das Kürzen. Ein aufgeblähter SPF-Eintrag ist fast immer ein sedimentierter: Jahre von Ergänzungen, nie eine Streichung. Die Bereinigung folgt einer logischen Reihenfolge.

Tote Mechanismen. Der vor zwei Jahren verlassene ESP, der stillgelegte Server, die Agentur mit beendetem Vertrag: Deren include:- und ip4:-Einträge bleiben stehen. Die DMARC-Berichte entscheiden — eine Quelle, die seit Monaten in keinem Bericht mehr auftaucht, kann raus.
Redundanzen. Ein ip4:, das eine bereits von einem include: abgedeckte Adresse benennt, zwei include: desselben Anbieters unter verschiedenen Namen, ein mx, obwohl die Eingangsserver nie etwas versenden: lauter geschenkte Bytes.
CIDR-Aggregation. Vier zusammenhängende Adressen, einzeln aufgelistet (ip4:192.0.2.16 ip4:192.0.2.17 ip4:192.0.2.18 ip4:192.0.2.19), komprimieren sich zu einem einzigen Block ip4:192.0.2.16/30. Bei breiteren Bereichen geht die Ersparnis in die Dutzende von Bytes.
Der Mechanismus ptr. Von RFC 7208 selbst abgeraten, teuer und unzuverlässig: Sein Platz ist im Archiv, nicht im Eintrag.
Delegation über Subdomains. Der stärkste Hebel: Der Newsletter geht von news.beispiel.de aus, die Rechnungsstellung von billing.beispiel.de, jede mit eigenem, kurzem SPF. Die Hauptdomain trägt nur noch die eigenen Flüsse, und jeder Eintrag bekommt Luft.

Zwei verwandte Techniken verdienen einen Verweis statt einer Abhandlung an dieser Stelle. Das Flattening — die include:-Einträge durch ihre aufgelösten IP-Adressen ersetzen — reduziert die DNS-Abfragen, verlängert aber den Eintrag, also das genaue Gegenteil des Ziels dieser Seite; seine Versprechen und Fallstricke werden in SPF-Flattening und seine Tücken untersucht. Und die Makros aus RFC 7208, die bestimmte Anwendungsfälle radikal verdichten können, haben ihren eigenen Artikel: SPF-Makros und der exists-Mechanismus.

255 Zeichen und 10 Lookups: zwei Grenzen ohne Gemeinsamkeit

Die 255-Zeichen-Grenze wird regelmäßig mit der anderen berühmten Obergrenze von SPF verwechselt: den zehn Mechanismen, die eine DNS-Abfrage auslösen (include, a, mx, ptr, exists, dazu der Modifikator redirect). Dabei haben die beiden nichts gemeinsam. Die erste ist eine Kodierungsvorgabe des DNS: Gemessen wird in Bytes, und die saubere Umgehung heißt Aufteilung in Strings. Die zweite ist eine Regel von SPF selbst: Gezählt wird in DNS-Auflösungen, und ab der elften Abfrage endet die Auswertung in einem normativen permerror.

Die Verwechslung rührt daher, dass beide dieselben Opfer treffen — Einträge, die ohne Aufsicht gewachsen sind —, doch die Abhilfen gehen auseinander und stehen sich mitunter frontal entgegen. Das Flattening heilt die Lookups und verschlimmert die Größe; die Aufteilung in Strings heilt die Größe, ohne eine einzige Abfrage einzusparen. Ein sehr kurzer Eintrag kann die Abfragegrenze sprengen (drei verschachtelte include: genügen), während ein 350-Byte-Eintrag, der nur aus ip4: besteht, keinen einzigen Lookup verbraucht. Zu klären, welche der beiden Grenzen tatsächlich das Problem ist, bildet daher die Voraussetzung jeder Korrektur — die Obergrenze der zehn DNS-Abfragen hat ihre eigene Gebrauchsanleitung, und die Lektüre lohnt, bevor irgendetwas angefasst wird.

Die Prüfung: dig, Anführungszeichen und Zählen

Für die Prüfung genügt dig, auf jeder Unix-Maschine vorhanden (unter Windows nslookup -type=TXT):

$ dig +short TXT beispiel.de
"v=spf1 ip4:192.0.2.0/28 include:_spf.google.com " "include:sendgrid.net ~all"
"google-site-verification=kX3v…"

Die Ausgabe sagt alles. Jedes Anführungszeichenpaar markiert einen String: Zwei Paare auf der SPF-Zeile bedeuten, dass der Eintrag aufgeteilt ist und dass die Aufteilung die Oberfläche des Hosters überlebt hat. Das Leerzeichen an der Nahtstelle lässt sich mit bloßem Auge kontrollieren — hier am Ende des ersten Strings. Die Gesamtzählung passt in einen Befehl:

$ dig +short TXT beispiel.de | grep spf1 | wc -c

Entscheidend ist nicht die Summe, sondern die Verteilung: Jeder einzelne String muss unter 255 Bytes bleiben, was die Anwesenheit mehrerer Anführungszeichenpaare auf einen Blick belegt. Drei Reflexe runden das Werkzeug ab: nach der Propagation prüfen (die TTL des alten Eintrags kann die Änderung stundenlang verdecken), einen öffentlichen Resolver befragen (@1.1.1.1, @9.9.9.9) statt des lokalen Caches, und in den Folgetagen die DMARC-Berichte beobachten — ein permerror durch Abschneiden steht dort schwarz auf weiß, wo die DNS-Oberfläche niemals etwas anzeigen wird.

Fazit

Die „255-Zeichen-Grenze" von SPF ist in Wahrheit eine DNS-Regel: 255 Bytes pro Zeichen-String eines TXT-Eintrags, niemals pro Eintrag. Ein langer SPF-Eintrag bleibt konform, sofern er in mehrere Strings aufgeteilt wird, die der Prüfmechanismus ohne Leerzeichen verkettet; die echten Brüche kommen von Oberflächen, die still abschneiden, von verfälschtem Copy-Paste und von DNS-Antworten, die für UDP zu groß geworden sind. Die richtige Reihenfolge: erst abspecken (tote Mechanismen, Redundanzen, CIDR-Aggregation, dedizierte Subdomains), dann bei Bedarf aufteilen, immer mit dig prüfen — und diese Byte-Grenze nie mit der Obergrenze der zehn DNS-Abfragen verwechseln, die anderen Gesetzen gehorcht und andere Abhilfen verlangt.

Ob der Eintrag einer Domain die Grenze streift, sauber aufgeteilt ist oder tote Bytes mitschleppt, zeigt in wenigen Sekunden eine kostenlose DMARC-Analyse: der Zustand von SPF neben DKIM und der DMARC-Policy, Aufteilung inklusive. Und um dauerhaft zu verfolgen, was die Berichte über die realen Versandquellen der Domain sagen, öffnet das Anlegen eines Kontos die kontinuierliche Überwachung — die 255-Byte-Grenze selbst wird sich jedenfalls nicht bewegen.