SPF-Eintrag erstellen: Schritt für Schritt

Die Arbeit an einem SPF-Eintrag liegt nicht im Schreiben, sondern im Sammeln. Die Zeile selbst ist in einer Minute getippt; vollständig wird sie erst, wenn wirklich jeder Weg bekannt ist, über den im Namen der Domain Mails hinausgehen.

Zuerst die vollständige Liste der Versender#

Ein SPF-Eintrag ist eine Erlaubnisliste, und jede Lücke darin trifft die eigenen Mails. Zu erfassen ist alles, was einliefert: der Postfachanbieter, das Newsletter-Werkzeug, das CRM, der Shop, das Rechnungs- und das Ticketsystem, Terminbuchungen, Überwachungsmeldungen von Servern und der Formularversand der eigenen Website.

Zwei Quellen helfen beim Zusammentragen. Die erste sind die laufenden Abonnements und Rechnungen: Was bezahlt wird, versendet meistens auch. Die zweite und deutlich zuverlässigere sind aggregierte DMARC-Berichte, die man mit p=none und einer rua-Adresse einige Wochen einsammelt, bevor man den Eintrag scharf stellt. Diese Berichte nennen die tatsächlichen Absender statt der erinnerten.

Jeder externe Dienst dokumentiert, was einzutragen ist. Übernommen wird der vom Anbieter genannte include-Ausdruck, niemals dessen IP-Adressen, denn die ändern sich ohne Ankündigung.

Den Eintrag zusammensetzen#

Der Eintrag ist ein TXT-Eintrag auf der Domain, deren Envelope-Adresse beim Versand verwendet wird. Er beginnt mit der Version, listet dann die Mechanismen durch Leerzeichen getrennt und endet mit all:

v=spf1 include:_spf.beispielanbieter.de include:versand.beispiel-dienst.de ip4:198.51.100.25 ~all

Es darf je Domain nur einen Eintrag mit v=spf1 geben. Kommt ein Dienst hinzu, wird ein weiteres include in die bestehende Zeile eingefügt, keine zweite Zeile angelegt.

Für die einzelnen Bausteine gilt: include bindet fremde Dienste ein. ip4 und ip6 decken eigene Server mit fester Adresse ab. a und mx gehören nur hinein, wenn der Webserver beziehungsweise die eingetragenen Mailserver tatsächlich selbst versenden; sonst kosten sie unnötig eine DNS-Abfrage. ptr bleibt draußen, es gilt als überholt.

Die Zahl der Abfragen ist der eigentliche Kostenfaktor: RFC 7208 erlaubt bei der Auswertung höchstens zehn DNS-Abfragen, und jedes include bringt die Abfragen der eingebundenen Domain mit. Wie man das nachzählt und was bei Überschreitung passiert, steht unter SPF-Eintrag prüfen.

Zwei Sonderfälle werden gern vergessen. Versendet eine Unterdomain mit eigener Envelope-Adresse, braucht sie einen eigenen Eintrag, denn geerbt wird nichts. Und Domains, über die gar nicht versendet wird, bekommen v=spf1 -all — das ist die kürzeste sinnvolle Regel überhaupt.

~all oder -all#

~all ist softfail: Der Empfänger nimmt die Mail in der Regel an und vermerkt den Fehlschlag. -all ist fail: Der Empfänger darf ablehnen. Beide Varianten sind zulässig, sie unterscheiden sich im Risiko der Übergangszeit.

Für den Start ist ~all die vernünftige Wahl. Es liefert über die Berichte dieselben Erkenntnisse wie -all, ohne dass ein vergessener Dienst gleich unsichtbar ausfällt. Sobald die Berichte über mehrere Wochen keine legitime Quelle mehr als Fehlschlag ausweisen, ist der Wechsel auf -all fällig.

?all und +all haben in einem produktiven Eintrag nichts zu suchen. Neutral heißt praktisch: keine Aussage.

Ein Argument gegen übereilte Härte sind Weiterleitungen. Reicht ein fremder Server eine Mail weiter, ohne den Envelope-Absender zu ersetzen, liefert er aus einer Adresse ein, die im SPF-Eintrag nicht steht — die Prüfung schlägt fehl, obwohl die Mail echt ist. Nur wo Absender-Umschreibung eingesetzt wird, ist das entschärft. Deshalb sollte DKIM parallel eingerichtet sein, bevor -all gesetzt wird.

Die Reihenfolge der Inbetriebnahme#

1. Liste vervollständigen. Erst danach lohnt der erste Tastendruck.

2. TTL des TXT-Eintrags kurz setzen, einige Stunden vor der Änderung. Dann wirken Korrekturen schnell statt über einen halben Tag.

3. Eintrag mit ~all veröffentlichen und unmittelbar danach direkt beim autoritativen Namensserver nachsehen, ob genau eine Zeile mit v=spf1 zurückkommt.

4. DMARC mit p=none und rua einrichten, falls noch nicht geschehen, und die Berichte auswerten.

5. Fehlende Dienste nachtragen, bis in den Berichten nur noch Fremde scheitern.

6. Auf -all wechseln und die TTL wieder heraufsetzen.

Warum SPF allein nicht reicht#

SPF prüft den Envelope-Absender aus dem SMTP-Befehl MAIL FROM, nicht den From-Header, den der Empfänger im Postfach sieht. Beide Angaben sind unabhängig voneinander. Wer eine eigene, sauber per SPF gedeckte Domain im Envelope verwendet, kann im sichtbaren From trotzdem eine fremde Adresse eintragen und ein einwandfreies spf=pass erzeugen.

DKIM setzt an anderer Stelle an: Es signiert Kopfzeilen und Inhalt kryptographisch, und die Signatur übersteht Weiterleitungen häufiger als SPF. DMARC verbindet beides mit dem sichtbaren Absender, indem es eine Übereinstimmung zwischen der Domain im From-Header und der von SPF geprüften oder der von DKIM signierten Domain verlangt — und festlegt, was bei Fehlschlag geschehen soll. Erst dieses Zusammenspiel schützt die Adresse, die der Empfänger tatsächlich liest.

Wer beim Aufräumen der Zone ohnehin gerade in den DNS-Einstellungen sitzt, prüft die übrigen Satzarten gleich mit: DNS-Eintrag prüfen. Für Verschlüsselung, Kopfzeilen und Konfiguration der Website selbst gibt es den Security-Scan.