Sender Policy Framework (afgekort SPF) is een protocol dat tot doel heeft spam te verminderen. Men hoopt e-mail spoofing en spam te verminderen door vast te stellen of de verzender van een e-mailbericht gerechtigd is te verzenden namens de vermelde afzender van het bericht. De procedure is vastgelegd in RFC 7208.
SPF vereist het gebruik van een TXT-record in de DNS-server waarin wordt aangegeven welke servers berichten mogen sturen namens een domeinnaam:
v=spf1 mx include:mijn.example.nl ip4:1.2.3.4 ip6:FFFF::0000 -all
Het bovenstaande voorbeeld is de simpelste implementatie van SPF die beschikbaar is. Hierin staan verschillende gegevens:
v=spf1 Sender Policy Framework versie = SPF1,mx Alle mailservers mogen sturen (deze worden in DNS opgenomen in de MX-record)include:mijn.example.nl Accepteer alles wat het SPF-record van het domein mijn.example.nl accepteertip4:1.2.3.4 Email verstuurd vanaf het IPv4-adres 1.2.3.4 moet geaccepteerd wordenip6:FFFF::0000 Email verstuurd vanaf het IPv6-adres FFFF::0000 moet geaccepteerd worden-all Hiermee wordt aangegeven dat alle andere mail niet legitiem is.Een ontvangende mailserver kijkt naar het domein van de MAIL FROM- of Return-Path-header en haalt daarvan het SPF-record op. Als er een SPF-record bestaat en het IP-adres van de verzendende mailserver komt niet overeen met een van de IP-adressen in het SPF-record, dan kan het e-mailbericht geweigerd worden. Merk op dat het hier om de MAIL FROM- of Return-Path-header gaat en niet om de DISPLAY FROM- of From-header die gewoonlijk in een mailclient weergegeven wordt. SPF beschermt daarmee vooral de communicatie tussen mailservers en beschermt niet tegen het vervalsen van de voor de gebruiker zichtbare afzender in een e-mailbericht.[1] Hiervoor kan eventueel DKIM gebruikt worden.
In het verleden was er sprake van een specifiek SPF-record op DNS-servers. Deze is echter nooit ingevoerd hoewel de IANA er wel een code voor heeft toegewezen.
Hoewel SPF in theorie relatief goed werkt, zijn er een aantal mankementen aan het protocol, waardoor SPF op zichzelf niet voldoende is om e-mail spoofing en spam tegen te gaan: Veel grote organisaties en diensten gebruiken namelijk nog steeds niet de volledige bescherming van SPF. Dit laat onder andere toe dat klanten, werknemers en andere onschuldige ontvangers nog steeds phishing-mails krijgen namens deze bedrijven. Het ontbreken van een dergelijk SPF record heeft zelfs de Nederlandse overheid al eens in een negatief daglicht gezet,[2] maar nog steeds, anno 2020, is de (Nederlandse) consument en werknemer niet voldoende beschermd tegen spoofing en phishing.
Daarnaast moeten de records exact goed zijn om bescherming te bieden; bij foute of incomplete records zullen veel mailservers de e-mails automatisch weigeren. Bij een typfout, fout in de volgorde of het ontbreken van bijvoorbeeld include, mag de ontvangende mailserver het record volgens de RFC 7208 negeren. Aan de andere kant kan een record ook waardeloos zijn, doordat qualifiers niet voldoende zijn ingesteld. Wanneer het record bijvoorbeeld -all bevat, kan de ontvangende mailserver zijn ingesteld om geen andere e-mails door te laten. Wanneer het record echter ?all bevat, zal de mailserver óók alle andere e-mails doorlaten. Dat zorgt ervoor dat de ontvanger alsnog malafide e-mails kan blijven ontvangen, hoewel de mailserver deze mogelijk markeert als potentieel schadelijk.
Een andere beperking van SPF is dat het protocol enkel de zogeheten envelop beschermt en niet de inhoud van de e-mail. Hier komt bij kijken dat op de envelop een andere afzender vermeld kan worden dan bij de inhoud van de e-mail. Hiervoor is DKIM opgezet. Vervolgens is er het probleem dat niet elke ontvangende mailserver actief beleid voert op SPF en DKIM, waardoor ook e-mails zonder deze records worden doorgelaten. Om dat laatste gat te dichten, is in 2012 DMARC in het leven geroepen. Hiermee geeft de verzender aan wat er moet gebeuren met e-mails namens zijn domein, wanneer die niet voldoen aan de gestelde eisen.[3]