SPF-Record

Definition

Ein SPF-Record (Sender Policy Framework Record) ist ein DNS-TXT-Resource-Record, der in der öffentlichen DNS-Zone einer Domain veröffentlicht wird und die IP-Adressen, IPv6-Präfixe und Mailserver-Hostnamen aufzählt, die autorisiert sind, im Namen dieser Domain E-Mails zu versenden. Wenn ein empfangender Mailserver eine eingehende Nachricht akzeptiert, fragt er den DNS des Absenders nach dem SPF-Record ab und vergleicht die verbindende IP-Adresse mit der Policy. Ist die IP nicht aufgeführt, kann der empfangende Server die Nachricht als Softfail markieren, direkt ablehnen oder zur weiteren Bewertung kennzeichnen — abhängig vom Policy-Qualifier des Domain-Eigentümers^[1].

SPF wurde erstmals als IETF-Standard in RFC 4408 (2006) formalisiert und später auf die aktuelle maßgebliche Spezifikation in RFC 7208 aktualisiert, die im April 2014 von der Internet Engineering Task Force (IETF) veröffentlicht wurde. Es ist einer von drei komplementären E-Mail-Authentifizierungsstandards neben DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting, and Conformance).

Funktionsweise

Der SPF-Auswertungsprozess umfasst mehrere sequenzielle Schritte, die von der SMTP-Engine des empfangenden Mailservers während der MAIL-FROM-Phase des SMTP-Handshakes ausgeführt werden.

Der Domain-Eigentümer veröffentlicht einen SPF-TXT-Record im DNS. Ein typischer Record folgt dieser Syntax: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Die Komponenten sind: v=spf1 (Versionsidentifikator), ein oder mehrere Mechanismen (include, ip4, ip6, a, mx, exists) und ein abschließender Qualifier (+all, -all, ~all, ?all). Der -all-Qualifier bedeutet einen Hard Fail — jeder nicht ausdrücklich aufgeführte Server ist nicht autorisiert. Der ~all-Qualifier (Softfail) lässt die Nachricht passieren, vermerkt aber die Policy-Diskrepanz; üblich während Migrationsphasen.

Wenn eine Nachricht eintrifft, extrahiert der empfangende MTA (Mail Transfer Agent) die Envelope-Sender-Domain (die MAIL-FROM-Adresse, auch RFC5321.MailFrom-Adresse genannt) und führt einen DNS-TXT-Lookup für _spf.<domain> oder direkt auf der Domain-Wurzel durch. Die SPF-Bibliothek wertet jeden Mechanismus der Reihe nach aus, bis eine Übereinstimmung gefunden wird oder das Limit von zehn DNS-Lookups erreicht ist (das in RFC 7208 Abschnitt 4.6.4 definierte „SPF PermError”-Limit). Das Ergebnis — Pass, Fail, SoftFail, Neutral, TempError oder PermError — wird in den Received-SPF-Header der Nachricht eingefügt und an den Spam-Filter und jede DMARC-Policy-Engine übergeben.

Wichtig zu beachten: SPF authentifiziert den Envelope-Sender (MAIL FROM), nicht den sichtbaren From-Header im Nachrichtentext. Diese Unterscheidung bedeutet, dass SPF allein kein Display-Name-Spoofing in E-Mail-Clients verhindert — weshalb DMARC-Ausrichtung, die verlangt, dass SPF- und/oder DKIM-Ergebnisse mit der RFC5322.From-Domain übereinstimmen, für vollständigen Schutz erforderlich ist.

Wo Sie ihm begegnen

SPF-Records erscheinen in jedem Kontext, in dem E-Mail-Zustellbarkeit und Sender-Reputation eine Rolle spielen. Transaktionale E-Mail-Infrastruktur, betrieben von Diensten wie Amazon SES, SendGrid, Mailgun, Postmark und SparkPost, verlangt von Domain-Eigentümern, SPF-include-Mechanismen hinzuzufügen, die auf die Sendeinfrastruktur des Anbieters verweisen, bevor Nachrichten Authentifizierungsprüfungen bestehen^[2].

