Sender Policy Framework (SPF) und Sender Rewrite Schema (SRS)

Um gefälschte Absender / Phishing Missbrauch zu verhindern, können sogenannte SPF-Recordsopen in new window (Sender Policy Framework) für eine Domain gesetzt werden. Im SPF-Record einer Domain wird definiert, welche Mail-Server/IP-Adressen die Erlaubnis haben, E-Mails über die absendende Domain zu verschicken. Onlime GmbH unterstützt den Eintrag solcher SPF-Einträge im DNS und SRS bei E-Mail-Weiterleitungen schon seit Jahren. Beachte dazu unsere Ankündigungen im Blog:

Wie soll ich einen SPF-Eintrag setzen?

Nehmen wir als Beispiel den Domainnamen deine-domain.ch.

Bei dieser Domain ist folgender SPF-Eintrag im DNS aktiv:

deine-domain.ch.	IN	TXT	"v=spf1 a mx include:spf.onlime.ch ~all"

Dieser DNS-Record kann vom Typ TXT oder auch SPF sein. In unserem Controlpanelopen in new window kann er unter DNS-Manager als TXT-Record überschrieben werden, z.B. indem du ihn von Softfail ~all auf (Hard)Fail -all umschaltest:

Dies beglaubigt nun die Mailserver von Onlime, mit Ihrer Absenderdomain @deine-domain.ch E-Mails zu versenden.

Die Beglaubigung dazu passiert nicht beim Ausgang der E-Mail, sondern erst beim Eingang des Empfänger-Mailservers, sprich z.B. beim Eingangs-Mailserver von Gmail oder GMX.

Dieser überprüft nun, ob der Mailserver, von welchem die E-Mail geliefert wird, auch wirklich dazu berechtigt ist. Das heisst, es wird die IP Adresse des Mailservers mit der IP Adresse im SPF-Record der Domain @deine-domain.ch vergleichen, durch obigen Eintrag also indirekt mit dem SPF-Record der Domain spf.onlime.ch (die Vorgabe für all unsere Kunden-Domains).

Schlägt der Vergleich nun fehl, so heisst das, dass dieser Mailserver, der die E-Mail soeben einliefern wollte, nicht dazu berechtigt ist. Die E-Mail wird also vom Empfänger-Mailserver abgelehnt, sofern im SPF-Record diese Regel klar definiert ist mit -all ("Fail", im Gegensatz zu "Softfail" ~all), quasi "alle anderen nicht". Damit kannst du für deine eigene Domain den Missbrauch von sog. Mail-forgings (gefälschte Absenderadresse) eindämmen.

Problematik bei Weiterleitungen

Bei Weiterleitungen wird der Weg der E-Mail länger, das heisst sie nimmt einen Umweg über den Server, bei dem die Weiterleitung eingerichtet ist.

Dies heisst nun, dass ein neuer Mailserver (nämlich der Mailserver, auf welchem die Weiterleitung eingerichtet ist) die E-Mail einliefert, und nicht mehr der Ausgangsserver des Absenders.

In dieser Konstellation haben wir das Problem, dass die Überprüfung fehlschlägt, weil die IP-Adresse des Weiterleitungsservers nicht im SPF-Record der Absender-Domain aufgeführt ist.

Ein konkretes Beispiel:

  • Absender: ihr.name@deine-domain.ch
  • Empfänger: hans.muster@example.com
  • Weiterleitung nach: hans.muster@gmx.net

Wenn die E-Mail beim Anbieter von example.com ankommt, ist der Absender immer noch eine @deine-domain.ch-Adresse, der Mailserver, der aber die E-Mail liefern möchte, ist example.com und entspricht nicht den SPF-Record-Restriktionen deiner Domain deine-domain.ch. In diesem Fall wird die E-Mail bei GMX abgelehnt. Dafür gibt es eine Lösung, die auf unserer Mailinfrastruktur implementiert ist. Lies weiter:

Was kann ich / mein Hoster gegen das Weiterleitungs-Problem tun?

Als Lösungsansätze bieten sich grundsätzlich folgende Massnahmen an:

  • Der SPF-Record wird "gelockert" indem z.B. der Qualifikator -all (Fail) durch den Qualifikator ~all (SoftFail) ausgetauscht wird oder man nimmt weitere Mailserver darin auf. Problematik hier: Woher weiss man, wer von seinen Empfängern alles mit Weiterleitungen arbeitet? Es ist quasi unmöglich, all diese aufzunehmen und der Aufwand zur ständigen Pflege wäre enorm. Ausserdem wird auf Basis von ~all (SoftFail) kein Empfangs-Mailserver die E-Mail filtern, was das ganze Konzept von SPF zunichte macht.

  • Der SPF-Record wird deaktiviert. Problematik hier: Das Problem würde dadurch wohl gelöst, der Record wurde aber ursprünglich eingerichtet um Phishing / Missbrauch zu vermeiden. Durch die Deaktivierung des Records würde auch dieser erwünschte Effekt wegfallen.

Die echte Lösung lautet SRSopen in new window (Sender Rewrite Schema)!

Der Weiterleitungs-Mailserver sollte die E-Mail mittels SRSopen in new window (Sender Rewrite Schema) umschreiben damit beim nächsten Einliefern die Überprüfung positiv ausfällt.

TIPP

Onlime setzt als Hoster auf die SRS-Lösung. Du brauchst dich also nicht selbst um die Umschreibung der Adresse zu kümmern wenn wir eine Mail für dich weiterleiten – das wird automatisch gemacht. Dies gilt aber nur wenn die Weiterleitung via unsere Mailserver geschieht.

Weitere Fragen

Welche Mailserver soll ich als Kunde für meinen SPF-record verwenden?

Du brauchst dich nicht um die IPs resp. Hostnames unserer Mailserver zu kümmern. Verwende einfach als Vorgabe den SPF-record unserer Domain spf.onlime.ch und trage exakt dies als TXT-record für deine Domain ein:

"v=spf1 a mx include:spf.onlime.ch -all"

ACHTUNG

Dieser TXT-record befindet sich bereits standardmässig in der DNS-zone deiner Domain. Wir haben aber vorsichtshalber ~all (Softfail) eingetragen

Du solltest diesen TXT-record durch den leicht modifizierten mit -all am Ende überschreiben, sobald du dir sicher bist, dass dieser SPF-record stimmt. Sprich: Verwende -all erst, wenn du dir sicher bist, dass du sämtliche E-Mails via Onlime versendest, resp. nachdem du zusätzliche externe Mailserver(-Dienste) in deinen SPF-Record aufgenommen hast (zusätzliche include:... Einträge).

Wie überprüfe ich meinen SPF-record?

Um einen SPF-Record auszulesen gibt es diverse Möglichkeiten wie beispielsweise mittels SPF Record Testing Toolsopen in new window.

oder über den dig-Befehl:

$ dig TXT deine-domain.ch

deine-domain.ch.	300	IN	TXT	"v=spf1 a mx include:spf.onlime.ch ~all"

Wie sich SPF-Records lesen lassen, findest du hieropen in new window.

include:spf.onlime.ch

Bitte verwende immer include:spf.onlime.ch in deinem SPF-record!

Bitte verwende NIE include:onlime.ch, da dieser SPF-Record nur für Onlime GmbH firmen-intern verwendet wird und einen zu grossen Netz-Range für unsere Kunden-Sites beinhaltet.

Zuletzt aktualisiert: