Was ist das Sender Policy Framework? SPF-E-Mail erklärt

Die Authentifizierungsmethode Sender Policy Framework (SPF) identifiziert die autorisierten Mailserver, die E-Mails im Namen einer bestimmten Domain versenden dürfen. Der SPF-Standard hilft dabei, offizielle E-Mail-Quellen einer Organisation zu identifizieren. Richtet eine Organisation SPF ein, unterstützt dies Internet Service Provider (ISPs), Anbieter von E-Mail-Sicherheitslösungen und andere E-Mail-Provider dabei, die E-Mail-Kommunikation der Organisation zu validieren und autorisierte Nachrichten von gefälschten E-Mails oder Phishing-Angriffen zu unterscheiden, die versuchen, sich als diese Domain auszugeben.

Dieser Artikel hilft Ihnen, Folgendes zu verstehen:

• Wie funktioniert das Sender Policy Framework?
• SPF einrichten
• Vorteile des Sender Policy Framework
• Einschränkungen des Sender Policy Framework
• FAQs zum Sender Policy Framework
• Fazit: SPF – ein entscheidender erster Schritt zur Beseitigung von Phishing

Wie funktioniert das Sender Policy Framework (SPF)?

SPF ermöglicht eine Form der E-Mail-Authentifizierung, die die von einer Organisation zum E-Mail-Versand autorisierten Domains und Internetprotokolladressen (IP-Adressen) definiert. SPF wird in den DNS-Einträgen beim Domain-Hosting-Anbieter der Organisation hinterlegt.

E-Mail-empfangende Server prüfen den E-Mail-Header auf die sendende Domain und führen anschließend eine DNS-Abfrage durch, um festzustellen, ob eine SPF-Datei existiert, die mit der sendenden Domain übereinstimmt. Stimmen die sendende Domain des SPF-Eintrags und die sendende Domain des E-Mail-Headers überein, besteht die E-Mail die SPF-Prüfung und kann an den Empfänger zugestellt werden. Existiert kein SPF-Eintrag oder stimmt die sendende Domain der E-Mail nicht mit den veröffentlichten DNS-Einträgen überein, kann die E-Mail abgewiesen oder in einen Spam-Ordner verschoben werden.

SPF-Grundlagen

Um zu verstehen, wie SPF funktioniert, ist es wichtig, die Struktur und Optionen der SPF-Datei zu kennen.

Grundlegende Struktur der SPF-Datei

Die Internet Engineering Task Force (IETF) veröffentlicht die vollständigen Informationen zu SPF und den zugehörigen Standards, die zuletzt 2014 aktualisiert wurden. Im Kern besteht die SPF-Datei aus einer einfachen .txt-Datei, die in den DNS-Eintrag beim Domain-Hosting-Anbieter der Organisation hochgeladen wird. Wichtig ist außerdem, dass SPF-Einträge nicht mehr als 10 Tags oder 255 Zeichen enthalten dürfen, was für größere Organisationen zu erheblichen Einschränkungen führen kann.

Optionen der SPF-Datei

Die grundlegende Dateistruktur verwendet folgende Syntax:

<version> <IP4 and/or IP6 address> <include: domain> <all tag>

• Version ist immer „v=spf1“, da alle anderen SPF-Versionen eingestellt wurden
• IP-Adresse
• • Kann entweder die IP4- oder die IP6-Adresse für IP-Adressen sein, die zum Versand von E-Mails im Namen der Domain autorisiert sind
  • Verwendet das Format ip4:<ip4-address>, ip4:<ip4-network>/<prefix-length>, ip6:<ip6-address>, ip6:<ip6-network>/<prefix-length>
  • Für die Präfixlänge wird bei IP4 /32 und bei IP6 /128 angenommen; IP4-Präfixlängen unter /16 sollten vermieden werden, um kleinere Empfänger nicht zu beeinträchtigen
