SPF-Record-Checker

Was ein SPF-Eintrag bewirkt

SPF (Sender Policy Framework) erlaubt einer Domain, im DNS die Liste der Server zu veröffentlichen, die für sie E-Mails senden dürfen. Trifft eine Nachricht ein, betrachtet der empfangende Server die Domain im Envelope-Absender (dem Return-Path, auch MAIL FROM genannt) und liest den SPF-Eintrag dieser Domain. Steht die verbindende IP-Adresse auf der Liste, besteht SPF. Wenn nicht, legt der Eintrag fest, was der Empfänger tun soll.

SPF betrachtet nicht die From-Adresse, die Ihre Empfänger sehen. Deshalb kann eine Nachricht SPF bestehen und trotzdem bei DMARC durchfallen: Die beiden Domains müssen übereinstimmen, und SPF allein sorgt nicht dafür.

So lesen Sie den Eintrag

Ein SPF-Eintrag ist eine einzelne Textzeile, die mit v=spf1 beginnt und aus Begriffen besteht, die von links nach rechts gelesen werden. Der erste Begriff, der auf die sendende IP passt, entscheidet das Ergebnis.

Das Limit von 10 DNS-Abfragen

Der SPF-Standard (RFC 7208) erlaubt einem Empfänger höchstens zehn DNS-Abfragen bei der Auswertung eines Eintrags. Die Begriffe include, a, mx, ptr, exists und redirect zählen jeweils, ebenso jede Abfrage innerhalb eines eingebundenen Eintrags. Wird die Zehn überschritten, ist das Ergebnis ein dauerhafter Fehler, den Empfänger als Fehlschlag werten.

Meist liegt es am Stapeln mehrerer E-Mail-Dienste: Eine Marketingplattform, ein Helpdesk, ein CRM und ein Mailanbieter können zusammen den Großteil des Budgets verbrauchen. Der Checker folgt jedem include wie ein Empfänger und zeigt die Zahl gegenüber dem Limit, sodass Sie sehen, welcher Zweig teuer ist.

Der Standard begrenzt außerdem „Void“-Abfragen (Namen, die nichts zurückliefern) auf zwei. Ein include, das auf eine Domain ohne SPF-Eintrag verweist, wird deshalb als Problem gezählt.

Lösungen, die funktionieren: Entfernen Sie Dienste, die Sie nicht mehr nutzen, ersetzen Sie a-, mx- und include-Begriffe durch ip4- und ip6-Bereiche, wo der Anbieter stabile veröffentlicht, und senden Sie verschiedene Mailarten von verschiedenen Subdomains, sodass jede einen eigenen Eintrag hat.

Fehler, die der Checker markiert

Dies sind die Probleme, die wir am häufigsten sehen. Der Checker meldet jedes davon mit einer verständlichen Lösung.

• Mehr als ein SPF-Record auf derselben Domain. Empfänger werten das als Fehler. Führen Sie die Records daher zu einem zusammen.
• Ein Record, der auf +all endet, oder auf ?all bei einer Domain, die echte Mails versendet. +all autorisiert jeden Server im Internet.
• Gar kein all-Term, wodurch das Ergebnis für nicht aufgeführte Server undefiniert bleibt.
• Ein Tippfehler in einem Mechanismus-Namen oder einer IP-Adresse, der den gesamten Record ungültig macht.
• Ein include, das auf eine Domain ohne SPF-Record zeigt, oder eine Schleife, in der zwei Records einander einbinden.
• Der ptr-Mechanismus, der langsam, unzuverlässig und veraltet ist.
• Ein Record mit mehr als 255 Zeichen, der als ein einziger String eingefügt wurde, oder einer, der nicht mehr in eine einzelne DNS-Antwort passt.

Was bestandenes SPF Ihnen nicht sagt

Ein sauberer Record bedeutet, dass die Richtlinie korrekt aufgebaut ist. Er beweist nicht, dass eine bestimmte Nachricht bestanden hat. Um eine echte Nachricht zu testen, öffnen Sie deren Header und lesen die Zeile Authentication-Results, oder fügen Sie sie in unseren E-Mail-Header-Analyzer ein.

SPF bricht auch bei weitergeleiteten Mails, weil die IP des weiterleitenden Servers nicht in Ihrem Record steht. Das ist einer der Gründe, warum DMARC entweder SPF oder DKIM akzeptiert und warum Sie Ihre Mails zusätzlich mit DKIM signieren sollten.

Soft Fail oder Hard Fail?

Sowohl ~all (Soft Fail) als auch -all (Hard Fail) teilen dem Empfänger mit, dass der Absender nicht autorisiert war. In der Praxis nutzen die meisten Empfänger SPF als eines von mehreren Signalen und treffen eine eigene Bewertung. Was mit fehlgeschlagenen Mails geschieht, entscheidet DMARC. Viele Organisationen veröffentlichen ~all, solange sie noch alle ihre Absender ermitteln, und wechseln zu -all, sobald die Liste vollständig ist. Beides ist akzeptabel, +all und ein fehlendes all sind es nicht.