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 bricht, und welche 3 Lösungen zur Spec passen.

Was das 255-Zeichen-Limit wirklich ist

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

Amazon SES macht das bereits auf amazonses.com: ein TXT-Eintrag, zwei quoted Strings, zusammengefügt zu einer v=spf1 … -all-Policy. Das aktuelle Outlook-SPF von Microsoft liegt allein bei ~248 Zeichen. Googles bei ~192. Beide plus SendGrid als Roh-CIDRs auf Ihre Domain zu packen, liegt 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 Paste in einen zweiten Eintrag. Das ist die gefährliche Teilung.
• Ein TXT-Eintrag, mehrere Strings - erlaubt. Das Risiko ist das Panel, nicht die RFC: fehlende Leerzeichen bei der Konkatenation, oder die gesamte Antwort wächst über die ~450-Oktett- / 512-Byte-UDP-Richtlinie in §3.4.

Lösung 1: Mehrere Strings in einem TXT-Eintrag (gültig - leicht falsch zu machen)

Der von RFC 7208 vorgesehene Weg über 255 Oktette pro String sind quoted Teilstücke 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 extra 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 dieses Quoting; der öffentliche Amazon-SES-Eintrag ist ein Live-Beispiel.

Das löst die Grenze pro String. Es verkleinert die DNS-Antwort nicht - vor UDP-Truncation schützt es also nicht. 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 (schneller Gewinn, 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. ein ip4:, das auch innerhalb eines Includes steckt)

Das verschafft Luft, verzögert das Problem aber nur - jeder neue Anbieter drückt Sie zurück Richtung 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 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 legale 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 - 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 - okay als Übergangslösung, skaliert aber nicht.
3. Gehostetes Flattening mit SPFlat! - die dauerhafte Lösung: ein kurzes Include auf Ihrer Domain, Lookups und Größe dahinter. Kostenloser Checker, danach 14-Tage-Testversion.

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