• Include verwendet die Syntax „include:senderdomain.net“, wobei senderdomain.net die Domain eines Drittanbieters ist, der zum Versand von E-Mails im Namen der Organisation autorisiert ist; wird dem Befehl ein „?“ vorangestellt, werden E-Mails bei einer Übereinstimmung mit der sendenden Domain als neutral statt als bestanden gekennzeichnet
• Alle Tags geben anderen Servern Empfehlungen, wie sie mit E-Mails umgehen sollen, die eine SPF-Prüfung nicht bestehen:
• • -all = E-Mails abweisen, die die SPF-Prüfung nicht bestehen
  • ~all = E-Mails, die die SPF-Prüfung nicht bestehen, als verdächtig kennzeichnen
  • ?all = Der Empfängerserver kann selbst bestimmen, wie mit E-Mails verfahren wird, die die SPF-Prüfung nicht bestehen
  • +all = jeder Domain erlauben, E-Mails im Namen der Organisation zu versenden (nicht empfohlen)

Das Sender Policy Framework bietet viele weitere Optionen, deren Verwendung jedoch gefährlich sein kann. Organisationen, die diese Optionen einsetzen möchten, sollten eng mit ihren Anbietern und IT-Mitarbeitern zusammenarbeiten, um die korrekte Syntax und Verwendung sicherzustellen. Beispiele für fortgeschrittenere Optionen sind:

• Der Mechanismus „a“ stellt eine Domain oder Netzwerkadresse bereit, innerhalb derer alle Einträge auf Übereinstimmungen geprüft werden
• Der Mechanismus „mx“ stellt eine Liste von IP-Adressen für den Mailaustausch bereit
• „ptr“ wird von Organisationen verwendet, die allen ihren Servern den E-Mail-Versand erlauben; wird normalerweise nicht verwendet
• „exists“ führt eine Abfrage der Domain durch und sucht nach einer Übereinstimmung mit dem SPF-Eintrag

Verwandte E-Mail-Standards

SPF bietet eine Authentifizierung mit begrenztem Umfang. Eine robustere Lösung sollte zusätzlich die Autorisierungs-Frameworks DKIM und DMARC implementieren.

DKIM: DomainKeys Identified Mail (DKIM) ermöglicht es einer Organisation, E-Mails ihrer Domain mithilfe von Public-Key-Kryptografie digital zu signieren.

DMARC: Domain-based Message Authentication Reporting and Conformance (DMARC) ermöglicht eine direktere Kontrolle über E-Mails, die SPF oder DKIM nicht bestehen, und erlaubt die Berichterstattung über legitime und gefälschte E-Mails.

SPF einrichten

Das Sender Policy Framework (SPF) lässt sich einfach einrichten und konfigurieren. In seiner grundlegendsten Form erfordert SPF lediglich eine einfache einzeilige Änderung an einem Domain-Eintrag. Bei vielen Hosting-Unternehmen führen Sie beispielsweise die folgenden Schritte aus:

1. Melden Sie sich beim Domain-Registrar an und klicken Sie auf die Option zum Verwalten oder Konfigurieren der DNS-Einstellungen
2. Suchen Sie die Option „Add a New Record“, klicken Sie darauf und wählen Sie einen „TXT“-Eintrag aus
3. Geben Sie im Dialogfeld für den Hostnamen entweder @ oder den Namen Ihrer Domain ein.
4. Kopieren Sie die SPF-Informationen in das Feld „value“, in dem die SPF-Optionen definiert werden

Obwohl dies theoretisch einfach ist, haben viele Organisationen spezielle Anforderungen, die zusätzliche Optionen oder Änderungen erfordern. Sowohl Google als auch Microsoft veröffentlichen beispielsweise konkrete Anweisungen dazu, wie Gmail- und Microsoft-365-Mailserver in SPF-Dateien aufgenommen werden. Nach dem Erstellen eines ersten SPF-Eintrags sollte die Organisation außerdem ihren Domain-Hosting-Anbieter und die verschiedenen Maildienste (z. B. HubSpot, Mailchimp) konsultieren, um sicherzustellen, dass der SPF-Eintrag korrekt erstellt und konfiguriert wurde.

Für Organisationen, die zusätzliche Unterstützung benötigen, gibt es zahlreiche Dienste, die im Auftrag der Organisation SPF erstellen und aktivieren können. Diese Dienste sind entweder als eigenständige Lösung oder als Paket mit der DMARC-Bereitstellung verfügbar.

SPF überprüfen und Fehler beheben

