SPF: zu viele DNS-Abfragen, so zählen und beheben Sie permerror

Ihr SPF-Record sieht gut aus, jeder Absender, den Sie nutzen, ist aufgeführt, und doch meldet eines Tages ein DMARC-Bericht oder ein Bounce permerror. Die übliche Ursache ist das Limit von 10 DNS-Abfragen: SPF darf bei der Auswertung nur eine feste Zahl an DNS-Abfragen auslösen, und jedes Tool, das Sie mit einem include: hinzufügen, verbraucht einen Teil dieses Budgets. Dieser Leitfaden zeigt, wie Sie Ihre Abfragen zählen, welche Terme eine Abfrage kosten und welche gratis sind und in welcher Reihenfolge Sie einen Record über dem Limit reparieren, ohne die E-Mails eines vergessenen Absenders zu brechen.

Die kurze Antwort#

SPF ist in RFC 7208 definiert, und dieser verlangt, dass eine Implementierung die Terme, die DNS-Abfragen auslösen, bei der Auswertung auf 10 begrenzen muss. Es zählen die Terme include, a, mx, ptr, exists und der Modifier redirect. Terme ohne Abfrage, ip4, ip6 und all, sind kostenlos. Gezählt wird rekursiv: Ein include: kostet eine Abfrage plus alles, was im Record steht, auf den es verweist. Überschreiten Sie 10, liefert die Prüfung permerror, was bedeutet, dass SPF für keine E-Mail der Domain besteht. Zur Lösung löschen Sie Includes für Tools, die Sie nicht mehr nutzen, ersetzen dann, was möglich ist, durch ip4/ip6 für stabile Server und verlagern danach Massenversender auf eine Subdomain. Flatten Sie nur als letzten Ausweg. Der kostenlose SPF-, DKIM- und DMARC-Checker und die Domain-Zustandsprüfung zeigen den von Ihnen veröffentlichten Record, folgen aber keinen Includes und zählen keine Abfragen. Sie zählen also von Hand wie unten beschrieben oder nutzen ein Tool, das rekursiv auflöst.

Was zum Limit zählt#

Ein konkretes Beispiel zeigt, wie schnell es sich summiert.

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net mx a ~all"

Dieser Record hat auf oberster Ebene sechs Terme, die Abfragen kosten, und jedes include: kann im Inneren weitere Terme enthalten. Die sichtbare Zahl ist 6, die tatsächliche Zahl ist, was die verschachtelten Records hinzufügen. Deshalb kann ein kurz wirkender Record über dem Limit liegen, und deshalb ändert sich die Zahl, ohne dass Sie Ihr DNS anfassen: Ein Anbieter bearbeitet seinen eigenen SPF-Record, und Ihre Summe verschiebt sich.

Der RFC sagt außerdem, dass Implementierungen „Void Lookups“, also Abfragen ohne Ergebnis, auf zwei begrenzen sollten. Das ist eine Empfehlung und keine harte Anforderung, aber ein include:-, a- oder mx-Term, der auf einen nicht mehr existierenden Namen zeigt, ist genau eine solche Abfrage. Es ist ein weiterer Grund, tote Includes zuerst zu entfernen.

Schritt 1: Bestätigen Sie, dass es ein Zählproblem ist#

Schließen Sie vor jeder Änderung die anderen Ursachen eines SPF-Fehlers aus.

1. Mehr als ein SPF-Record. Zwei v=spf1-TXT-Records am selben Namen sind ebenfalls ein permanenter Fehler, und das passiert leicht aus Versehen, wenn die Einrichtungsseite eines Tools sagt, Sie sollten einen Record hinzufügen. Führen Sie dig +short TXT example.com aus und zählen Sie die Zeilen, die mit v=spf1 beginnen. Finden Sie zwei, führen Sie sie zusammen. Wenn SPF, DKIM und DMARC nicht mehr funktionieren behandelt das und die anderen üblichen Ursachen.
2. Ein Syntaxfehler. Ein Tippfehler wie include ohne Domain, ein ungültiger ip4-Bereich oder ein fehlendes Leerzeichen bricht den Record.
3. Ein zirkuläres Include. Zwei Domains, die sich gegenseitig einbinden, werden nie fertig ausgewertet.
4. Ein Include, das ins Leere zeigt. Die Zieldomain veröffentlicht überhaupt keinen SPF-Record.

