SPF-Records beim E-Mail-Versand

Wer sich mit Mailservern beschäftigt, stößt immer wieder auf die Schlagwörter SPF, DKIM, DMARC und MTA-STS. Mit dieser Blog-Serie möchte ich etwas Licht ins Dunkel bringen. Alle genannten Methoden dienen dazu, dass der Empfänger überprüfen kann, ob der Absender der E-Mail authorisiert ist, E-Mails mit dieser Domain zu versenden.

Cyber-Sicherheit rückt immer mehr in den Fokus der Unternehmen. Eine Vielzahl von Sicherheitsrisiken, wie z.B. E-Mail-Spoofing, Phishing Mails und SPAM, zielen auf die Gewinnung von Daten, den Zugriff auf Netzwerke usw. ab. Die Folge ist ein Reputations- und Datenverlust. E-Mails zählen dabei zu den einfachsten Angriffswegen. Der erste Teil meiner Blog-Serie beschäftigt sich daher mit dem Sender Policy Framework kurz SPF genannt

Definition SPF

SPF ist eine Validierungstechnik, bei der der empfangende Mail-Transfer-Agent erkennen kann, ob das sendende System für die Domain zugelassen ist. Autorisierte IP-Adressen für eine Domain werden dabei in einem DNS-Eintrag für diese Domain veröffentlicht. Wenn ein Mail-Transfer-Agent versucht, eine Nachricht zu versenden, führt der Empfängerserver eine DNS-Abfrage für die sendenden Domäne durch. Hierbei wird die Domain aus dem RFC5321.MailFrom Feld genutzt, um festzustellen, ob ein SPF-Eintrag vorhanden ist - dies wird als “Authentifizierung” bezeichnet.

Der Mail-Transfer-Agent stellt die E-Mail aufgrund der Authentifizierungsergebnisse ggfs. an den Empfänger zu. Das Ergebnis der Authentifizierung kann dabei drei Formen annehmen: Pass, Neutral oder Fail.

• Pass bedeutet, dass der Mailserver die Nachricht als legitim akzeptiert und ihre Zustellung zulässt.
• Neutral bedeutet, dass es für diese Domäne im DNS entweder gar keinen oder einen ungültigen Eintrag gibt, so dass nicht festgestellt werden kann, ob es sich um eine legitime Nachricht von dieser Domäne handelt oder nicht.
• Fail bedeutet, dass etwas an dieser Nachricht nicht authentisch genug war, um zugestellt zu werden.

Die RFC5321.MailFrom Adresse ist die Entität, die bei der SMTP-Kommunikation als Teil des Mail-From Befehls weitergegeben wird. Diese Adresse wird auch als “Umschlagadresse”, “ReturnPath”-Adresse oder SPF-Adresse bezeichnet.

Was ist ein SPF-Record?

Als SPF-Record wird ein TXT-Record in der DNS-Zone der Domain bezeichnet, der alle autorisierten Mailserver für diese Domain enthält.

Beim E-Mail-Spoofing werden die Headerzeilen einer E-Mail so angepasst, dass diese E-Mail scheinbar von einer “bekannten” Domain bzw. Absender gesendet wurde. Hierbei soll der Anwender meist dazu verleitet werden über entsprechende Links einen Schadcode auf seinen Client zu laden oder Informationen weiterzugeben. Diese E-Mails werden im Regelfall nicht über die für eine Domain autorisierten Mail-Transfer-Agents versendet.

Damit kann durch die Konfiguration eines SPF-Records, nicht nur die Zustellbarkeit der E-Mails für eine Domain verbessert werden, sondern auch die Reputation erhöht werden.

Wie ist ein SPF-Record aufgebaut?

Am Anfang des TXT-Records wird mit v= die verwendete SPF-Version angegeben, aktuell ist diese immer SPF1. Diese Version wurde 2014 in der RFC 7208 definiert. Auf diese Angabe erfolgt nun eine Zeichenfolge mit Mechanismen, Quantifizierern und den Modifizierern.

Mechanismen eines SPF-Records

Die Mechanismen beschreiben alle Hosts, welche als autorisierte Systeme für diese Domain genutzt werden.