Nach der Implementierung von SPF kann es mehrere Tage dauern, bis sich der DNS-Eintrag im Internet verbreitet hat. Danach kann das Unternehmen E-Mails versenden und den Header der E-Mail auf „spf=pass“ prüfen.

Natürlich kann SPF leicht falsch implementiert werden. Treten Probleme auf, sollte die Organisation daher Folgendes überprüfen:

• Falsche Syntax wie zusätzliche Leerzeichen, Tippfehler usw.
• Mehr als 10 E-Mail-Absender, da dies Fehler verursacht. Hat eine Organisation mehr als 10 autorisierte sendende Domains, muss sie möglicherweise mehrere SPF-Einträge mithilfe von Subdomains einrichten.
• Mehr als 255 Zeichen zwischen sendenden Domains und optionalen Flags – diese sind ungültig, sodass der SPF-Eintrag gekürzt, korrigiert und erneut hinterlegt werden muss.
• Falsche Anbieterinformationen, die SPF-Fail-Bedingungen verursachen können. Arbeiten Sie mit dem Anbieter zusammen, um sicherzustellen, dass die Informationen im SPF-Eintrag die konkrete IP-Adresse oder Domain widerspiegeln, die zum Versand der E-Mails verwendet wird, und nicht etwa Bounceback-Domains, Website-URLs usw.
• Unnötige „a“- und „mx“-Einträge, da diese zu Verwirrung und Fehlern führen können: Statt die IP-Adresse des ausgehenden E-Mail-Servers abzubilden, verweist die „a“-Adresse normalerweise auf die IP-Adresse des Webhosts der Domain, während „mx“-Hosts typischerweise für eingehende E-Mails verwendet werden.

Anbieter von E-Mail-Authentifizierung wie dmarcian bieten kostenlose Tools an, die eine schnelle Analyse des SPF-Eintrags ermöglichen und Organisationen bei der Fehlerbehebung unterstützen.

Vorteile von SPF

Ein korrekt konfiguriertes SPF bietet zwei wesentliche konkrete Vorteile: die Eindämmung von Identitätsmissbrauch und eine verbesserte Domain-Reputation. Für die meisten Organisationen sollten diese Vorteile die zahlreicheren, aber geringfügigen Nachteile aufwiegen.

Eindämmung von Identitätsmissbrauch

Die als E-Mail-Spoofing bekannte Untergruppe von Phishing-Angriffen versucht, sich als legitime Organisationen auszugeben, um die Wahrscheinlichkeit zu erhöhen, einen Leser zu täuschen. Bei einem korrekt konfigurierten SPF wird es schwieriger, sich als die Organisation auszugeben.

Wenn ein Mailserver eine gefälschte E-Mail empfängt, vergleicht er die sendende IP-Adresse mit der SPF-Datei und weist die gefälschte E-Mail zurück, wenn sie nicht vom Mailserver der Organisation stammt. Dies schützt die Reputation des Unternehmens, indem Spam-E-Mails blockiert werden, die die Marke der Organisation missbrauchen wollen. Außerdem können Phishing-Angriffe blockiert werden, die versuchen, sich als Mitarbeiter der Organisation auszugeben – etwa wenn ein Phishing-Angriff den CEO imitiert.

Verbesserte Domain-Reputation

Richtet eine Organisation keinen SPF-Eintrag ein, können E-Mail-Server, die ihre E-Mails empfangen, diese markieren oder abweisen, weil die Authentizität der Domain der Organisation nicht überprüft werden kann. Die Einrichtung eines SPF-Eintrags verbessert die Reputation der Organisationsdomain und die Zustellrate legitimer E-Mails.

Einschränkungen des Sender Policy Framework

SPF schützt weltweit vor Spam, Spoofing und Phishing-E-Mails und stärkt die E-Mail-Sicherheit. Allerdings weist es auch zahlreiche, wenn auch eher geringfügige, Einschränkungen auf.

Schwierig zu pflegen