Trifft nichts davon zu, zählen Sie die Abfragen. Tun Sie es einmal von Hand, damit Sie den Baum verstehen: Fragen Sie den Record der obersten Ebene ab, listen Sie jeden Term auf, der eine Abfrage kostet, fragen Sie dann jedes include:- und redirect=-Ziel ab und wiederholen Sie das. Ein Tool, das Includes folgt, übernimmt die Rekursion und lohnt sich, denn ein verschachtelter Anbieter-Record kann mehrere Ebenen tief sein. Die kostenlosen Checker auf dieser Seite lesen den Record, zählen aber nicht.

Schritt 2: Entfernen Sie, was Sie nicht mehr nutzen#

Das ist die günstigste Lösung und bringt meist mehrere Abfragen zurück. Gehen Sie jedes include: durch und fragen Sie, ob noch etwas darüber sendet.

• Testtools. Dienste, die Sie einen Monat lang ausprobiert und nie entfernt haben.
• Abgelöste Plattformen. Das Marketing-Tool, das Sie vor zwei Jahren ersetzt haben, oder der alte Helpdesk.
• Anbieter, die Sie nur anhand des Includes benennen können. Wenn Sie nicht sagen können, was es ist, finden Sie es heraus, bevor Sie löschen. DMARC-Aggregatberichte zeigen, welche Quellen tatsächlich als Ihre Domain gesendet haben, ein Include, das in einem Monat Berichte nie auftaucht, ist also ein guter Kandidat.

Löschen Sie eines nach dem anderen, zählen Sie neu und bewahren Sie den alten Record-Text auf, damit Sie zurückrollen können. Entfernen Sie außerdem bloße mx- und a-Terme, sofern Sie nicht wirklich von diesen Hosts senden, und ptr vollständig.

Schritt 3: Ersetzen Sie Includes vorsichtig durch IP-Bereiche#

Bei einem Absender mit einer kleinen, stabilen Adressmenge, etwa Ihrem eigenen Mailserver, können Sie ein include: oder mx gegen ip4:-Einträge tauschen und so Abfragen sparen.

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com ~all

Der Preis ist der Pflegeaufwand. Ein ip4:-Eintrag ist das Versprechen, dass Sie bemerken, wenn sich die Adressen ändern. Tun Sie das nur für Infrastruktur, die Sie kontrollieren. Kopieren Sie niemals die lange IP-Liste eines großen ESP in Ihren Record: Anbieter nehmen Adressen hinzu und ab, ohne es Ihnen zu sagen, und Ihre Kopie veraltet unbemerkt.

Schritt 4: Verlagern Sie Massen- und Marketing-Absender auf eine Subdomain#

Jede Versanddomain hat ihren eigenen SPF-Record und ihr eigenes Budget. Senden Ihre Marketing-Plattform, Ihr Transaktionsdienst und Ihr Support-Desk alle als example.com, teilen sie sich ein Budget von 10. Geben Sie dem Newsletter eine Subdomain wie news.example.com, veröffentlichen Sie dort einen kurzen SPF-Record und stellen Sie die Plattform so ein, dass sie sie für Return-Path und From-Adresse verwendet. Das trennt auch die Reputation, was der Leitfaden zur Versand-Subdomain ausführlich erklärt.

Behalten Sie dabei DMARC im Blick. Das Alignment vergleicht die From-Domain mit der Domain, die SPF oder DKIM bestanden hat. Relaxed Alignment lässt news.example.com mit example.com übereinstimmen, aber der Absender muss sich weiterhin unter einer dieser Domains authentifizieren. DMARC einrichten behandelt das Alignment.

