Im Jahr 2014 wachte ein kleines E-Commerce-Unternehmen auf und stellte fest, dass jemand 50.000 Phishing-E-Mails an seine Kunden geschickt hatte – alle scheinbar von der offiziellen Domain. Die E-Mails sahen legitim aus. Die From-Adresse war korrekt. Kunden klickten, gaben ihre Kreditkartendaten ein, und das Unternehmen verbrachte die nächsten sechs Monate damit, das Vertrauen wieder aufzubauen, das sie über Jahre hinweg verdient hatten.
Der Angriff war aufgrund eines einzigen fehlenden DNS-Eintrags möglich: SPF.
SPF—Sender Policy Framework—gehört zu den Dingen, die technisch und langweilig klingen, bis man versteht, was sie tatsächlich tun. Es ist der Unterschied zwischen „Jeder kann E-Mails als dich senden“ und „Nur deine autorisierten Server dürfen das.“ Das digitale Äquivalent zu einem Türsteher, der am Eingang Ausweise kontrolliert.
Das Problem, das SPF löst
Hier ist eine unbequeme Wahrheit über E-Mail: Die 'From'-Adresse, die du siehst, ist im Grunde eine Selbstangabe. Wenn du eine E-Mail von [email protected] erhältst, gibt es im E-Mail-Protokoll nichts, was beweist, dass sie wirklich von den Servern von Big Company stammt. Der Absender behauptet es einfach.
Das ist, als könnte jeder eine beliebige Absenderadresse auf einen Brief schreiben. Du könntest einen Brief versenden und behaupten, er käme aus dem Weißen Haus, und die Post würde ihn ohne Nachfragen zustellen. Genau so funktionierte E-Mail jahrzehntelang – und deshalb wurde Phishing zu einem massiven Problem.
SPF ändert das, indem Domaininhaber eine Liste autorisierter Absender veröffentlichen. Wenn eine E-Mail ankommt und behauptet, von deiner Domain zu sein, kann der empfangende Server prüfen: „Kam das wirklich von einem Server, der für diese Domain senden darf?“ Wenn nicht, wird die E-Mail markiert oder abgelehnt.
Wie es in der Praxis funktioniert
Verfolgen wir, was passiert, wenn du eine E-Mail von deiner Firmendomain sendest – vorausgesetzt, SPF ist korrekt eingerichtet.
Du verfasst eine E-Mail in Gmail oder deinem E-Mail-Client und klickst auf Senden. Deine E-Mail gelangt zu deinem Firmenmailserver (oder dem Server deines E-Mail-Providers), der sich mit dem Mailserver des Empfängers verbindet. An diesem Punkt sieht der Server des Empfängers zwei Dinge: die IP-Adresse des Servers, der die E-Mail zustellen will, und die Domain in der 'From'-Adresse.
Der Server des Empfängers führt dann eine DNS-Abfrage für den SPF-Eintrag deiner Domain aus. Dieser Eintrag enthält eine Liste von IP-Adressen und Domains, die berechtigt sind, in deinem Namen E-Mails zu senden. Wenn die IP des verbundenen Servers zu etwas in dieser Liste passt, besteht die E-Mail den SPF-Check. Wenn nicht, fällt sie durch.
Die gesamte Prüfung dauert Millisekunden. Der Absender merkt nicht einmal, dass sie stattgefunden hat. Aber diese einfache Abfrage entscheidet darüber, ob deine E-Mail im Posteingang landet oder als potenzieller Betrug markiert wird.
Einen SPF-Eintrag lesen
SPF-Einträge leben in deinem DNS als TXT-Records. Hier ist ein Beispiel aus der Praxis:
Das wirkt kryptisch, ist aber eigentlich unkompliziert, wenn man die Syntax kennt. Zerlegen wir es Schritt für Schritt.
Das 'v=spf1' am Anfang deklariert dies als SPF-Eintrag (Version 1 – es gab nur diese eine Version). Alles danach ist eine Liste derer, die senden dürfen.
'include:_spf.google.com' bedeutet „Suche den SPF-Eintrag von Google und vertraue den Servern, die sie dort auflisten.“ So autorisierst du Google Workspace, E-Mails für deine Domain zu senden, ohne jede einzelne Google-IP-Adresse auflisten zu müssen (das wären Hunderte).
'include:amazonses.com' macht dasselbe für Amazon SES. Wenn du SES für transaktionale E-Mails nutzt, autorisiert das deren Server.
'ip4:203.0.113.42' autorisiert direkt eine spezifische IP-Adresse. Vielleicht ist das dein eigener Mailserver oder ein Altsystem, das Berichte versendet.
Das '-all' am Ende ist entscheidend. Es bedeutet „Alles ablehnen, was nicht zu den obigen Regeln passt.“ Das nennt man einen „Hard Fail“. Du könntest auch '~all' sehen (Soft Fail, markiert Fehler als verdächtig, lehnt aber nicht ab) oder '?all' (neutral, im Wesentlichen „Ich weiß es nicht, mach, was du willst“). Für echte Sicherheit willst du '-all'.
Das 10-Lookup-Limit
Hier wird SPF knifflig – und viele Unternehmen laufen genau hier in Probleme.
Jede 'include'-Anweisung löst eine DNS-Abfrage aus. Und SPF hat ein hartes Limit von 10 DNS-Lookups pro Prüfung. Überschreitest du das, ist dein SPF-Eintrag ungültig – was bedeutet, dass alle deine E-Mails an SPF scheitern, sogar die von legitimen Servern.
Dieses Limit existiert, weil SPF-Prüfungen in Echtzeit während der E-Mail-Zustellung stattfinden. Wenn ein Angreifer einen SPF-Eintrag erstellen könnte, der Hunderte von DNS-Abfragen auslöst, könnte er das als Denial-of-Service-Angriff gegen die DNS-Infrastruktur missbrauchen. Das 10-Lookup-Limit verhindert das.
Das Problem ist, dass moderne Unternehmen viele Dienste nutzen, die E-Mails senden: Google Workspace, eine Marketingplattform, ein transaktionaler E-Mail-Dienst, ein Kundensupport-Tool, vielleicht ein HR-System. Jeder benötigt eine 'include'-Anweisung, und jedes 'include' kann wiederum weitere 'includes' enthalten. Allein der SPF-Eintrag von Google kann 3-4 Lookups verbrauchen.
Wenn du an die Grenze stößt, hast du einige Optionen. Du kannst SPF-Flattening-Services nutzen, die alle Includes in direkte IP-Adressen auflösen (das erfordert allerdings Pflege, da sich IPs ändern). Du kannst dein E-Mail-Versenden über weniger Anbieter konsolidieren. Oder du nutzt Subdomains – marketing.yourcompany.com für Marketing-E-Mails, support.yourcompany.com für Support – jeweils mit eigenem SPF-Eintrag.
Die Grenzen von SPF
SPF ist essenziell, aber keine vollständige Lösung. Wer seine Grenzen versteht, baut eine richtige E-Mail-Authentifizierungsstrategie.
Erstens prüft SPF die 'envelope from'-Adresse (die technische Return-Adresse), nicht die 'header from'-Adresse (die, die Empfänger sehen). Ein Angreifer kann SPF bestehen und trotzdem dem Empfänger eine gefälschte Adresse anzeigen. Deshalb gibt es DMARC – es verknüpft die Ergebnisse von SPF und DKIM mit der sichtbaren 'From'-Adresse.
Zweitens funktioniert SPF nicht bei weitergeleiteten E-Mails. Wenn jemand deine E-Mail an eine andere Adresse weiterleitet, ist die IP des weiterleitenden Servers nicht in deinem SPF-Eintrag, sodass die weitergeleitete E-Mail an SPF scheitert. Das ist eine grundlegende Einschränkung des Protokolls und der Grund, warum DKIM (das den Inhalt der E-Mail signiert) als Ergänzung wichtig ist.
Drittens sagt SPF empfangenden Servern nur dann, was sie mit Fehlermeldungen tun sollen, wenn du '-all' verwendest. Viele Domains nutzen '~all' oder '?all', weil sie Angst haben, legitime E-Mails zu blockieren. Aber das bedeutet, dass Angreifer weiterhin gefälschte E-Mails senden können – sie werden nur als verdächtig markiert, statt abgelehnt.
SPF richtig einrichten
SPF aufzusetzen ist nicht schwer, aber es richtig zu machen erfordert etwas Überlegung. So gehst du vor.
Beginne damit, jeden Dienst zu prüfen, der E-Mails von deiner Domain sendet. Das ist meist mehr, als du denkst. Dein E-Mail-Provider, klar. Aber auch dein Marketing-Automation-Tool, dein transaktionaler E-Mail-Dienst, dein CRM, dein Support-Desk, dein Rechnungsstellungssystem, vielleicht sogar dein Drucker (manche senden Scan-to-Email). Erstelle eine vollständige Liste.
Suche für jeden Dienst nach dessen SPF-include-Statement. Das steht meist in der Dokumentation unter „E-Mail-Authentifizierung“ oder „DNS-Setup“. Füge jedes davon zu deinem SPF-Eintrag hinzu.
Starte mit '~all' (Soft Fail) statt '-all' (Hard Fail). So kannst du Probleme überwachen, ohne legitime E-Mails zu blockieren. Beobachte deine DMARC-Berichte (du sammelst DMARC-Berichte, oder?) auf SPF-Fehler. Wenn du siehst, dass legitime Dienste scheitern, nimm sie in deinen Eintrag auf.
Wenn du ein paar Wochen ohne unerwartete Fehler hinter dir hast, wechsle zu '-all'. Erst dann beginnt SPF, dich wirklich zu schützen. Bis dahin ist es nur eine Empfehlung.
Setze dir schließlich eine Kalendererinnerung, deinen SPF-Eintrag vierteljährlich zu überprüfen. Dienste ändern sich, du fügst neue Tools hinzu, IPs rotieren. Ein veralteter SPF-Eintrag ist fast so schlecht wie gar keiner.
Frequently asked questions
Mein SPF-Eintrag ist korrekt, aber E-Mails landen trotzdem im Spam. Warum?
SPF ist nur ein Faktor bei der Zustellbarkeit. Spamfilter berücksichtigen auch die Reputation deiner Domain, die Reputation der IP, den Inhalt der E-Mail, Engagement-Raten und ob du DKIM und DMARC eingerichtet hast. Ein bestandener SPF-Check garantiert keinen Platz im Posteingang – er bedeutet nur, dass du eine Hürde genommen hast.
Kann ich mehrere SPF-Einträge für eine Domain haben?
Nein, und das ist ein häufiger Fehler. Wenn du mehrere TXT-Records hast, die mit 'v=spf1' beginnen, schlagen SPF-Prüfungen fehl. Du brauchst genau einen SPF-Eintrag, der alle deine autorisierten Absender enthält.
Was passiert, wenn ich das 10-Lookup-Limit überschreite?
Dein SPF-Eintrag wird ungültig, und alle SPF-Prüfungen liefern 'permerror'. Die meisten empfangenden Server behandeln das wie einen SPF-Fehler, was deiner Zustellbarkeit schaden kann. Nutze ein SPF-Checker-Tool, um deine Lookups zu zählen, bevor du Änderungen veröffentlichst.
Soll ich -all oder ~all verwenden?
Nutze ~all während der Einrichtung und Tests. Sobald du sicher bist, dass dein SPF-Eintrag alle legitimen Absender enthält, wechsle zu -all. Der Soft Fail (~all) schützt dich nicht wirklich vor Spoofing – er markiert verdächtige E-Mails, lehnt sie aber nicht ab.