ExchangeServer
SPF (Sender Policy Framework)
Overview
Das Sender Policy Framework (SPF) ist in RFC 7208 (April 2014, Proposed Standard) beschrieben. Der Domaininhaber veröffentlicht im DNS eine Liste der erlaubten Absenderserver. Der empfangende Server prüft die Absenderadresse aus dem SMTP-Umschlag (MAIL FROM, auch Envelope From oder Return-Path) und optional den HELO-Namen.
SPF prüft nicht die im Mailprogramm sichtbare Absenderadresse (Header From). Deshalb schützt SPF allein nicht vor Fälschungen der sichtbaren Adresse, erst DMARC verknüpft das Ergebnis mit dem Header From. Weiterleitungen brechen SPF häufig, weil der weiterleitende Server nicht im Eintrag steht.
SPF ist heute Voraussetzung für die Zustellung bei großen Anbietern: Google und Yahoo verlangen es seit Februar 2024 von Massenversendern, Microsoft für Outlook.com, Hotmail.com und Live.com seit 5. Mai 2025 bei mehr als 5.000 Mails pro Tag.
How it works
Der SPF-Eintrag ist ein TXT-Record nach dem Schema v=spf1 [Mechanismen] [Abschlussregel]:
- Mechanismen nennen erlaubte Quellen: ip4 und ip6 für Adressen, include für Dienste wie Exchange Online (include:spf.protection.outlook.com), a und mx für Hosts der Domain.
- Die Abschlussregel legt fest, was mit allen übrigen Quellen passiert: -all (Hardfail, von Microsoft empfohlen), ~all (Softfail) oder ?all (neutral, nur für Tests).
- Der Empfänger ruft den Eintrag der Umschlag-Domain ab und prüft, ob die sendende IP passt. Ergebnisse sind unter anderem pass, fail, softfail, neutral, permerror und temperror.
- Nach RFC 7208 sind höchstens zehn DNS-abfragende Mechanismen (include, a, mx, ptr, exists, redirect) pro Prüfung erlaubt, sonst ergibt sich permerror.
Pro Domain darf es nur einen SPF-Eintrag geben, Subdomains brauchen eigene Einträge.
Benefits
- Ohne Software umsetzbar, weil nur ein DNS-Eintrag nötig ist
- Erschwert das Fälschen der Domain im Mailumschlag
- Grundlage für DMARC, das SPF und DKIM gemeinsam auswertet
- Voraussetzung für gute Zustellbarkeit bei Google, Yahoo und Outlook.com
Practical example
Ein Unternehmen versendet Mails über Exchange Online, ein Newsletter-Tool und das CRM. Die IT führt alle drei Quellen in einem SPF-Eintrag zusammen, prüft mit einem Analysewerkzeug die Zahl der DNS-Abfragen und verlagert den Newsletter auf eine eigene Subdomain mit eigenem SPF-Eintrag. Nachdem die DMARC-Berichte keine unbekannten Absender mehr zeigen, stellt sie die Abschlussregel von ~all auf -all um.
Things to keep in mind
- Pro Domain nur einen SPF-Eintrag pflegen, mehrere Einträge führen zu permerror
- Die Grenze von zehn DNS-Abfragen beachten, besonders bei vielen include-Einträgen von Drittdiensten
- Alle legitimen Absender erfassen, auch Marketing-Tools, CRM, Ticketsysteme, Scanner und Drucker
- spf.protection.outlook.com nicht in IP-Adressen auflösen (flatten), weil sich Microsofts Adressen häufig ändern
- Für Domains ohne Mailversand v=spf1 -all setzen, damit sie nicht für Fälschungen taugen
Conclusion
SPF gehört zur Grundausstattung jeder Maildomain und ist schnell umgesetzt. Allein genügt es nicht, erst mit DKIM und DMARC entsteht ein belastbarer Schutz vor Spoofing.
Further reading
Related articles
Microsoft 365
Exchange Online Hardening | Security & Privacy Best Practices
Microsoft 365
Microsoft Purview | Data Lifecycle Management: Retention Labels
Microsoft 365
Microsoft Purview | Data Lifecycle Management: Publish labels (Label Policy)
Microsoft 365