• a: Angabe aller IP-Adressen (DNS A-Record), die für das Versenden autorisiert sind.
• ptr: Der ptr-Mechanismus verwendet den umgekehrten Hostnamen oder die Subdomain der sendenden IP-Adresse; sollte vermieden werden!
• ip4/ip6: Wird verwendet, um eine IP4 bzw. IP6 Adresse zu autorisieren.
  Beispiel: v=spf1 ip4:18.185.146.154 ip4:137.117.247.105 ~all
• mx: Angabe des MX-Records, dessen Host autorisiert werden soll.
  Beispiel: v=spf1 mx:spirit21.com ~all
• include: Verweist auf den SPF-Record einer anderen Domain, wenn diese gültig ist, ist auch dieser Mechanismus gültig.
  Beispiel: v=spf1 include:spf.protection.outlook.com
  - exits: Prüft, ob ein A-Eintrag für eine bestimmte Domäne gültig ist oder nicht. Dazu werden alle A-Einträge für diese Domäne überprüft. Wird selten verwendet, Einsatz bei DNSBL-Abfragen.
• all: Entspricht allen IP-Adressen und wird am Ende des SPF-Records angewendet. Hier ist ein Qualifizieren erforderlich.

Quantifizierer eines SPF-Records

Mechanismen besitzen einen Quantifizierer, der definiert wie bei einer Übereinstimmung vorgegangen werden soll. Der MTA vergleicht die IP-Adresse des sendenden Systems, mit den in der Liste der autorisierten IP-Adressen enthaltenen Einträge. Bei einer Übereinstimmung wird eine Regel für die Ergebnisbehandlung in Abhängigkeit des Qualifizieres angewendet. Die Standardregel, wenn nichts angegeben wurde, ist pass oder ‘+’.

Die möglichen Quantifizierer lauten wie folgt:

• +: Stellt das PASS-Ergebnis dar. Wenn die Adresse gefunden wurde, wird die Nachricht akzeptiert und in das Postfach zugestellt. Wird im Regelfall weggelassen, da +mx und mx identisch sind.
• -: Steht für HARDFAIL und gibt an, dass die Adresse nicht akzeptiert wird, und die Nachricht daher abgelehnt werden muss. Beispiel: v=spf1 mx:spirit21.com -all
• ~: Steht für SOFTFAIL. Die Nachricht wird nicht abgelehnt, soll aber entsprechend mit einem negativen Scoring in die SPAM-Filterung eingehen
• ?: Die IP-Adresse des sendenden Servers ist neutral. Daher kann das empfangende System entscheiden, ob es die E-Mail annimmt oder ablehnt.
  Wenn im SPF kein Quantifizieren angegeben wird, bedeutet das, dass der +all angewendet wird. Dies ist im Regelfall nicht gewünscht.

Wer braucht einen SPF-Record?

Durch einen SPF-Record für die eigene Domain wird in erster Linie die Reputation des eigenen Unternehmens geschützt. Es wird die Glaubwürdigkeit der eigenen Domain erhöht und damit verringert sich die Wahrscheinlichkeit, dass diese von SPAM-Filtern gelistet wird. Durch den SPF-Record sinkt die Wahrscheinlichkeit, dass SPAM-Mails mit dieser Domain bei einem Empfänger im Postfach landen. Möchte ein Unternehmen DMARC nutzen wollen, bildet unter anderem ein gültiger SDPF-Record die Grundlage dafür.

Wenn ein SPF-Record eingesetzt werden soll, sind die folgenden Schritte erforderlich

Schritt 1: Identifizierung der IP-Adressen, die E-Mails an Systeme über das Internet senden

Da in einem Unternehmen E-Mails meist von mehreren Systemen gesendet werden, müssen im ersten Schritt alle IP-Adressen der Systeme identifiziert werden. Dabei sind nicht nur die eigenen Systeme zu berücksichtigen, sondern auch Fremdsysteme, die E-Mails im Namen der Domain versenden. Dies können z.B. Newsletter-Dienste oder Agenturen sein.

Schritt 2: Aufstellung aller Domains, die das Unternehmen hat

