Was ist SPF (Sender Policy Framework)?

Definition

Das Sender Policy Framework ist einer der drei zentralen E-Mail-Authentifizierungsstandards, neben DKIM und DMARC. Es geht eine grundlegende Schwäche von E-Mail an: Standardmäßig kann jeder eine Nachricht senden, die vorgibt, von irgendeiner Domain zu kommen, weil die ursprünglichen Mailprotokolle nie eine Möglichkeit eingebaut haben zu beweisen, wer der echte Absender ist. SPF schließt einen Teil dieser Lücke, indem es einem Domaininhaber eine Möglichkeit gibt, öffentlich und in maschinenlesbarer Form zu erklären, welche Server genau Mail im Namen der Domain senden dürfen.

Diese Erklärung liegt im Domain Name System, demselben globalen Verzeichnis, das Domainnamen in Netzwerkadressen übersetzt. Der Domaininhaber veröffentlicht einen speziellen DNS-Record, der die autorisierten Absender benennt. Wenn eine Nachricht eingeht, schlägt der empfangende Mailserver diesen Record nach und vergleicht ihn mit dem Server, der die Nachricht tatsächlich zugestellt hat. Steht der sendende Server auf der Liste, besteht die Nachricht SPF. Steht er nicht darauf, scheitert die Nachricht an SPF, was ein starker Hinweis darauf ist, dass die Mail gefälscht sein könnte. SPF verschlüsselt nichts und prüft nicht den Nachrichteninhalt. Es beantwortet eine fokussierte Frage: Wurde diese Nachricht von einem Server gesendet, den der Domaininhaber genehmigt hat?

So funktioniert es

Eine SPF-Richtlinie wird als einzelner DNS-TXT-Record auf der Domain veröffentlicht. Der Record beginnt immer mit dem Versions-Tag v=spf1, gefolgt von einer Reihe von Mechanismen, die autorisierte Absender beschreiben, und endet normalerweise mit einem all-Mechanismus, der das Standardergebnis festlegt. Ein einfacher Record könnte v=spf1 include:_spf.google.com -all lauten, was Google-Workspace-Mailserver autorisiert und alles andere ablehnt.

Die Mechanismen sind die Bausteine. Die Mechanismen ip4 und ip6 autorisieren bestimmte Adressen oder Adressbereiche direkt. Der Mechanismus a autorisiert die Server, die in den Adress-Records der Domain stehen, und mx autorisiert die Server, die als Mail-Exchanger der Domain gelistet sind. Der Mechanismus include ist in der Praxis der häufigste, da er die SPF-Richtlinie eines anderen Anbieters einbindet, was die Art ist, wie eine Domain den Versand an Dienste wie Google, Microsoft oder eine E-Mail-Plattform delegiert. Jeder Mechanismus kann einen Qualifier tragen, der das Ergebnis bei einer Übereinstimmung festlegt. Ein Pluszeichen, das der Standard ist, bedeutet Pass. Ein Minuszeichen bedeutet Fail, eine Tilde bedeutet Softfail, also eine sanfte Warnung, und ein Fragezeichen bedeutet Neutral. Der all-Mechanismus am Ende fängt jeden Server ab, der nicht übereinstimmte, sodass -all eine harte Ablehnung von allem Ungelisteten ist, während ~all ein sanfteres Signal ist.

Wenn ein empfangender Server SPF auswertet, prüft er die Envelope-From-Adresse, also den während des SMTP-Austauschs deklarierten Return-Path, und bei Bounce-Nachrichten mit leerem Return-Path prüft er stattdessen die HELO-Identität. Der Standard legt eine wichtige Einschränkung fest: Die Auswertung eines Records darf nicht mehr als zehn DNS-Abfragen nutzen, und Mechanismen wie include, a, mx und exists verbrauchen jeweils eine. Braucht ein Record mehr als zehn, erzeugt er einen PermError, den Empfänger als Fehler werten können, sodass SPF-Records kompakt gehalten werden müssen. SPF hat außerdem strukturelle Grenzen. Es bricht, wenn Mail weitergeleitet wird, weil der weiterleitende Server nicht auf der Liste der ursprünglichen Domain steht, und es validiert entscheidenderweise nur die Envelope-From-Adresse, nicht die sichtbare From-Adresse, die ein Empfänger tatsächlich sieht.

