Besser e-mailen mit SPF-Record

E-Mail ist unzuverlässig. Das kennt jeder: Die eigentlich erwünschte Nachricht wird als Spam ausgefiltert. Oder die Zustellung scheitert schon vorher und der empfangende Mailserver verweigert die Annahme. Mit der korrekten Einstellung des sog. SPF-Record in der Domain-Verwaltung lässt sich das Problem entschärfen.

Gefälschte Absender

Erst letzte Woche schilderte mir eine Kundin das Problem, dass jemand ungefragt E-Mails mit ihrer Absender-Adresse verschickt hatte. Das kann man sich ähnlich vorstellen wie bei der Post, wo man jeden beliebigen Absender auf die Postkarte schreiben kann und die wird dann ungeprüft zugestellt.

SPF-Record

Immer mehr E-Mail-Provider setzen das sog. Sender Policy Framework (SBF) ein, um gefälschte Absender-Adressen zu verhindern – vor allem zur Spam-Bekämpfung: E-Mails mit vermeintlich gefälschten Absenderadressen werden nicht zugestellt.

Mit dem sog. SPF-Record gibt der Domaininhaber an, von welchem Server aus E-Mail unter seiner Domain verschickt werden darf. Der empfangende E-Mail-Server kann nun nachschauen, ob der tatsächliche Absender mit dem im SPF-Record angegebenen übereinstimmt. Bei Wikipedia finden Sie eine detailliertere Beschreibung.

Ist für Ihre Domain ein SPF-Record gesetzt? Das können Sie z. B. hier online abfragen. Welche Einstellungen für Ihre Domain vorzunehmen sind erfahren Sie bei Ihrem E-Mail-Provider (z. B. HostEurope).

Probleme

Probleme gibt es vor allem beim Einsatz von E-Mail-Weiterleitungen und bei Web-Formularen wie sie auf Kanzleihomepages typischerweise als Kontaktformular eingesetzt werden. Hier ist besondere Sorgfalt geboten, damit neue Mandatsanfragen nicht im Nirvana landen.

In eigener Sache

Für meine eigene Domain hatte ich bisher keinen SPF-Record gesetzt. Das habe ich jetzt nachgeholt und bin gespannt, ob ich künftig tatsächlich weniger Probleme bei der E-Mail-Zustellung habe. Ich werde berichten.

 

 

1 Antwort
  1. Andreas
    Andreas says:

    SPF gibt es schon recht lange, aber die Probleme konnten bis heute nicht ausgeräumt werden, da das Dilemma hier systemimmanent ist. Wie du erwähnst ist eines das der E-Mail Weiterleitungen. Schlussendlich muss man sich entscheiden: Weiterleitungen ermöglichen _oder_ SPF nutzen. Ich habe SPF lange getestet und hatte alle Möglichkeiten, den Server zu konfigurieren. Damit viele Standardfälle funktionieren, muss man das Scheunentor schon weit aufmachen. Die Lösung bei Weiterleitungen (erst recht, wenn eine solche zum zweiten/mehrfachen Male geschieht), soll SRS sein. Nicht mal ein Internetstandard, vom Postfix Entwickler wegen Untauglichkeit nicht implementiert.

    Bei Problemen: die E-Mail kommt zurück mit einer Meldung zu SPF. Auch toll: ein Link zur Fehlersuche ist gleich dabei. Aber: die Analyse sagt aus, dass alles korrekt eingestellt ist (im DNS, im Client, im Mailserver) und _eigentlich_ die Mail zugestellt werden sollte. Fatal: der Sender erfährt davon nichts, denn diese Meldung bekommt nur der Systemadmin. Und wer nutzt gleichzeitig DMARC-Einträge im DNS?

    Auch die Formulare hast du angesprochen: der Admin etwa einer WordPress Domain gibt dort eine Versandadresse ein. Bestenfalls eine aus seinem Domainbereich. Jetzt sind solche Server meist virtuelle Server (viele verschiedene Domains laufen parallel), aber es gibt nur _einen_ Mailserver, der Domainname meist vorgegeben vom Provider des physischen Servers. Eine für dich interessante Frage: _Darf_ ein Kunde diesen Domainnamen überhaupt als legitimen Mailversandserver ins eigene DNS eintragen???

    Nicht weiter eingehen möchte ich auf Probleme bei Mailinglisten. Auch Fälschungen bleiben weiterhin möglich, da es verschieden ausgewertete „from“ Felder gibt und sich SPF nur auf eines bezieht.

    Es gab ein Treffen großer deutscher E-Mail Provider, von denen nur GMX/Web.de SPF einsetzten. Mittlerweile auch nur noch in einer weichgespülten Version, weil Kunden nicht mal mehr sich selbst E-Mails senden konnten.

    Das ganze wird auch schnell komplex. Technische Details z. B. hier:
    https://i-mscp.net/index.php/Thread/17529-Mail-bounced-after-forward-although-SPF-rules-confirm-sending-rights/

    Grundsätzlich wäre SPF eine interessante Lösung. Aber die Architektur des E-Mailverkehrs lässt das nicht zu. Es gibt zum Glück andere, bessere Lösungen. Und es bleiben Nischenanwendungen. Z. B., wenn ich absolut ausschließen möchte, dass im Namen eines Servers, etwa einer intern genutzten Subdomain _überhaupt_ Mails versendet werden. Auch, wenn die genannten Problemfelder im eigenen Fall nicht einschlägig sind, ist es eine gute Lösung.

    Bei mir wird SPF deshalb nicht mehr installiert.

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.