SPF-Authentifizierung: Eine Übersicht und bewährte Praktiken
Vogel
19.12.2016
1 min read
Wichtige Erkenntnisse
SPF (Sender Policy Framework) ist ein pfadbasiertes E-Mail-Authentifizierungsprotokoll, das überprüft, ob der sendende Server berechtigt ist, E-Mails für eine Domain zu senden.
SPF-Richtlinien existieren als DNS TXT-Einträge, die mit Mechanismen formatiert sind, die definieren, welche Server, IPs oder Netzwerke im Auftrag einer Domain senden dürfen.
Die SPF-Validierung ist mit der Return-Path-Domain (Bounce-Domain) oder dem HELO-Hostname verknüpft — nicht mit der sichtbaren Absenderadresse.
Da SPF nur den Sendeweg prüft, kann es früh im SMTP-Transaktionsprozess validiert werden, was es nützlich macht, um unautorisierte E-Mails schnell abzulehnen.
SPF ist effektiv, aber nicht perfekt — es ist anfällig für falsche Negative, insbesondere bei der E-Mail-Weiterleitung und bei Mailinglisten.
SPF-Einträge basieren auf Mechanismen wie
mx,a,ipv4,ipv6,include,redirect,existsund müssen mit einemall-Modifikator enden (-all,~all,?all,+all).Es gelten DNS-Abfragelimits: Die SPF-Auswertung darf 10 DNS-Abfragen nicht überschreiten, was die Planung von Einträgen wichtig macht.
Der
ptr-Mechanismus gilt inzwischen als „nicht verwenden“, aber Validatoren müssen ihn trotzdem akzeptieren. Einige Absender verwenden ihn noch aufgrund von Kompatibilitätslücken.SPF allein garantiert nicht, dass eine E-Mail legitim ist — nur dass sie von einem autorisierten Server gesendet wurde. Es funktioniert am besten in Kombination mit DKIM, DMARC und anderen Anti-Betrugstechniken.
Q&A Highlights
Was ist SPF in einfachen Worten?
SPF ermöglicht es einer Domain zu deklarieren, welche Server berechtigt sind, in ihrem Namen E-Mails zu versenden. Empfangsserver überprüfen dies, um unautorisierte Absender zu erkennen.
Warum wird SPF als „path-based“ bezeichnet?
Da SPF den Pfad validiert, den die Nachricht genommen hat – speziell die IP des sendenden Servers – und nicht den Inhalt der Nachricht.
Wo wird eine SPF-Policy gespeichert?
A: Als ein DNS TXT-Eintrag, beginnend mit
v=spf1, gefolgt von Mechanismen, die erlaubte Absender definieren.Welcher Domain wird von SPF validiert?
Der Return-Path (auch als Bounce-Domain bezeichnet).
Wenn der Return-Path leer ist (NULL-Absender), überprüft SPF stattdessen die HELO-Domain.
Kann SPF früh im SMTP-Transaktionsprozess überprüft werden?
Ja. Da es nur von der IP und der Domain des sendenden Servers abhängt, kann SPF validiert werden, bevor der Nachrichteninhalt empfangen wird—was es effizient für die Filterung macht.
Warum schlägt SPF manchmal selbst bei legitimen E-Mails fehl?
Häufige Ursachen sind:
Email-Weiterleitung (der Weiterleiter ist nicht im SPF-Eintrag der ursprünglichen Domain enthalten)
Mailinglisten (Nachrichten werden von einem anderen Server erneut gesendet)
Dies führt zu falschen Negativen, die bei der pfadbasierten Authentifizierung inherent sind.
Was ist die Rolle von Mechanismen wie include, redirect und exists?
include— eine andere Domain-SFP-Eintrag autorisieren (z.B. Ihr ESP)redirect— die SFP-Richtlinie einer anderen Domain wiederverwendenexists— dynamisch basierend auf einem DNS-Lookup autorisieren (nützlich für komplexe Infrastruktur)
Wie funktionieren „all“ Modifier?
-all→ alles nicht aufgelistete ablehnen (streng)~all→ softfail (akzeptieren, aber markieren)?all→ neutral+all→ alles durchlassen (deaktiviert effektiv SPF)
Warum wird der ptr-Mechanismus entmutigt?
Es ist langsam, unzuverlässig und im modernen Standard veraltet—aber SPF-Validatoren müssen es weiterhin unterstützen.
Ist SPF allein genug für die E-Mail-Authentifizierung?
Nein. SPF überprüft die sendende Infrastruktur, aber:
Es schützt nicht die Nachrichtenintegrität
Es stimmt nicht mit den sichtbaren From-Domains überein
Es funktioniert nicht bei Weiterleitungen
SPF ist am stärksten, wenn es mit DKIM und DMARC kombiniert wird.
Bevor wir in die technische Umsetzung eintauchen, lohnt es sich, die Entwicklung und Vielfalt der verfügbaren Techniken zur E-Mail-Validierung zu verstehen. Von einfacher Syntaxprüfung bis zu modernen datengetriebenen Ansätzen bieten verschiedene Validierungsmethoden unterschiedliche Genauigkeits- und Zuverlässigkeitsgrade.
Wenn wir von „Email Authentication“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit geben soll, dass die Nachricht tatsächlich vom angegebenen Absender stammt. Die Idee ist, ein gewisses Maß an Schutz gegen betrügerische E-Mails, wie Phishing und Spoofing zu erreichen, die das Vertrauen des Empfängers beim Erhalt von E-Mails untergraben könnten. Für Organisationen, die eine Nachrichtenverschlüsselung auf Nachrichtenniveau über die Authentifizierung hinaus benötigen, bietet S/MIME End-to-End-Sicherheit, wobei die automatisierte Sammlung öffentlicher Empfängerschlüssel die Implementierung skalierbarer macht. Das Versenden authentifizierter E-Mails bedeutet jedoch nicht, dass die E-Mail eine gute oder erwünschte E-Mail ist; es bedeutet lediglich, dass eine Reputation für die authentifizierte Partei zuverlässig etabliert und in Entscheidungen zur E-Mail-Akzeptanz und -Platzierung verwendet werden kann.
Es gibt heute zwei Hauptformen der E-Mail-Authentifizierung—Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM). In diesem Blogpost werde ich erklären, was SPF ist und wie es funktioniert.
Bevor wir in die technische Umsetzung eintauchen, lohnt es sich, die Entwicklung und Vielfalt der verfügbaren Techniken zur E-Mail-Validierung zu verstehen. Von einfacher Syntaxprüfung bis zu modernen datengetriebenen Ansätzen bieten verschiedene Validierungsmethoden unterschiedliche Genauigkeits- und Zuverlässigkeitsgrade.
Wenn wir von „Email Authentication“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit geben soll, dass die Nachricht tatsächlich vom angegebenen Absender stammt. Die Idee ist, ein gewisses Maß an Schutz gegen betrügerische E-Mails, wie Phishing und Spoofing zu erreichen, die das Vertrauen des Empfängers beim Erhalt von E-Mails untergraben könnten. Für Organisationen, die eine Nachrichtenverschlüsselung auf Nachrichtenniveau über die Authentifizierung hinaus benötigen, bietet S/MIME End-to-End-Sicherheit, wobei die automatisierte Sammlung öffentlicher Empfängerschlüssel die Implementierung skalierbarer macht. Das Versenden authentifizierter E-Mails bedeutet jedoch nicht, dass die E-Mail eine gute oder erwünschte E-Mail ist; es bedeutet lediglich, dass eine Reputation für die authentifizierte Partei zuverlässig etabliert und in Entscheidungen zur E-Mail-Akzeptanz und -Platzierung verwendet werden kann.
Es gibt heute zwei Hauptformen der E-Mail-Authentifizierung—Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM). In diesem Blogpost werde ich erklären, was SPF ist und wie es funktioniert.
Bevor wir in die technische Umsetzung eintauchen, lohnt es sich, die Entwicklung und Vielfalt der verfügbaren Techniken zur E-Mail-Validierung zu verstehen. Von einfacher Syntaxprüfung bis zu modernen datengetriebenen Ansätzen bieten verschiedene Validierungsmethoden unterschiedliche Genauigkeits- und Zuverlässigkeitsgrade.
Wenn wir von „Email Authentication“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit geben soll, dass die Nachricht tatsächlich vom angegebenen Absender stammt. Die Idee ist, ein gewisses Maß an Schutz gegen betrügerische E-Mails, wie Phishing und Spoofing zu erreichen, die das Vertrauen des Empfängers beim Erhalt von E-Mails untergraben könnten. Für Organisationen, die eine Nachrichtenverschlüsselung auf Nachrichtenniveau über die Authentifizierung hinaus benötigen, bietet S/MIME End-to-End-Sicherheit, wobei die automatisierte Sammlung öffentlicher Empfängerschlüssel die Implementierung skalierbarer macht. Das Versenden authentifizierter E-Mails bedeutet jedoch nicht, dass die E-Mail eine gute oder erwünschte E-Mail ist; es bedeutet lediglich, dass eine Reputation für die authentifizierte Partei zuverlässig etabliert und in Entscheidungen zur E-Mail-Akzeptanz und -Platzierung verwendet werden kann.
Es gibt heute zwei Hauptformen der E-Mail-Authentifizierung—Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM). In diesem Blogpost werde ich erklären, was SPF ist und wie es funktioniert.
SPF ist nicht narrensicher
Obwohl es ein relativ unkomplizierter Weg zu sein scheint, E-Mails zu authentifizieren, ist SPF anfällig für Ausfälle in Form von Fehlalarmen. Diese Ausfälle können häufiger auftreten, als es vielen recht ist.
Hier sind zwei gängige Szenarien, in denen vollkommen legitime E-Mails die SPF-Validierung nicht bestehen und daher als betrügerisch erscheinen können:
Automatisches Weiterleiten, bei dem eine Nachricht, die an jsmith@alumni.university.edu gesendet wurde, an ein Postfach weitergeleitet wird, das so eingestellt ist, dass alle E-Mails automatisch an jsmith@isp.com weitergeleitet werden
Mailinglisten, bei denen E-Mails, die an talk-about-stuff@listserv.foo.com gesendet werden, „explodiert“ und an jeden Abonnenten gesendet werden
In beiden Fällen, wenn der Return-Path unverändert von seinem Original bleibt, könnten die E-Mails die SPF-Prüfung nicht bestehen (abhängig von dem Modifikator, der mit dem ‚all‘-Mechanismus verwendet wird). Dies liegt daran, dass sie von einem Zwischenserver an ihr endgültiges Ziel gelangen, nicht von dem ursprünglichen, und dieser Zwischenserver wahrscheinlich nicht im SPF-Eintrag der Domäne enthalten ist. Eine Technik namens „Sender Rewriting Scheme“ oder „SRS“ kann dieses Risiko mindern, und einige größere Seiten haben es eingeführt, aber es ist nicht universell.
Obwohl es ein relativ unkomplizierter Weg zu sein scheint, E-Mails zu authentifizieren, ist SPF anfällig für Ausfälle in Form von Fehlalarmen. Diese Ausfälle können häufiger auftreten, als es vielen recht ist.
Hier sind zwei gängige Szenarien, in denen vollkommen legitime E-Mails die SPF-Validierung nicht bestehen und daher als betrügerisch erscheinen können:
Automatisches Weiterleiten, bei dem eine Nachricht, die an jsmith@alumni.university.edu gesendet wurde, an ein Postfach weitergeleitet wird, das so eingestellt ist, dass alle E-Mails automatisch an jsmith@isp.com weitergeleitet werden
Mailinglisten, bei denen E-Mails, die an talk-about-stuff@listserv.foo.com gesendet werden, „explodiert“ und an jeden Abonnenten gesendet werden
In beiden Fällen, wenn der Return-Path unverändert von seinem Original bleibt, könnten die E-Mails die SPF-Prüfung nicht bestehen (abhängig von dem Modifikator, der mit dem ‚all‘-Mechanismus verwendet wird). Dies liegt daran, dass sie von einem Zwischenserver an ihr endgültiges Ziel gelangen, nicht von dem ursprünglichen, und dieser Zwischenserver wahrscheinlich nicht im SPF-Eintrag der Domäne enthalten ist. Eine Technik namens „Sender Rewriting Scheme“ oder „SRS“ kann dieses Risiko mindern, und einige größere Seiten haben es eingeführt, aber es ist nicht universell.
Obwohl es ein relativ unkomplizierter Weg zu sein scheint, E-Mails zu authentifizieren, ist SPF anfällig für Ausfälle in Form von Fehlalarmen. Diese Ausfälle können häufiger auftreten, als es vielen recht ist.
Hier sind zwei gängige Szenarien, in denen vollkommen legitime E-Mails die SPF-Validierung nicht bestehen und daher als betrügerisch erscheinen können:
Automatisches Weiterleiten, bei dem eine Nachricht, die an jsmith@alumni.university.edu gesendet wurde, an ein Postfach weitergeleitet wird, das so eingestellt ist, dass alle E-Mails automatisch an jsmith@isp.com weitergeleitet werden
Mailinglisten, bei denen E-Mails, die an talk-about-stuff@listserv.foo.com gesendet werden, „explodiert“ und an jeden Abonnenten gesendet werden
In beiden Fällen, wenn der Return-Path unverändert von seinem Original bleibt, könnten die E-Mails die SPF-Prüfung nicht bestehen (abhängig von dem Modifikator, der mit dem ‚all‘-Mechanismus verwendet wird). Dies liegt daran, dass sie von einem Zwischenserver an ihr endgültiges Ziel gelangen, nicht von dem ursprünglichen, und dieser Zwischenserver wahrscheinlich nicht im SPF-Eintrag der Domäne enthalten ist. Eine Technik namens „Sender Rewriting Scheme“ oder „SRS“ kann dieses Risiko mindern, und einige größere Seiten haben es eingeführt, aber es ist nicht universell.
SPF Übersicht
Sender Policy Framework (SPF), um RFC 7208 zu paraphrasieren, ist ein Protokoll, das einer Organisation nicht nur erlaubt, Hosts und Netzwerke zu autorisieren, ihre Domainnamen beim Versenden von E-Mails zu verwenden, sondern auch eine Möglichkeit bietet, wie ein empfangender Host diese Autorisierung überprüfen kann.
Wenn Sie diesen Beitrag fertig gelesen haben, hoffe ich, dass Sie Folgendes gelernt haben:
SPF ist ein „pfadbasiertes“ Authentifizierungssystem.
SPF-Richtlinien werden in DNS TXT-Einträgen deklariert.
Die Validierung ist an die Return-Path-Domain (was wir hier bei SparkPost die „Bounce-Domain“ nennen) oder die HELO-Domain gebunden.
Die Validierung kann früh in der SMTP-Transaktion durchgeführt werden, daher ist es eine gute Überprüfung, um nicht authentifizierte Mails schnell abzulehnen.
Es ist anfällig für einen relativ hohen Prozentsatz an falschen Negativen.
Sender Policy Framework (SPF), um RFC 7208 zu paraphrasieren, ist ein Protokoll, das einer Organisation nicht nur erlaubt, Hosts und Netzwerke zu autorisieren, ihre Domainnamen beim Versenden von E-Mails zu verwenden, sondern auch eine Möglichkeit bietet, wie ein empfangender Host diese Autorisierung überprüfen kann.
Wenn Sie diesen Beitrag fertig gelesen haben, hoffe ich, dass Sie Folgendes gelernt haben:
SPF ist ein „pfadbasiertes“ Authentifizierungssystem.
SPF-Richtlinien werden in DNS TXT-Einträgen deklariert.
Die Validierung ist an die Return-Path-Domain (was wir hier bei SparkPost die „Bounce-Domain“ nennen) oder die HELO-Domain gebunden.
Die Validierung kann früh in der SMTP-Transaktion durchgeführt werden, daher ist es eine gute Überprüfung, um nicht authentifizierte Mails schnell abzulehnen.
Es ist anfällig für einen relativ hohen Prozentsatz an falschen Negativen.
Sender Policy Framework (SPF), um RFC 7208 zu paraphrasieren, ist ein Protokoll, das einer Organisation nicht nur erlaubt, Hosts und Netzwerke zu autorisieren, ihre Domainnamen beim Versenden von E-Mails zu verwenden, sondern auch eine Möglichkeit bietet, wie ein empfangender Host diese Autorisierung überprüfen kann.
Wenn Sie diesen Beitrag fertig gelesen haben, hoffe ich, dass Sie Folgendes gelernt haben:
SPF ist ein „pfadbasiertes“ Authentifizierungssystem.
SPF-Richtlinien werden in DNS TXT-Einträgen deklariert.
Die Validierung ist an die Return-Path-Domain (was wir hier bei SparkPost die „Bounce-Domain“ nennen) oder die HELO-Domain gebunden.
Die Validierung kann früh in der SMTP-Transaktion durchgeführt werden, daher ist es eine gute Überprüfung, um nicht authentifizierte Mails schnell abzulehnen.
Es ist anfällig für einen relativ hohen Prozentsatz an falschen Negativen.
“Pfadbasierte” Authentication
SPF wird als ein pfadbasiertes Authentifizierungssystem betrachtet, da es ausschließlich mit dem Pfad verbunden ist, den die Nachricht von ihrem Ursprung bis zu ihrem Ziel genommen hat. Wenn ein sendender Server eine SMTP-Transaktion mit einem empfangenden Server initiiert, bestimmt der empfangende Server, ob der sendende Server autorisiert ist, diese Nachricht zu senden, basierend auf der SPF-Richtlinie der Domain. Es ist ausschließlich eine Entscheidung basierend darauf, woher die Nachricht kommt, ohne jeglichen Bezug zum Inhalt der Nachricht.
SPF wird als ein pfadbasiertes Authentifizierungssystem betrachtet, da es ausschließlich mit dem Pfad verbunden ist, den die Nachricht von ihrem Ursprung bis zu ihrem Ziel genommen hat. Wenn ein sendender Server eine SMTP-Transaktion mit einem empfangenden Server initiiert, bestimmt der empfangende Server, ob der sendende Server autorisiert ist, diese Nachricht zu senden, basierend auf der SPF-Richtlinie der Domain. Es ist ausschließlich eine Entscheidung basierend darauf, woher die Nachricht kommt, ohne jeglichen Bezug zum Inhalt der Nachricht.
SPF wird als ein pfadbasiertes Authentifizierungssystem betrachtet, da es ausschließlich mit dem Pfad verbunden ist, den die Nachricht von ihrem Ursprung bis zu ihrem Ziel genommen hat. Wenn ein sendender Server eine SMTP-Transaktion mit einem empfangenden Server initiiert, bestimmt der empfangende Server, ob der sendende Server autorisiert ist, diese Nachricht zu senden, basierend auf der SPF-Richtlinie der Domain. Es ist ausschließlich eine Entscheidung basierend darauf, woher die Nachricht kommt, ohne jeglichen Bezug zum Inhalt der Nachricht.
Deklaration einer SPF-Richtlinie
Ein SPF-Policy-Eintrag einer Domain ist lediglich ein speziell formatiertes DNS TXT-Eintrag, der üblicherweise einen oder mehrere der folgenden „Mechanismen“ enthält:
v=spf1 – Erforderliches erstes Token, um anzuzeigen, dass der TXT-Eintrag ein SPF-Eintrag ist (eine Domain kann mehrere TXT-Einträge haben)
ipv4, ipv6 – Wird verwendet, um IP-Adressen und Netzwerke anzugeben, die befugt sind, E-Mails für die Domain zu senden
a – Wenn die sendende Domain einen DNS-„A“-Eintrag hat, der zur sendenden IP aufgelöst wird, ist die IP zugelassen
mx – Wenn die sendende IP auch einer der MX-Einträge der sendenden Domain ist, ist die IP zugelassen
all – Erforderliches letztes Token, immer modifiziert:
-all – Nur was hier aufgelistet wird, darf bestehen; Fehler ablehnen.
~all – Was hier nicht aufgelistet ist, sollte weich fehlschlagen; akzeptieren, aber notieren.
?all – Unsicher, ob Dinge, die hier nicht aufgelistet sind, passieren sollen.
+all – Wir denken, dass SPF nutzlos ist; alles zulassen.
Andere, weniger häufige Mechanismen, die noch weit verbreitet sind, sind:
include – Wird verwendet, wenn eine Domain nicht nur ihre eigenen Server hat, sondern auch die Server eines anderen nutzt. Muss sorgfältig verwendet werden. Jedes Include ist eine weitere DNS-Abfrage, und SPF-Einträge dürfen nicht mehr als zehn DNS-Abfragen zur Auflösung erfordern.
redirect – Wenn Domain A und Domain B demselben Unternehmen gehören und dieselbe Infrastruktur nutzen. Die Eigentümer möchten typischerweise nur eine Kopie des SPF-Eintrags für beide behalten und B so konfigurieren, dass Anfragen an A weitergeleitet werden.
exists – Wenn eine Domain viele kleine, nicht zusammenhängende Netzwerkblöcke hat, kann dieser Mechanismus verwendet werden, um seinen SPF-Eintrag anzugeben, anstatt alle aufzulisten. Nützlich, um innerhalb des Größenlimits (512 Bytes) für DNS-Antworten zu bleiben.
Eine Anmerkung zum „ptr“-Mechanismus
Ein letzter Mechanismus, „ptr“, bestand in der ursprünglichen Spezifikation für SPF, aber wurde in der aktuellen Spezifikation als „nicht verwenden“ deklariert. Der ptr-Mechanismus wurde verwendet, um zu deklarieren, dass, wenn die sendende IP-Adresse einen DNS-PTR-Eintrag hatte, der auf den fraglichen Domainnamen auflöste, diese IP-Adresse autorisiert war, E-Mails für die Domain zu senden.
Der aktuelle Status dieses Mechanismus ist, dass er nicht verwendet werden sollte. Dennoch müssen Websites, die SPF-Validierung durchführen, ihn als gültig akzeptieren.
Mechanismus | Was es tut | Hinweise / Nutzungshinweise |
|---|---|---|
v=spf1 | Erklärt, dass der TXT-Eintrag eine SPF-Policy ist | Erforderliches erstes Token |
ipv4 / ipv6 | Autorisiert bestimmte IPs oder CIDR-Blöcke | Die expliziteste und zuverlässigste Autorisierungsmethode |
a | Autorisiert IPs, die mit dem A-Eintrag der Domain übereinstimmen | Gut für einfache Infrastrukturen |
mx | Autorisiert IPs, die in den MX-Einträgen der Domain aufgeführt sind | Nützlich, wenn MX-Server auch E-Mails senden |
include | Importiert die SPF-Policy einer anderen Domain | Zählt zum 10-DNS-Lookup-Limit; sparsam verwenden |
redirect | Delegiert SPF-Policy an eine andere Domain | Wird verwendet, wenn mehrere Domains eine SPF-Definition teilen |
exists | Autorisiert über eine benutzerdefinierte DNS-Lookup-Regel | Nützlich für große, fragmentierte IP-Bereiche; Validator muss es unterstützen |
ptr | Autorisiert basierend auf der Rückwärts-DNS-Zuordnung | Veraltet („nicht verwenden“), muss aber dennoch von Validatoren akzeptiert werden |
all | Definiert, wie alles, was nicht explizit erlaubt ist, behandelt wird | Varianten: -all ablehnen, ~all weich fehlschlagen, ?all neutral, +all alles erlauben (nicht empfohlen) |
Ein SPF-Policy-Eintrag einer Domain ist lediglich ein speziell formatiertes DNS TXT-Eintrag, der üblicherweise einen oder mehrere der folgenden „Mechanismen“ enthält:
v=spf1 – Erforderliches erstes Token, um anzuzeigen, dass der TXT-Eintrag ein SPF-Eintrag ist (eine Domain kann mehrere TXT-Einträge haben)
ipv4, ipv6 – Wird verwendet, um IP-Adressen und Netzwerke anzugeben, die befugt sind, E-Mails für die Domain zu senden
a – Wenn die sendende Domain einen DNS-„A“-Eintrag hat, der zur sendenden IP aufgelöst wird, ist die IP zugelassen
mx – Wenn die sendende IP auch einer der MX-Einträge der sendenden Domain ist, ist die IP zugelassen
all – Erforderliches letztes Token, immer modifiziert:
-all – Nur was hier aufgelistet wird, darf bestehen; Fehler ablehnen.
~all – Was hier nicht aufgelistet ist, sollte weich fehlschlagen; akzeptieren, aber notieren.
?all – Unsicher, ob Dinge, die hier nicht aufgelistet sind, passieren sollen.
+all – Wir denken, dass SPF nutzlos ist; alles zulassen.
Andere, weniger häufige Mechanismen, die noch weit verbreitet sind, sind:
include – Wird verwendet, wenn eine Domain nicht nur ihre eigenen Server hat, sondern auch die Server eines anderen nutzt. Muss sorgfältig verwendet werden. Jedes Include ist eine weitere DNS-Abfrage, und SPF-Einträge dürfen nicht mehr als zehn DNS-Abfragen zur Auflösung erfordern.
redirect – Wenn Domain A und Domain B demselben Unternehmen gehören und dieselbe Infrastruktur nutzen. Die Eigentümer möchten typischerweise nur eine Kopie des SPF-Eintrags für beide behalten und B so konfigurieren, dass Anfragen an A weitergeleitet werden.
exists – Wenn eine Domain viele kleine, nicht zusammenhängende Netzwerkblöcke hat, kann dieser Mechanismus verwendet werden, um seinen SPF-Eintrag anzugeben, anstatt alle aufzulisten. Nützlich, um innerhalb des Größenlimits (512 Bytes) für DNS-Antworten zu bleiben.
Eine Anmerkung zum „ptr“-Mechanismus
Ein letzter Mechanismus, „ptr“, bestand in der ursprünglichen Spezifikation für SPF, aber wurde in der aktuellen Spezifikation als „nicht verwenden“ deklariert. Der ptr-Mechanismus wurde verwendet, um zu deklarieren, dass, wenn die sendende IP-Adresse einen DNS-PTR-Eintrag hatte, der auf den fraglichen Domainnamen auflöste, diese IP-Adresse autorisiert war, E-Mails für die Domain zu senden.
Der aktuelle Status dieses Mechanismus ist, dass er nicht verwendet werden sollte. Dennoch müssen Websites, die SPF-Validierung durchführen, ihn als gültig akzeptieren.
Mechanismus | Was es tut | Hinweise / Nutzungshinweise |
|---|---|---|
v=spf1 | Erklärt, dass der TXT-Eintrag eine SPF-Policy ist | Erforderliches erstes Token |
ipv4 / ipv6 | Autorisiert bestimmte IPs oder CIDR-Blöcke | Die expliziteste und zuverlässigste Autorisierungsmethode |
a | Autorisiert IPs, die mit dem A-Eintrag der Domain übereinstimmen | Gut für einfache Infrastrukturen |
mx | Autorisiert IPs, die in den MX-Einträgen der Domain aufgeführt sind | Nützlich, wenn MX-Server auch E-Mails senden |
include | Importiert die SPF-Policy einer anderen Domain | Zählt zum 10-DNS-Lookup-Limit; sparsam verwenden |
redirect | Delegiert SPF-Policy an eine andere Domain | Wird verwendet, wenn mehrere Domains eine SPF-Definition teilen |
exists | Autorisiert über eine benutzerdefinierte DNS-Lookup-Regel | Nützlich für große, fragmentierte IP-Bereiche; Validator muss es unterstützen |
ptr | Autorisiert basierend auf der Rückwärts-DNS-Zuordnung | Veraltet („nicht verwenden“), muss aber dennoch von Validatoren akzeptiert werden |
all | Definiert, wie alles, was nicht explizit erlaubt ist, behandelt wird | Varianten: -all ablehnen, ~all weich fehlschlagen, ?all neutral, +all alles erlauben (nicht empfohlen) |
Ein SPF-Policy-Eintrag einer Domain ist lediglich ein speziell formatiertes DNS TXT-Eintrag, der üblicherweise einen oder mehrere der folgenden „Mechanismen“ enthält:
v=spf1 – Erforderliches erstes Token, um anzuzeigen, dass der TXT-Eintrag ein SPF-Eintrag ist (eine Domain kann mehrere TXT-Einträge haben)
ipv4, ipv6 – Wird verwendet, um IP-Adressen und Netzwerke anzugeben, die befugt sind, E-Mails für die Domain zu senden
a – Wenn die sendende Domain einen DNS-„A“-Eintrag hat, der zur sendenden IP aufgelöst wird, ist die IP zugelassen
mx – Wenn die sendende IP auch einer der MX-Einträge der sendenden Domain ist, ist die IP zugelassen
all – Erforderliches letztes Token, immer modifiziert:
-all – Nur was hier aufgelistet wird, darf bestehen; Fehler ablehnen.
~all – Was hier nicht aufgelistet ist, sollte weich fehlschlagen; akzeptieren, aber notieren.
?all – Unsicher, ob Dinge, die hier nicht aufgelistet sind, passieren sollen.
+all – Wir denken, dass SPF nutzlos ist; alles zulassen.
Andere, weniger häufige Mechanismen, die noch weit verbreitet sind, sind:
include – Wird verwendet, wenn eine Domain nicht nur ihre eigenen Server hat, sondern auch die Server eines anderen nutzt. Muss sorgfältig verwendet werden. Jedes Include ist eine weitere DNS-Abfrage, und SPF-Einträge dürfen nicht mehr als zehn DNS-Abfragen zur Auflösung erfordern.
redirect – Wenn Domain A und Domain B demselben Unternehmen gehören und dieselbe Infrastruktur nutzen. Die Eigentümer möchten typischerweise nur eine Kopie des SPF-Eintrags für beide behalten und B so konfigurieren, dass Anfragen an A weitergeleitet werden.
exists – Wenn eine Domain viele kleine, nicht zusammenhängende Netzwerkblöcke hat, kann dieser Mechanismus verwendet werden, um seinen SPF-Eintrag anzugeben, anstatt alle aufzulisten. Nützlich, um innerhalb des Größenlimits (512 Bytes) für DNS-Antworten zu bleiben.
Eine Anmerkung zum „ptr“-Mechanismus
Ein letzter Mechanismus, „ptr“, bestand in der ursprünglichen Spezifikation für SPF, aber wurde in der aktuellen Spezifikation als „nicht verwenden“ deklariert. Der ptr-Mechanismus wurde verwendet, um zu deklarieren, dass, wenn die sendende IP-Adresse einen DNS-PTR-Eintrag hatte, der auf den fraglichen Domainnamen auflöste, diese IP-Adresse autorisiert war, E-Mails für die Domain zu senden.
Der aktuelle Status dieses Mechanismus ist, dass er nicht verwendet werden sollte. Dennoch müssen Websites, die SPF-Validierung durchführen, ihn als gültig akzeptieren.
Mechanismus | Was es tut | Hinweise / Nutzungshinweise |
|---|---|---|
v=spf1 | Erklärt, dass der TXT-Eintrag eine SPF-Policy ist | Erforderliches erstes Token |
ipv4 / ipv6 | Autorisiert bestimmte IPs oder CIDR-Blöcke | Die expliziteste und zuverlässigste Autorisierungsmethode |
a | Autorisiert IPs, die mit dem A-Eintrag der Domain übereinstimmen | Gut für einfache Infrastrukturen |
mx | Autorisiert IPs, die in den MX-Einträgen der Domain aufgeführt sind | Nützlich, wenn MX-Server auch E-Mails senden |
include | Importiert die SPF-Policy einer anderen Domain | Zählt zum 10-DNS-Lookup-Limit; sparsam verwenden |
redirect | Delegiert SPF-Policy an eine andere Domain | Wird verwendet, wenn mehrere Domains eine SPF-Definition teilen |
exists | Autorisiert über eine benutzerdefinierte DNS-Lookup-Regel | Nützlich für große, fragmentierte IP-Bereiche; Validator muss es unterstützen |
ptr | Autorisiert basierend auf der Rückwärts-DNS-Zuordnung | Veraltet („nicht verwenden“), muss aber dennoch von Validatoren akzeptiert werden |
all | Definiert, wie alles, was nicht explizit erlaubt ist, behandelt wird | Varianten: -all ablehnen, ~all weich fehlschlagen, ?all neutral, +all alles erlauben (nicht empfohlen) |
Einige Beispiel SPF Records
Hier sind einige Beispielaufzeichnungen und deren Bedeutungen. Dieses Beispiel zeigt RFC 1918-Adressen, aber ich erkenne, dass solche Adressen niemals in echten SPF-Einträgen erscheinen werden.
MX-Eintrag, eine IP-Adresse, ein IP-Netzwerk, Softfail für alles andere:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-Eintrag, zwei IP-Netzwerke, alles andere ablehnen:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Wir senden keine E-Mails:
“v=spf1 -all”
Wir halten SPF für dumm:
“v=spf1 +all”
Der SPF-Eintrag für die Domain sparkpostmail.com (Redirect-Mechanismus verwendet)
“v=spf1 redirect=_spf.sparkpostmail.com”
Der SPF-Eintrag für _spf.sparkpostmail.com (exists- und ptr-Mechanismen verwendet):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bei SparkPost verwenden wir derzeit den ptr-Mechanismus in unserem SPF-Eintrag. Wir haben festgestellt, dass dies aufgrund fehlender universeller Unterstützung zur Validierung des exists-Mechanismus erforderlich ist. Und bisher haben wir keine SPF-Fehler festgestellt, die durch die Verwendung des ptr-Mechanismus entstehen.
Hier sind einige Beispielaufzeichnungen und deren Bedeutungen. Dieses Beispiel zeigt RFC 1918-Adressen, aber ich erkenne, dass solche Adressen niemals in echten SPF-Einträgen erscheinen werden.
MX-Eintrag, eine IP-Adresse, ein IP-Netzwerk, Softfail für alles andere:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-Eintrag, zwei IP-Netzwerke, alles andere ablehnen:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Wir senden keine E-Mails:
“v=spf1 -all”
Wir halten SPF für dumm:
“v=spf1 +all”
Der SPF-Eintrag für die Domain sparkpostmail.com (Redirect-Mechanismus verwendet)
“v=spf1 redirect=_spf.sparkpostmail.com”
Der SPF-Eintrag für _spf.sparkpostmail.com (exists- und ptr-Mechanismen verwendet):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bei SparkPost verwenden wir derzeit den ptr-Mechanismus in unserem SPF-Eintrag. Wir haben festgestellt, dass dies aufgrund fehlender universeller Unterstützung zur Validierung des exists-Mechanismus erforderlich ist. Und bisher haben wir keine SPF-Fehler festgestellt, die durch die Verwendung des ptr-Mechanismus entstehen.
Hier sind einige Beispielaufzeichnungen und deren Bedeutungen. Dieses Beispiel zeigt RFC 1918-Adressen, aber ich erkenne, dass solche Adressen niemals in echten SPF-Einträgen erscheinen werden.
MX-Eintrag, eine IP-Adresse, ein IP-Netzwerk, Softfail für alles andere:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-Eintrag, zwei IP-Netzwerke, alles andere ablehnen:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Wir senden keine E-Mails:
“v=spf1 -all”
Wir halten SPF für dumm:
“v=spf1 +all”
Der SPF-Eintrag für die Domain sparkpostmail.com (Redirect-Mechanismus verwendet)
“v=spf1 redirect=_spf.sparkpostmail.com”
Der SPF-Eintrag für _spf.sparkpostmail.com (exists- und ptr-Mechanismen verwendet):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bei SparkPost verwenden wir derzeit den ptr-Mechanismus in unserem SPF-Eintrag. Wir haben festgestellt, dass dies aufgrund fehlender universeller Unterstützung zur Validierung des exists-Mechanismus erforderlich ist. Und bisher haben wir keine SPF-Fehler festgestellt, die durch die Verwendung des ptr-Mechanismus entstehen.
Wie funktioniert SPF Authentication?
So sieht ein typischer SMTP-Transaktion aus, wenn SPF im Spiel ist:
Der sendende Server (Client) verbindet sich mit dem empfangenden Server
Der empfangende Server notiert die IP-Adresse des verbindenden Clients
Sie tauschen Begrüßungen aus, einschließlich des HELO-Hostnamens des Clients
Der Client gibt den SMTP MAIL FROM-Befehl aus
Der empfangende Server kann nun den SPF-Eintrag entweder für die MAIL FROM-Domain oder den HELO-Hostnamen abfragen, um festzustellen, ob die verbindende IP berechtigt ist, E-Mails für die Domain zu senden, und entscheiden, ob die Nachricht akzeptiert wird oder nicht.
So sieht ein typischer SMTP-Transaktion aus, wenn SPF im Spiel ist:
Der sendende Server (Client) verbindet sich mit dem empfangenden Server
Der empfangende Server notiert die IP-Adresse des verbindenden Clients
Sie tauschen Begrüßungen aus, einschließlich des HELO-Hostnamens des Clients
Der Client gibt den SMTP MAIL FROM-Befehl aus
Der empfangende Server kann nun den SPF-Eintrag entweder für die MAIL FROM-Domain oder den HELO-Hostnamen abfragen, um festzustellen, ob die verbindende IP berechtigt ist, E-Mails für die Domain zu senden, und entscheiden, ob die Nachricht akzeptiert wird oder nicht.
So sieht ein typischer SMTP-Transaktion aus, wenn SPF im Spiel ist:
Der sendende Server (Client) verbindet sich mit dem empfangenden Server
Der empfangende Server notiert die IP-Adresse des verbindenden Clients
Sie tauschen Begrüßungen aus, einschließlich des HELO-Hostnamens des Clients
Der Client gibt den SMTP MAIL FROM-Befehl aus
Der empfangende Server kann nun den SPF-Eintrag entweder für die MAIL FROM-Domain oder den HELO-Hostnamen abfragen, um festzustellen, ob die verbindende IP berechtigt ist, E-Mails für die Domain zu senden, und entscheiden, ob die Nachricht akzeptiert wird oder nicht.
MAIL FROM oder HELO – Welches sollte geprüft werden?
Die SPF-Spezifikation legt fest, dass empfangende Sites SPF für die MAIL FROM-Domain überprüfen MÜSSEN und EMPFIEHLEN, sie für den HELO-Hostname zu überprüfen. In der Praxis erfolgt die Überprüfung nur auf der MAIL FROM-Domain, außer vielleicht in den Fällen, in denen die MAIL FROM-Adresse der NULL-Absender (d.h. „<>“) ist, in welchem Fall der HELO-Hostname die einzige verfügbare Identität ist.
Die SPF-Spezifikation legt fest, dass empfangende Sites SPF für die MAIL FROM-Domain überprüfen MÜSSEN und EMPFIEHLEN, sie für den HELO-Hostname zu überprüfen. In der Praxis erfolgt die Überprüfung nur auf der MAIL FROM-Domain, außer vielleicht in den Fällen, in denen die MAIL FROM-Adresse der NULL-Absender (d.h. „<>“) ist, in welchem Fall der HELO-Hostname die einzige verfügbare Identität ist.
Die SPF-Spezifikation legt fest, dass empfangende Sites SPF für die MAIL FROM-Domain überprüfen MÜSSEN und EMPFIEHLEN, sie für den HELO-Hostname zu überprüfen. In der Praxis erfolgt die Überprüfung nur auf der MAIL FROM-Domain, außer vielleicht in den Fällen, in denen die MAIL FROM-Adresse der NULL-Absender (d.h. „<>“) ist, in welchem Fall der HELO-Hostname die einzige verfügbare Identität ist.