Warum das für die E-Mail-Zustellbarkeit wichtig ist

SPF ist heute eine Grundvoraussetzung statt eines optionalen Extras. Mailbox-Anbieter werten eine bestandene SPF-Prüfung als positives Vertrauenssignal und einen fehlenden oder scheiternden Record als Grund zum Misstrauen, was direkt beeinflusst, ob Mail im Posteingang oder im Spam-Ordner landet. Seit den 2024 von Google und Yahoo eingeführten Absenderanforderungen wird von Massenversendern erwartet, dass sie sich mit SPF authentifizieren, und eine Domain ohne gültigen SPF-Record kann erleben, dass ihre Mail gedrosselt oder komplett abgelehnt wird.

SPF ist auch deshalb wichtig, weil es eine Voraussetzung für DMARC ist, die Richtlinienschicht, die die Authentifizierung an die sichtbare From-Adresse bindet. DMARC funktioniert, indem es prüft, ob SPF oder DKIM bestanden wurde und ob das Ergebnis mit der From-Domain übereinstimmt. Ohne einen korrekt konfigurierten SPF-Record kann eine Domain keine DMARC-Ausrichtung über SPF erreichen, was ihren Gesamtschutz schwächt. Gleichzeitig ist es wichtig, realistisch zu sein, was SPF nicht kann. Weil es den sichtbaren From-Header ignoriert und beim Weiterleiten bricht, kann SPF allein einen entschlossenen Spoofer nicht stoppen. Es ist eine notwendige Schicht einer dreischichtigen Verteidigung und entfaltet seinen vollen Wert nur, wenn DKIM und DMARC daneben stehen.

So geht VeriMails damit um

SPF und E-Mail-Verifizierung lösen zwei verschiedene Hälften desselben Zustellbarkeitsproblems. SPF authentifiziert die Mail, die du sendest, damit empfangende Server darauf vertrauen, dass sie wirklich von dir kam. Die E-Mail-Verifizierung bereinigt die Liste, an die du sendest, sodass du immer nur echte, erreichbare Adressen anschreibst. Eine starke Posteingang-Platzierung braucht beides im Zusammenspiel, und keines von beiden ersetzt das andere.

VeriMails konzentriert sich auf die Empfängerseite. Jede Adresse, die du einreichst, wird über Syntaxprüfung, eine MX- und DNS-Abfrage, einen Live-SMTP-Handshake, Catch-All-Erkennung, Erkennung von Wegwerfadressen und Erkennung rollenbasierter Adressen geprüft, sodass ungültige Adressen entfernt werden, bevor sie einen Bounce erzeugen und eine Reputation herunterziehen können, die gute SPF-, DKIM- und DMARC-Records schützen sollen. Um auch auf der Authentifizierungsseite zu helfen, bietet VeriMails einen kostenlosen SPF-Generator, der einen syntaktisch korrekten Record für deine Domain und deine Versanddienste erstellt und ihn innerhalb des Zehn-Abfragen-Limits hält. Du kannst eine Liste über die REST API oder einen CSV-Massen-Upload verifizieren, mit klaren Zustellbarkeitskategorien für deine Kampagnenentscheidungen. Die Verifizierung beginnt bei $0.0019 pro E-Mail, mit 10,000 Credits für $19 und Jahresplänen ab $12.50/month bei jährlicher Abrechnung, und jedes Konto startet mit 100 kostenlosen Credits, ohne Kreditkarte, die nie verfallen.

Häufig gestellte Fragen