SPF-Lookup-Limit senken — den Record umbauen statt aufweichen

Zuerst messen, nicht schätzen

Im eigenen Record stehen vielleicht drei include: — in der Auflösung werden daraus schnell zwölf Abfragen, weil jeder Anbieter selbst wieder verschachtelt. Gezählt werden include, a, mx, ptr, exists und redirect, rekursiv. Nicht gezählt werden ip4: und ip6: — sie kosten null.

Der SPF-Check löst die Kette vollständig auf und zeigt die Summe samt Aufschlüsselung je Zweig. Ohne diese Zahl ist jeder Umbau Raten.

Weg 1 — aufräumen

Der billigste und mit Abstand häufigste Gewinn. In fast jedem gewachsenen Record steht mindestens ein Dienst, der seit Jahren nicht mehr sendet: das abgelöste Newsletter-Tool, die Testumgebung, der ehemalige Hoster. Die DMARC-Reports zeigen schwarz auf weiß, welche Quellen tatsächlich noch Nachrichten produzieren. Was dort seit Wochen mit count 0 fehlt, kann raus.

Weg 2 — Mechanismen ersetzen

• a und mx kosten je einen Lookup und lösen meist auf eine Handvoll fester Adressen auf. Als ip4: eingetragen kosten sie nichts. Der Preis: Ändert sich die Adresse, musst du es selbst mitbekommen.
• ptr ersatzlos streichen. RFC 7208 rät ausdrücklich davon ab, und viele Empfänger werten es ohnehin nicht mehr aus.
• Kleine include: auflösen. Hat ein Anbieter nur zwei feste IPs, ersetze das include: durch die IPs. Bei großen Anbietern ist das der falsche Weg — siehe unten.

Weg 3 — auf Subdomains verteilen

Der sauberste Weg, wenn wirklich viele Systeme senden. Jede Versandart bekommt eine eigene Subdomain mit eigenem Record und eigenem Lookup-Budget:

Der Newsletter versendet dann als news@mail.deinedomain.de. Das ist kein Trick, sondern gute Praxis: Die Reputation des Werbeversands bleibt von der des Geschäftsverkehrs getrennt, und ein Zwischenfall beim einen trifft den anderen nicht. Denk daran, dass sp= in der DMARC-Policy für die Subdomains gilt.

Weg 4 — auflösen („Flattening“)

Die include:-Ketten werden aufgelöst und ihre IPs fest in den eigenen Record geschrieben. Das senkt die Zahl auf null Lookups und ist deshalb verlockend. Die Kosten sind real:

• Der Record veraltet still. Ändert der Anbieter seine Adressen, besteht SPF plötzlich nicht mehr — ohne Vorwarnung und ohne dass sich bei dir etwas geändert hätte.
• Er wird lang. Ein einzelner TXT-String fasst 255 Zeichen; längere Records werden in mehrere Strings zerlegt. Das ist zulässig, aber jeder Resolver-Fehler dabei zerlegt einen Mechanismus.
• Es braucht Automatik. Von Hand geflattete Records sind nach einem halben Jahr falsch. Wer flattet, braucht einen Prozess, der täglich neu auflöst und den Record aktualisiert.

Vertretbar ist das bei kleinen, stabilen Anbietern. Bei großen Cloud-Anbietern, die ihre Adressbereiche laufend anpassen, ist es die schlechteste der vier Möglichkeiten.

Was du nicht tun solltest

-all auf ~all oder ?all zurückzustellen macht die Fehlermeldung nicht weg — ein Record über dem Limit ist unabhängig vom Qualifier ungültig. Es schwächt nur den Schutz. Dasselbe gilt für das Streichen legitimer Absender: Sie fehlen dann im Record und fallen bei durchgesetztem DMARC aus.

Wie sich das Symptom im Postfach zeigt, steht bei SPF permerror — too many DNS lookups.