SPF im Detail – korrektes einrichten von SPF-Records

In unserem Thema des Monats Oktober ’16 hatten wir bereits eine Einführung über SPF-Records und ihre Funktion gegeben. Hier eine kurze Zusammenfassung:

SPF steht für Sender Policy Framework und das System soll massgeblich vor Spam E-Mails schützen. Hierfür wird ein TXT-Eintrag im DNS der Domain gesetzt. Über diesen werden die IPs bzw. Domainnamen aufgelistet, die zum Versand von dieser Domain aus berechtigt sind. Zusätzlich zu SPF gibt es auch noch ein weiteres System namens DKIM, auf welches wir hier aber nicht näher eingehen werden.

Im Folgenden möchten wir nun das Sender Policy Framework genauer unter die Lupe nehmen.

Wie funktioniert SPF?

Das Sender Policy Framework ermöglicht es einem E-Mail-Empfänger die Authentizität des Absenders festzustellen. Dies gelingt, indem der empfangende Mailserver überprüft, von welchem Server die Mail versendet wurde. Diese Information wird mit der Domain des Absenders abgeglichen. In den DNS-Einstellungen dieser Domain können in einem extra hierfür angelegten Record alle Mailserver angegeben werden, die für den Mail-Versand von dieser Domain autorisiert sind. Ist der versendende Mailserver aufgelistet, wird die E-Mail akzeptiert.

Animierte Darstellung des Prozesses

Wie richte ich SPF für meine Domain ein?

Um E-Mails welche über die eigene Domain versendet werden zu authentifizieren, muss in den DNS-Einstellungen ein neuer Record erstellt werden. Für einige Zeit wurde empfohlen einen eigens hierfür eingesetzten DNS-Record-Typ SPF zu nutzen. Seit 2014 ist dieser aber wieder veraltet und SPF-Einträge werden einfach als TXT-Record gespeichert. Der Content eines solchen Records kann dann beispielsweise so aussehen:

"v=spf1 +a +mx include:_spf.google.com ~all"

Wir werden diesen nun Schritt für Schritt ansehen. Der erste Teil v=spf1 gibt einfach die genutzte SPF-Version an. Anschliessend folgen mehrere Hosts (a und mx), gekoppelt an Mechanismen (hier +). Folgende Mechanismen stehen hierbei zur Verfügung:

  • + (Pass) – Dieser Host darf Mails versenden. Wenn nichts genauer spezifiziert ist, wird dies als Default genutzt. +a und a ergeben also dasselbe.
  • – (Fail) – Dieser Host darf keine Mails versenden. Mails sollten nicht angenommen werden.
  • ~ (SoftFail) – Eine Mischung aus Fail und Neutral. Diese Mails werden typischerweise angenommen, aber als Spam markiert.
  • ? (Neutral) – Über diesen Host kann explizit nichts gesagt werden. Mails werden angenommen.

Als Host können folgende Optionen gewählt werden:

  • a – Der Host dieser Domain, also der eigene Server
  • mx – Die eingetragenen Mailserver
  • ptr – Subdomains der Domain
  • ip4 – Eine ausgewiesene ip4-Adresse
  • ip6 – Eine ausgewiesene ip6-Adresse
  • all – Alle Hosts (dies wird meistens zuletzt mit einem SoftFail verknüpft)
  • exists – Ein komplizierter Anwendungsfall, der sehr selten genutzt wird
  • include – Referenziert auf die SPF-Einträge einer anderen Domain

In unserem Beispiel oben erlauben wir also Mails vom Host selbst sowie den eingetragenen Mailservern. Zusätzlich wird die Policy von Google eingebunden. Dies wird beispielsweise genutzt, wenn Google Mailserver über Apps for Work genutzt werden. Abschliessend werden durch das ~all alle weiteren Hosts als SoftFail ausgegeben. Die Syntax kann noch detaillierter auf der Website openspf.org nachgelesen werden. Es wird darauf hingewiesen, dass der Content des TXT-Records in „“ gesetzt sein sollte, da sonst durch Leerzeichen getrennte Statements einzeln verarbeitet werden und folglich keinen Sinn mehr ergeben.