Wettbewerbsplattformen, die E-Mail-Bestätigungsabstimmungen versenden — einschließlich Woobox, ShortStack und maßgeschneiderter Systeme, die Mailchimp Transactional (Mandrill) verwenden — sind darauf angewiesen, dass die sendende Domain einen gültigen SPF-Record besitzt. Mailbox-Anbieter wie Google (Gmail), Microsoft (Outlook / Exchange Online Protection) und Yahoo Mail bewerten SPF als Eingang in ihre Zustellbarkeitsalgorithmen. Ein fehlender oder fehlkonfigurierter SPF-Record erhöht die Wahrscheinlichkeit erheblich, dass Bestätigungs-E-Mails stillschweigend in Spam-Ordner zugestellt oder vollständig abgelehnt werden — wodurch Stimmen unbestätigt bleiben.

DNS-Hosting-Panels von Anbietern wie Cloudflare, AWS Route 53, GoDaddy und Namecheap stellen SPF-TXT-Record-Bearbeitung über ihre Verwaltungsoberflächen bereit. Diagnosetools wie MXToolbox SPF Lookup, Google Admin Toolbox und der SPF Surveyor von DMARCIAN ermöglichen Domain-Eigentümern, veröffentlichte Records zu inspizieren und zu validieren.

Praktische Beispiele

Eine Wettbewerbsplattform versendet Stimmbestätigungs-E-Mails von [email protected]. Die Domain votes.example.com hat den SPF-Record v=spf1 include:sendgrid.net -all. Wenn Gmail eine Bestätigungsnachricht empfängt, fragt sein eingehender SMTP-Server das DNS nach dem SPF-Record von votes.example.com ab, expandiert den sendgrid.net-Include-Mechanismus und prüft die verbindende IP gegen SendGrids autorisierte Serverliste. Stimmt die IP überein, lautet das SPF-Ergebnis Pass und die Nachricht gelangt in den Posteingang. Hätte die Domain keinen SPF-Record, würde der Filter von Gmail die Nachricht als nicht authentifiziert behandeln und die Wahrscheinlichkeit der Inbox-Platzierung reduzieren.

Ein Regionalzeitungs-Wettbewerb wechselt seinen transaktionalen E-Mail-Anbieter von Mailchimp zu Amazon SES, ohne den SPF-Record zu aktualisieren. Bestätigungs-E-Mails beginnen, SPF-Prüfungen bei Microsoft Outlook zu scheitern, und werden in den Spam-Ordner verschoben — wodurch Wähler das Bestätigungsfenster verpassen. Der Wettbewerbsadministrator diagnostiziert das Problem mit MXToolbox, fügt include:amazonses.com zum SPF-Record hinzu, und die Zustellbarkeit erholt sich innerhalb des DNS-Propagationsfensters (typischerweise 0–48 Stunden je nach TTL-Einstellungen).

Verwandte Konzepte

SPF ist eine Säule des Drei-Standard-E-Mail-Authentifizierungsstacks: Siehe DKIM für kryptografische Signaturverifizierung und DMARC für die Policy-Schicht, die auf Basis der SPF- und DKIM-Ergebnisse handelt. Die praktischen Auswirkungen auf den Wettbewerbsbetrieb werden in Email Confirmation Vote beschrieben, wo die Zustellbarkeit der Bestätigungsnachricht die kritischste operative Abhängigkeit ist. BIMI (Brand Indicators for Message Identification), ein neuerer Standard, der auf DMARC aufbaut, erlaubt verifizierten Versendern, ein Markenlogo in unterstützenden Mailbox-Anbietern anzuzeigen — ein aufkommendes Vertrauenssignal, das hier nicht abgedeckt wird.

Quellen

1. IETF RFC 7208 — Sender Policy Framework: https://www.rfc-editor.org/rfc/rfc7208
2. MXToolbox SPF Lookup: https://mxtoolbox.com/spf.aspx
3. Wikipedia — Sender Policy Framework: https://en.wikipedia.org/wiki/Sender_Policy_Framework