Organisationen müssen ihre SPF-Einträge laufend aktualisieren, wenn Anbieter ihre E-Mail-Server ändern, die Organisation den Internetanbieter wechselt oder die Marketingabteilung neue E-Mail-Newsletterdienste hinzufügt. Änderungen können zeitaufwendig sein und müssen mit allen Beteiligten umständlich überprüft werden, was regelmäßige DNS-Aktualisierungen erschwert.

Durch fehlerhafte E-Mail-Weiterleitung beeinträchtigt

Weitergeleitete E-Mails ändern häufig die sendende IP-Adresse, wodurch die SPF-Prüfung fehlschlägt. Organisationen sollten die Servereinstellungen so korrigieren, dass weitergeleitete E-Mails die korrekten Informationen behalten, doch viele tun dies nicht.

Keine vollständige Lösung

SPF überprüft nur die sendende Domain im E-Mail-Header und vergleicht sie nicht mit der dem Benutzer angezeigten „From“-E-Mail-Adresse. Verwendet ein Phishing-Angreifer eine eigene SPF-Datei mit einer eigenen sendenden Domain, wird SPF als gültig bestanden. Für einen umfassenderen Schutz sollten SPF, DKIM und DMARC kombiniert eingesetzt werden, um die Reputation einer Organisation und validierte E-Mails zu schützen.

Probleme großer Organisationen

Je größer eine Organisation ist, desto wahrscheinlicher verfügt sie über eine große Zahl von Servern und Diensten, die E-Mails für die Organisation versenden. Aufgrund der Begrenzung auf 255 Zeichen und 10 DNS-Abfragen können größere Organisationen nicht alle sendenden IP-Adressen in einem einzigen SPF-Eintrag veröffentlichen. Stattdessen müssen sie Subdomains verwenden, um die SPF-Einschränkungen zu umgehen.

Schwierige ROI-Messung

Obwohl die Organisation Verbesserungen bei der Reputation und zuverlässiger zustellbare E-Mails feststellen kann, lassen sich diese Vorteile nur schwer für die Messung des Return on Investment quantifizieren. Zudem kommt der Hauptvorteil in der Regel anderen zugute: den E-Mail-Servern und E-Mail-Sicherheitstools, die die E-Mails empfangen und den SPF-Eintrag prüfen, um Spam- und Phishing-E-Mails zu blockieren. Die Investition zur Implementierung von SPF ist zwar gering, doch der immaterielle ROI und die Vorteile erklären, warum die Einführung nicht höher ist als 50%.

Potenziell für Spoofing missbrauchbar

SPF kann von jeder Organisation eingesetzt werden – auch von böswilligen Akteuren und Spammern. Da eine SPF-Prüfung die „From“-Informationen im E-Mail-Text nicht einbezieht, können böswillige Akteure eine eigene SPF-Datei veröffentlichen, um ihre gefälschten E-Mails oder Spam anhand ihrer eigenen Domaininformationen zu authentifizieren, und dem E-Mail-Empfänger anschließend im „From“-Feld des E-Mail-Programms völlig andere Informationen anzeigen.

Erfordert korrekte E-Mail-Servereinstellungen

SPF funktioniert nur auf E-Mail-Servern, die für die SPF-Prüfung eingerichtet sind oder E-Mail-Sicherheitstools verwenden, die dieselbe Aufgabe übernehmen. Server können SPF-Prüfungen problemlos überspringen und so die Verbreitung von Spam und Spoofing-E-Mails ermöglichen.

SPF-FAQs:

Fazit: SPF – ein entscheidender erster Schritt zur Beseitigung von Phishing

Phishing bleibt das wichtigste Einfallstor für Cybersecurity- und Netzwerkangriffe, da zu viele gefälschte E-Mails ungekennzeichnet bleiben. SPF ist der erste Schritt im E-Mail-Authentifizierungsprozess aus SPF, DKIM und DMARC, der die überwiegende Mehrheit der Phishing-E-Mails blockieren könnte, wenn genügend Organisationen SPF zusammen mit DKIM und DMARC einführen. SPF ist zwar aufwendig zu pflegen, doch die geringen Bereitstellungskosten sollten alle Organisationen dazu bewegen, SPF als ersten Schritt im Kampf gegen weltweites E-Mail-Phishing einzuführen – oder sich zumindest vor Phishing zu schützen, bei dem die eigene Domain imitiert wird.