Es ist für jede Domain, die das Unternehmen besitzt, ein entsprechender SPF-Record zu erstellen, auch wenn diese nicht selbst aktiv für den Mailversand genutzt wird. Ist dies nicht der Fall können Cyberkriminelle diese Domain fälschen und zum Versenden von E-Mails nutzen. Auch dadurch entsteht ein entsprechender Reputationsverlust für das Unternehmen.

Schritt 3: Erstellen und Veröffentlichen des SPF-Records

Nachdem für alle Domains die Systeme identifiziert wurden, wird für jede Domain ein entsprechender SPF-Record erstellt. Dieser muss dann in den DNS der jeweiligen Domain als TXT-Record eingetragen werden. Ein SPF-Record für Domains, die nicht zum E-Mailversand genutzt werden, sieht wie folgt aus: v=spf1 -all

Schritt 4: Testen des SPF-Records

Nachdem der SPF-Record erstellt und veröffentlich wurde, sollte dieser noch getestet werden. Dazu können verschiedene Tools genutzt werden.

• MXTOOLBOX SPF-Check
• DMARCADVISOR SPF-Check
• spfrecord

Diese Tools helfen dabei, die Gültigkeit eines SPF-Records sicherzustellen. Dazu werden mehrere Parameter geprüft:

• Vorhandensein des SPF-Records. Der Eintrag kann im DNS gefunden werden.
• Vermeidung mehrerer Einträge. Pro Domain ist nur ein einziger SPF-Record zulässig.
• Anzahl maximaler Suchvorgänge. Diese ist auf zehn beschränkt und muss bei den includes beachtet werden.
• Verwendung des PTR-Mechanismus. Da dies nicht empfohlen ist, weisen die Tools entsprechend darauf hin.

Welche Beschränkungen von SPF gibt es?

Durch die Nutzung eines SPF-Records ergeben sich Vorteile für die Zustellung von E-Mails. Es gibt aber auch Einschränkungen.

Header-Probleme

SPF wurde mit dem Ziel entwickelt, Angreifer daran zu hindern, die Absenderadresse der Mail zu fälschen. Beim Spoofing wird meist nur das “Von Feld” im Header der Mail verändert. Dies dient “nur” der Anzeige und wird nicht vom Mail-Transfer-Agent verarbeitet.

Weiterleitungen

Werden E-Mails z.B. weitgeleitet und ist im SPF-Record durch ‘-all’ der Empfang von allen nicht autorisierten Systeme abzulehnen, werden solche Mails dann nicht in das Empfängerpostfach zugestellt.

Absender können immer auch von anderen Mail-Transfer-Agents kommen. So können Mails

• von einem Benutzer aus seinem Postfach an ein Postfach bei einem anderen Provider weitergeleitet werden. Diese Weiterleitungen lassen im Regelfall den Absender (Envelope-From) unverändert.
• von einer Mailingsite an eine Vielzahl von Empfängern verteilt werden. In diesem Fall wird der Envelope-Empfänger in der Regel auf die Mailingliste zeigen, das Header-From jedoch unverändert sein.
• aus technischen Gründen oder durch Webforms von anderen Systemen gesendet werden.

Kann SPF vor Phishing schützen?

Eine E-Mail enthält an zwei Stellen die Absenderinformation, einmal für die Transportebene im Envelope-From und für den Empfänger im Header-From Feld. Da bei SPF nur der Envelope genutzt wird, und nicht zusätzlich der Header-Teil, kann SPF nicht vor Phishing schützen!

Zusammenfassung

Die Risiken für die Cyber-Security entwickeln sich ständig weiter. Mit Hilfe eines SPF-Records beim E-Mail-Versand kann der Missbrauch der eigenen Domain durch Spammer eingeschränkt werden. Jedoch bietet die Nutzung eines SPF-Records keinen vollständigen Schutz. Daher sollten Lösungen wie DKIM und DMARC zusammen mit SPF verwendet werden.

Mit der “Domain Keys Identified Mail” - kurz DKIM - steht eine Lösung zur Verfügung, die den Missbrauch von Absenderinformationen wirkungsvoll einschränkt und nebenbei sogar die Unverfälschtheit des Headers sicherstellt. Dazu mehr im nächsten Teil der Serie.