Wichtig ist auch, dass immer nur ein solcher TXT-Record vorhanden sein sollte. Alle Statements sollten also zusammengefasst werden, anstatt mehrere Records zu erstellen.

Auf diese Weise kann grundsätzlich ein SPF-Record angelegt werden. Aber es gibt auch noch ein paar Sonderfälle, auf die wir kurz eingehen möchten.

Newsletter über die eigene Domain versenden

Wer ein Tool wie Mailchimp nutzt um regelmässige Newsletter zu versenden, der hat vermutlich bereits bemerkt, dass beim Absender darauf hingewiesen wird, dass diese Mail über einen Dritten versendet wurde. Bei Google sieht das zum Beispiel so aus:

Gmail informiert, dass die Mail über einen Dritten gesendet wude

Nähere Information hierzu bietet auch die Google Hilfe. Es ist jedoch auch möglich, den Newsletterdienst mit der eigenen Domain zu verbinden. Hierbei kommt es aber nun zu Problemen, da der versendende Mailserver nicht im eigenen SPF-Record erwähnt ist. Hierfür kann einfach die SPF-Policy des Newsletterdienstes mit eingebunden werden. Für Mailchimp wäre das dann:

"v=spf1 include:servers.mcsv.net ~all"

Wenn bereits ein SPF-Record besteht, wird diesem einfach das include:servers.mcsv.net hinzugefügt. Nun kann die eigenen Domain als Absender der E-Mail genutzt werden.

Nach Anpassen des SPF Records, kann die eigenen Domain als Absender eingetragen werden

SPF und Content Delivery Networks

Wer ein CDN wie Cloudflare nutzt, muss bei der Erstellung seines SPF-Records etwas genauer aufpassen. Die Domain löst in dem Fall nicht mehr auf die IP des eigenen Servers sondern auf einen Server des CDN auf, da Cloudflare die eigentliche IP bewusst verschleiert (mehr Info dazu in der Cloudflare FAQ). Das bedeutet, dass das Statement +a es zwar erlauben würde Mails vom CDN aus zu versenden, der eigene Server wäre aber nicht autorisiert. In diesem Fall muss also unbedingt auch explizit die IP des eigenen Servers mit angegeben werden:

"v=spf1 a ptr ip4:194.126.200.00 ~all"

Auf welche IP die eigene Domain auflöst kann ganz einfach im Terminal getestet werden. Der Befehl

$ ping eigene-domain.tld

zeigt von welchem Server die Antwort kommt*. In unserem Fall ist dies ein Server von Cloudflare anstatt unseres eigenen Servers. In diesem Fall muss die eigene IP also wie oben gezeigt autorisiert werden.

Mehr Info

Hier haben wir noch einmal weiterführende Informationen und Tools zum Thema SPF:

  • spf-record.de Hier kann man SPF-Records zu einer Domain anzeigen oder auch mit Hilfe eines kleinen Tools generieren lassen – sehr praktisch!
  • openspf.org Hier noch einmal die gesamte Syntax für alle, die es genauer wissen möchten
  • mxtoolbox.com Mit der MX Toolbox können Mailserver für eine Domain überprüft werden. Neben fehlenden SPF-Einträgen können hier noch eine ganze Menge anderer Fehler und Probleme erkannt werden

 

* Das $ ist nicht Teil des Befehls sondern zeigt, dass dies in der Konsole eingegeben wird

Ein Kommentar zu “SPF im Detail – korrektes einrichten von SPF-Records

  1. Pingback: Empfangsprobleme bei internen E-Mails? | k-webs tech blog

Schreiben Sie einen Kommentar

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