← Frankys Web GitHub Kontakt
Frankys Web Mailtools

E-Mail-Konfigurationen prüfen und verstehen

SPF zusammenfassen

Includes durch ihre IP-Bereiche ersetzen und die 10-Lookup-Grenze unterschreiten.

Dieses Werkzeug braucht ein kostenloses Konto. Alles andere auf mailtools bleibt ohne Anmeldung nutzbar.

Kostenlos registrieren Anmelden

Ein SPF-Record darf beim Prüfen höchstens zehn DNS-Lookups auslösen (RFC 7208 §4.6.4). Jedes include: kostet einen davon, und es bringt die Lookups seines Anbieters mit: hinter _spf.google.com stecken real etwa vier weitere. Drei, vier Dienstleister genügen deshalb, um die Grenze zu reißen. Was dann passiert, ist das Unangenehme daran: der Record wird nicht etwa teilweise ausgewertet, sondern gilt komplett als fehlerhaft (PermError). SPF fällt damit für alle deine Absender aus, nicht nur für den letzten Eintrag.

Im Englischen heißt dieses Verfahren SPF Flattening, und auch im deutschsprachigen Raum wird meist so danach gesucht. Hier heißt es zusammenfassen, weil das sagt, was passiert: aus mehreren Einträgen wird einer.

Was dieses Werkzeug macht

Es löst die Includes Ihres Records auf und ersetzt sie durch die IP-Bereiche, die dahinterstehen. Aus include:_spf.google.com werden die ip4:- und ip6:-Einträge von Google. Passt danach alles in einen Eintrag, kostet dein Record beim Prüfen gar keinen Lookup mehr, weil nichts mehr nachzuschlagen ist. Wird er zu groß, verteilt das Werkzeug ihn auf mehrere Einträge, die der erste über include: zusammenhält; dann bleibt ein Lookup je zusätzlichem Eintrag, und die Rechnung geht trotzdem auf, weil die Lookups deiner Anbieter wegfallen.

Zwei Dinge bleiben dabei stehen. a und mx zeigen auf deine eigene Infrastruktur und werden nicht eingefroren, sonst wären sie nach dem nächsten Serverumzug still falsch. Und Anbieter, die gar keine Liste veröffentlichen, sondern jeden Absender einzeln über eine DNS-Abfrage autorisieren (exists:, so macht es zum Beispiel Salesforce), behalten ihr include:: dort gibt es nichts einzufrieren, heute nicht und nie. Das Werkzeug sagt dir, wenn das der Fall war.

Bringt das alles zusammen keinen Gewinn, bekommst du keinen Record. Eine Ausgabe, die genauso viele Lookups kostet wie vorher und zusätzlich das Verfallsdatum einer Momentaufnahme trägt, wäre keine Verbesserung, sondern ein schlechter Tausch.

Dein ursprünglicher Record bleibt dabei erhalten und bearbeitbar. Das ist kein Beiwerk, sondern der Grund, warum diese Funktion eine Anmeldung verlangt: einem zusammengefassten Record sieht man nicht mehr an, welcher Bereich zu welchem Anbieter gehört. Wer später einen Dienst nicht mehr benutzt, müsste aus hundert Netzen heraussuchen, welche davon zu ihm gehörten. Mit dem gespeicherten Original ist es eine Zeile: das include: löschen, neu zusammenfassen lassen, fertig.

Das Ergebnis lesen

Über dem Ergebnis steht, wie viele Lookups der alte Record gekostet hat und wie viele der neue kostet. Darunter stehen die Einträge, die du anlegen musst, jeder mit vollem Namen. Bei einer Kette gehört der erste Eintrag auf deine Domain selbst, die übrigen auf die genannten Unternamen; erst alle zusammen ergeben den Record. Jeder Eintrag bleibt unter 450 Oktett, damit die DNS-Antwort in ein UDP-Paket passt (RFC 7208 §3.4).

Bekommst du kein Ergebnis, ist das Absicht. Dieses Werkzeug liefert lieber gar keinen Record als einen unvollständigen: ein Record, der still einen Anbieter vergisst, sieht fertig aus und weist dessen Mail ab, und auffallen würde das erst an ausbleibenden Antworten. Abgelehnt wird deshalb, wenn ein Include nicht auflöst, wenn der Record exists:, ptr oder redirect= enthält (die lassen sich nicht in IP-Bereiche übersetzen), wenn selbst die Kette die zehn Lookups wieder reißen würde, oder wenn am Ende nichts gespart wäre.

Hintergrund: der Preis dieser Optimierung

Ein zusammengefasster Record ist eine Momentaufnahme fremder Infrastruktur. Solange include:_spf.google.com im Record steht, holt jeder prüfende Server die aktuellen Bereiche von Google. Stehen die Bereiche direkt drin, gilt der Stand von heute, und zwar so lange, bis du ihn erneuerst. Nimmt der Anbieter neue Adressbereiche in Betrieb, weist dein Record deren Mail ab, ohne dass irgendwo ein Fehler auftaucht: der Record ist syntaktisch einwandfrei, die Prüfung läuft durch, das Ergebnis ist nur falsch.

Deshalb ist diese Funktion an ein Konto gebunden, deshalb trägt jedes Ergebnis sichtbar sein Alter, und deshalb ist der Weg zurück immer offen: dein Original bleibt gespeichert. Wer die Wahl hat, sollte zuerst prüfen, ob sich Includes einsparen lassen: ein alter Newsletter-Dienst, ein abgelöstes Ticketsystem, ein Anbieter, der längst über DKIM signiert. Erst wenn das ausgeschöpft ist, ist das Zusammenfassen der richtige Schritt.

