SPF-Eintrag über 255 Zeichen: 3 echte Lösungen (Flattening, Splitting & Komprimierung)

Veröffentlicht am 21. September 2026 · 5 Min. Lesezeit · spFlat!

Ein einzelner DNS-TXT-Character-String darf 255 Oktette nicht überschreiten. Das ist ein DNS-Kodierungslimit (RFC 1035), keine SPF-Erfindung. Wenn Sie mehrere Anbieter als ip4:/ip6:-Bereiche auf Ihre eigene Domain packen, ist das Limit schnell erreicht, oft schneller als das 10-Lookup-Limit.

Die 255-Oktett-Grenze wird häufig falsch verstanden. RFC 7208 verbietet das Aufteilen eines langen Werts nicht. Es verbietet etwas anderes, und die praktische Obergrenze liegt über 255 Zeichen. Hier erfahren Sie, was wirklich scheitert und welche 3 Lösungen zur Spezifikation passen.

Was das 255-Zeichen-Limit wirklich ist

Ein DNS-TXT-Eintrag wird als ein oder mehrere Character-Strings gespeichert. Jeder String umfasst maximal 255 Oktette. RFC 7208 §3.3 sagt: Enthält ein TXT-Eintrag mehrere Strings, MÜSSEN Empfänger sie ohne zusätzliche Leerzeichen aneinanderfügen. So veröffentlichen Sie regelkonform eine SPF-Policy, die länger als 255 Zeichen ist.

Amazon SES macht das bereits auf amazonses.com: ein TXT-Eintrag, zwei Strings in Anführungszeichen, zusammengefügt zu einer v=spf1 … -all-Policy. Das aktuelle Outlook-SPF von Microsoft liegt allein bei ~248 Zeichen. Googles bei ~192. Packen Sie beide plus SendGrid als rohe CIDRs auf Ihre Domain, liegen Sie klar über 255 und über einer komfortablen UDP-DNS-Antwort.

Zwei verschiedene Fehler werden oft als „zu lang“ zusammengeworfen:

• Zwei (oder mehr) v=spf1-TXT-Einträge am selben Namen: RFC 7208 §3.2 macht daraus einen PermError. Manche DNS-Oberflächen teilen einen langen eingefügten Wert auf einen zweiten Eintrag auf. Das ist die gefährliche Teilung.
• Ein TXT-Eintrag, mehrere Strings: erlaubt. Das Risiko liegt beim Panel, nicht beim RFC: fehlende Leerzeichen beim Zusammenfügen, oder die gesamte Antwort wächst über die ~450-Oktett- bzw. 512-Byte-UDP-Richtlinie in §3.4.

Lösung 1: Mehrere Strings in einem TXT-Eintrag (gültig, aber fehleranfällig)

Der von RFC 7208 vorgesehene Weg über 255 Oktette pro String sind Teilstücke in Anführungszeichen in einem einzigen TXT-Eintrag:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com "
"include:sendgrid.net include:mailgun.org ~all"

Empfänger fügen diese Strings ohne zusätzliche Leerzeichen zusammen. Setzen Sie das Leerzeichen ans Ende des ersten Stücks (wie oben), sonst kleben Tokens aneinander und Sie bekommen einen Syntaxfehler. Route 53, Cloudflare und andere dokumentieren diese Schreibweise; der öffentliche Amazon-SES-Eintrag ist ein reales Beispiel.

Das löst die Grenze pro String. Es verkleinert die DNS-Antwort nicht und schützt also nicht vor dem Abschneiden (Truncation) bei UDP. Und wenn Ihre Oberfläche einen zweiten TXT-Eintrag statt eines zweiten Strings anlegt, gibt es PermError. Prüfen Sie nach dem Veröffentlichen mit dig TXT, was wirklich im DNS steht.

Lösung 2: Eintrag komprimieren (schnelle Hilfe, reicht nicht immer)

Sie können oft Zeichen sparen, ohne die Bedeutung zu ändern:

• redirect= oder redundante Mechanismen entfernen, falls vorhanden
• ip4:/ip6:-Einträge streichen, die bereits von einem Include abgedeckt sind
• Doppelte Einträge entfernen (z. B. eine ip4:-Angabe, die auch innerhalb eines Includes steckt)

Das verschafft Luft, verzögert das Problem aber nur. Jeder neue Anbieter bringt Sie wieder näher an beide Limits.

Lösung 3: Gehostetes Flattening (kurz und unter 10 Lookups)

Alle aufgelösten CIDRs auf die eigene Domain zu packen macht den TXT-Eintrag meist länger, nicht kürzer. Klein bleibt der Eintrag mit einem Include auf einen Flattening-Dienst:

Vorher (mehrere Includes, verschachtelte Lookups oder eine riesige IP-Liste):

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org ~all

Nachher gehostetes Flattening (ein Lookup auf Ihrer Domain):

v=spf1 include:_yourdomain.spf.spflat.cloud ~all

Empfänger machen einen Include-Lookup. Die lange IP-Liste liegt auf dem Flattening-Hostnamen, wo sie in gültige TXT-Strings aufgeteilt und aktuell gehalten werden kann. Ihr veröffentlichter Eintrag bleibt klar unter 255 Zeichen und unter 10 Lookups.

Das Fazit

1. Mehrere Strings in einem TXT-Eintrag: RFC-konform für die 255-Oktett-String-Grenze. Prüfen Sie, dass Sie nicht zwei SPF-Einträge veröffentlicht haben, und achten Sie auf die UDP-Größe.
2. Komprimierung: brauchbar als Übergangslösung, skaliert aber nicht.
3. Gehostetes Flattening mit spFlat!: die dauerhafte Lösung, ein kurzer Include auf Ihrer Domain, Lookups und Größe werden dahinter verwaltet. Kostenloser Checker, danach 14-Tage-Testversion.

Prüfen Sie Ihre Domain auf spflat.cloud. Sie sehen die aktuelle Lookup-Anzahl (und den 10-Lookup-PermError) und ob ein weiterer Anbieter die Auswertung zum Scheitern bringen würde.