Schritt 5: Flattening und warum es veraltet#

Flattening bedeutet, include:-Terme durch die tatsächlichen IP-Adressen zu ersetzen, auf die sie auflösen, sodass der Record keine Abfragen braucht. Es funktioniert, und es ist zugleich die riskanteste Lösung, denn das Include existiert genau dazu, dass der Anbieter Adressen ändern kann, ohne dass Sie das DNS bearbeiten. Ein geflatteter Record friert die Adressen zum Zeitpunkt des Erstellens ein. Fügt der Anbieter einen Server hinzu, scheitert die E-Mail von dort an SPF, bis jemand Ihren Record aktualisiert.

Zwei weitere Grenzen gelten. Ein geflatteter Record kann über die Größe hinauswachsen, die ein einzelner TXT-Record bequem fasst, und DNS begrenzt eine UDP-Antwort, sodass große Records aufgeteilt oder sorgfältig ausgeliefert werden müssen. Und Sie besitzen nun einen Aktualisierungsjob. Wenn Sie flatten, tun Sie es mit einem Dienst oder Skript, das nach Zeitplan neu auflöst und Sie bei Fehlern alarmiert, niemals als einmaliges Copy-and-paste.

Für die meisten Domains genügt die obige Reihenfolge. Erst löschen, dann Subdomain, dann ip4, zuletzt flatten.

Die Zahl unter Kontrolle halten#

Die Abfragezahl ist nicht fest. Sie bewegt sich, wenn Sie ein Tool hinzufügen und wenn ein Anbieter seinen eigenen Record bearbeitet, sodass ein Record, der im März bestand, im September ohne Änderung von Ihnen scheitern kann. Drei Gewohnheiten halten Sie vorn.

• Zählen Sie vor dem Hinzufügen. Prüfen Sie die Summe, bevor Sie ein Include ergänzen, damit Sie wissen, ob der neue Absender hineinpasst.
• Prüfen Sie nach Zeitplan neu. Domain-Zustandsprüfungen berechnen die rekursive Zahl jedes Mal neu.
• Alarmieren Sie bei 9, nicht bei 11. Wenn die Zahl über 10 liegt, scheitern Sie bereits.

Die Domain-Zustand-Überwachung übernimmt die letzten beiden. Jede abgedeckte Domain erhält eine tägliche SPF-Prüfung, die Includes und Redirects folgt und Abfragen so zählt, wie es RFC 7208 Abschnitt 4.6.4 beschreibt. Sie gibt bei 9 oder 10 Abfragen eine Warnung und über 10 ein Problem mit Schweregrad „bad“ aus und benachrichtigt Sie per E-Mail. Sie markiert auch die anderen SPF-Probleme aus Schritt 1: mehrere Records, Syntaxfehler, ein Include, das keinen Record veröffentlicht, ein Abschluss mit +all oder ?all und den ptr-Mechanismus. Eine Grenze sollten Sie kennen: Jeder Bericht hat ein Budget von 40 DNS-Abfragen pro Domain, sodass bei einem sehr großen Record einige Punkte als nicht geprüft erscheinen und die Zahl eine Untergrenze ist. Warum sich mehr als nur SPF zu prüfen lohnt, steht in E-Mail-Domain-Zustand überwachen, und die anbieterspezifischen SPF-Anleitungen zeigen, was jeder Absender zu Ihrer Zahl beiträgt.

SPF sagt nur, welche Server als Sie senden dürfen, und kann nicht sagen, ob die Menschen auf Ihrer Liste Ihre E-Mails wollen oder überhaupt existieren. Die 100 kostenlosen Credits auf der Preisseite führen die vollständige Verifizierung für eine Liste durch, sodass Sie sehen, wie viele Adressen bouncen würden. Ein Record, der SPF besteht, braucht weiterhin eine gesunde Liste, um den Posteingang zu erreichen.