Häufige Fehlerbilder

  • Der Record wurde zusammengefasst und niemand hat ihn je erneuert. Der gefährlichste Zustand überhaupt, weil er lautlos ist. Prüfe ihn regelmäßig gegen das gespeicherte Original.
  • Nur der erste Eintrag der Kette wurde angelegt. Dann findet der prüfende Server die Unternamen nicht, die Includes laufen ins Leere, und es gilt am Ende deine all-Regel für praktisch jede Mail.
  • Der alte Record blieb daneben stehen. Zwei SPF-Records auf derselben Domain sind ein PermError (RFC 7208 §4.5), und dann gilt keiner von beiden.
  • Die Kette wurde von Hand gekürzt. Wer einzelne Bereiche herausnimmt, ohne zu wissen, zu welchem Anbieter sie gehören, sperrt eigene Absender aus. Ändere stattdessen das Original und fasse neu zusammen.

Häufige Fragen

Ist das dasselbe wie SPF Flattening?
Ja. <em>SPF Flattening</em> ist der gängige englische Name für genau dieses Verfahren: Includes werden durch die IP-Bereiche ersetzt, die dahinterstehen. Hier heißt es zusammenfassen, weil das den Vorgang beschreibt statt das Ergebnis. An der Sache ändert der Name nichts, auch nicht an ihrem Preis: ein zusammengefasster Record ist eine Momentaufnahme fremder Infrastruktur und gehört regelmäßig erneuert.
Warum brauche ich dafür ein Konto?
Weil das Ergebnis ohne deinen ursprünglichen Record wertlos wird. Einem zusammengefassten Record sieht man nicht an, welcher IP-Bereich zu welchem Anbieter gehört. Willst du später einen Dienst entfernen, müsstest du aus hundert Netzen heraussuchen, welche davon seine waren. Mit dem gespeicherten Original löschst du eine Zeile und lassen neu zusammenfassen. Dazu kommt, dass ein zusammengefasster Record altert und deshalb überwacht gehört, und beides setzt voraus, dass wir das Original kennen.
Wie oft muss ich den Record erneuern?
Es gibt keine feste Frist, weil es von deinen Anbietern abhängt. Große Anbieter ändern ihre Bereiche selten, aber sie tun es. Als Faustregel: nach jeder Änderung an deinem Versand sofort, sonst alle paar Monate. Das Werkzeug zeigt dir beim erneuten Zusammenfassen, welche Bereiche neu sind und welche weggefallen sind, damit du nicht raten musst.
Was passiert, wenn ein Anbieter neue IP-Bereiche in Betrieb nimmt?
Dein Record weist deren Mail ab, so als käme sie von einem Fremden. Das ist der Preis dieser Optimierung und der Grund, warum sie nicht für jeden die richtige Wahl ist. Es taucht nirgends ein Fehler auf: der Record ist syntaktisch einwandfrei, die Prüfung läuft sauber durch, nur das Ergebnis stimmt nicht mehr. Wer das nicht regelmäßig kontrollieren will, fährt mit weniger Includes besser als mit eingefrorenen Bereichen.
Warum bekomme ich mehrere Einträge statt einem?
Weil alles zusammen nicht in einen Record passt. RFC 7208 §3.4 empfiehlt, dass Name und Recordtext zusammen unter 450 Oktett bleiben, damit die DNS-Antwort in ein UDP-Paket passt. Darüber muss der Resolver auf TCP ausweichen, und wo das scheitert, gilt der Record als gar nicht vorhanden. Die Kette umgeht das: der erste Eintrag steht auf deiner Domain und verweist auf die übrigen. Geschnitten wird je Anbieter, damit eine Änderung bei einem von ihnen nicht alle Einträge verschiebt.
Kostet die Kette nicht wieder Lookups?
Ja, einen je Kettenglied. Das ist der Tausch: statt der Lookups deiner Anbieter, die du nicht kontrollierst und die tief verschachtelt sein können, zahlst du eine feste, überschaubare Zahl für deine eigenen Einträge. Wenn selbst das die zehn Lookups reißen würde, erzeugt das Werkzeug gar nichts, statt dir eine Lösung hinzulegen, die das Problem behält.
Warum werden a und mx nicht auch aufgelöst?
Weil sie auf deine eigene Infrastruktur zeigen. Eingefroren wären sie beim nächsten Serverumzug stillschweigend falsch, und zwar ausgerechnet für die Adressen, über die du selbst verfügst und die du deshalb am wenigsten im Blick hast. Sie kosten je einen Lookup, den man gut behalten kann, und wandern unverändert in den neuen Record.
Mein Record enthält exists: oder ptr, warum geht es nicht?
Diese Mechanismen treffen eine Aussage über die anfragende Adresse, nicht über eine feste Menge von Absendern. Es gibt keine Liste von IP-Bereichen, die dasselbe bedeutet. Sie einfach wegzulassen ergäbe einen Record, der weniger erlaubt als dein Original, und das würdest du erst an abgewiesener Mail merken. Deshalb lehnt das Werkzeug hier ab, statt etwas zu bauen, das ungefähr passt.
Ändert das Zusammenfassen meine Policy?
Nein. Der Qualifier Ihres all-Mechanismus bleibt unangetastet: aus ~all wird nicht heimlich -all. Die Kettenglieder enden zwar auf -all, das ist aber etwas anderes: sie werden nur über include: betreten, wo allein zählt, ob ein Mechanismus trifft. Die Entscheidung über nicht passende Mail fällt im ersten Eintrag, also dort, wo deine eigene Einstellung steht.