SPF (Sender Policy Framework)
SPF (Sender Policy Framework) ist ein E-Mail-Authentifizierungsprotokoll, das als DNS-Eintrag festlegt, welche Mailserver berechtigt sind, E-Mails im Namen einer Domain zu versenden. Empfangende Server prüfen anhand dieses Eintrags, ob eine E-Mail von einem autorisierten Absender stammt.
Ausführliche Erklärung
SPF funktioniert über einen sogenannten SPF-Record, einen TXT-Eintrag im Domain Name System (DNS), der alle autorisierten IP-Adressen und Mailserver auflistet, die für eine bestimmte Domain E-Mails versenden dürfen. Wenn ein empfangender Mailserver eine E-Mail erhält, prüft er den SPF-Eintrag der Absender-Domain und vergleicht die sendende IP-Adresse mit der autorisierten Liste. Stimmen die Angaben nicht überein, schlägt die SPF-Prüfung fehl und die E-Mail wird je nach Konfiguration als Spam markiert oder abgelehnt.
Für KMU ist SPF aus zwei Gründen relevant: Erstens schützt ein korrekt konfigurierter SPF-Eintrag die eigene Domain davor, dass Kriminelle sie für Phishing-Angriffe oder Spam-Kampagnen missbrauchen. Ohne SPF kann jeder beliebige Server im Internet vorgeben, E-Mails im Namen Ihrer Domain zu versenden. Zweitens verbessert SPF die Zustellbarkeit legitimer E-Mails erheblich – insbesondere seit 2024, als Microsoft und Google begonnen haben, E-Mails von Domains ohne korrekte SPF-Einträge vermehrt als Spam zu behandeln oder ganz abzulehnen.
SPF arbeitet nicht isoliert, sondern ist Teil eines dreistufigen E-Mail-Sicherheitskonzepts. Zusammen mit DKIM (DomainKeys Identified Mail), das E-Mails kryptografisch signiert, und DMARC (Domain-based Message Authentication, Reporting and Conformance), das Handlungsanweisungen für fehlgeschlagene Prüfungen gibt, bildet SPF eine umfassende Schutzstrategie gegen E-Mail-Spoofing.
Die Implementierung erfordert Zugang zur DNS-Verwaltung der eigenen Domain. Dabei müssen alle legitimen Versandquellen erfasst werden – vom eigenen Mailserver über Newsletter-Tools bis hin zu CRM-Systemen. Wichtig ist, dass pro Domain nur ein einziger SPF-Record existieren darf, da mehrere Einträge zu Konflikten führen. Nach der Einrichtung sollte der SPF-Eintrag regelmäßig aktualisiert werden, insbesondere wenn neue E-Mail-Dienste hinzukommen oder Dienstleister wechseln.
Praxisbeispiel
Eine Steuerberatungskanzlei mit 12 Mitarbeitenden in Linz versendet E-Mails über drei Quellen: den eigenen Exchange-Server, ein Newsletter-Tool für Mandanteninformationen und ein CRM-System für automatisierte Terminbestätigungen. Der IT-Dienstleister richtet einen SPF-Record ein, der alle drei IP-Adressen enthält. Dadurch werden E-Mails der Kanzlei von Gmail, Outlook und anderen Anbietern nicht mehr fälschlicherweise als Spam eingestuft, und gleichzeitig ist die Domain gegen Missbrauch durch Phishing-Angreifer geschützt.
Code-Beispiel
## Beispiel eines SPF-Records als DNS TXT-Eintrag
# Grundstruktur
v=spf1 ip4:203.0.113.42 include:_spf.mailprovider.com ~all
# Erklärung:
# v=spf1 → SPF-Version 1
# ip4:203.0... → Autorisierte IPv4-Adresse
# include:... → Autorisierung externer Dienste
# ~all → Softfail (verdächtig, aber nicht ablehnen)
# -all → Hardfail (strikt ablehnen)
# Praxisbeispiel KMU mit mehreren Quellen
v=spf1 ip4:203.0.113.42 include:spf.mailjet.com include:_spf.google.com ~all