SPF-richtlijnen

SPF (Sender Policy Framework) is een gratis, open DNS-standaard waarmee een domeineigenaar expliciet vastlegt welke servers namens dat domein e-mail mogen versturen. Het is een van de twee bouwstenen waar DMARC op steunt, naast DKIM.

Zie het als een gastenlijst bij de deur

SPF is als een gastenlijst bij de ingang van een evenement: het geeft aan welke adressen (IP-adressen) mogen zeggen dat ze namens een bepaald domein versturen. Staat het adres van de afzender niet op de lijst, dan weet de “deur” — de ontvangende mailserver — dat er iets niet klopt.

Waarom dit belangrijk is

Zonder SPF-record kan iedereen jouw domein in het afzenderadres van een e-mail zetten, zonder dat er in DNS iets vastligt om te controleren of dat klopt. SPF dicht dat gat door ontvangende mailservers het IP-adres van de verzendende server te laten vergelijken met een lijst die je zelf publiceert. Dit heeft directe invloed op afleverbaarheid: mailboxproviders gebruiken SPF, samen met DKIM en DMARC, om te bepalen of een bericht er echt uitziet.

Hoe het werkt

SPF wordt gecontroleerd tegen de envelope-afzender — het technische “return path”-adres dat tijdens het SMTP-verkeer tussen mailservers wordt gebruikt (RFC 5321.MailFrom). Dit is niet altijd hetzelfde adres als het “Van”-adres dat een lezer in zijn inbox ziet. De ontvangende server zoekt het SPF TXT-record van dat domein op, vergelijkt dit met het IP-adres waar het bericht daadwerkelijk vandaan kwam, en dat levert een pass of fail op.

Elk domein zou een SPF-record moeten hebben — ook domeinen die nooit e-mail versturen; die moeten dat expliciet aangeven (zie Beveiliging, hieronder). SPF wordt niet overgeërfd door subdomeinen: elk (sub)domein dat mail verstuurt heeft zijn eigen expliciete record nodig.

Ik wil meer weten

De uitleg hierboven dekt wat de meeste mensen nodig hebben. De rest van dit artikel is de gedetailleerde naslag: de exacte syntaxisregels, beveiligingsaanbevelingen en de standaarden waar dit allemaal op gebaseerd is.

Algemeen

Elk domein (verzendend en niet-verzendend) zou een SPF TXT-record moeten hebben.
Een domein mag maar één SPF TXT-record hebben.
SPF-records worden gepubliceerd als DNS TXT resource records. Gebruik niet het aparte SPF-recordtype (RR-type 99) — dat is verouderd.
TXT-records zijn beperkt tot 255 tekens per string, maar kunnen uit meerdere achter elkaar geplaatste strings bestaan — dit heet een multi-string TXT-record.
Controleer de syntaxis van het SPF-record vóór publicatie in DNS; dit kan met een SPF-checker.
Vermijd dubbele vermeldingen of netblocks binnen één SPF-record.
SPF wordt niet overgeërfd: publiceer SPF-records expliciet op elk (sub)domein dat mail verstuurt.
Zet de mechanismen in een SPF-record van belangrijkst/hoogste mailvolume (links) naar minst belangrijk (rechts), zodat het record snel te evalueren is.
Elke mailserver-hostname die in HELO/EHLO wordt gebruikt, zou een eigen SPF-record moeten hebben dat die hostname autoriseert (meestal v=spf1 a -all), wat een geldig “A”-record voor die hostname vereist.

Goed om te weten

SPF wordt in moderne e-mailfiltering niet langer op zichzelf gebruikt als beslissend mechanisme — in de praktijk blokkeren ontvangers een bericht niet alleen op basis van een SPF-resultaat. Het blijft belangrijk omdat DMARC het gebruikt als één van zijn twee authenticatiesignalen.

Configuratie

SPF-records beginnen altijd met v=spf1 en eindigen met ~all (soft fail) of -all (hard fail).
SPF-records zijn beperkt tot 10 DNS-lookups. De mechanismen die hierin meetellen zijn: a, mx, include, ptr (verouderd), redirect en exists.
SPF wordt gecontroleerd tegen het domein dat gebruikt wordt in de envelope-from/MailFrom/return-path tijdens de SMTP-transactie. Gebruikt een afzender daar een ander domein, dan hoeft die niet aan het SPF-record van je organisatiedomein te worden toegevoegd.
Het include-mechanisme delegeert een deel van het record aan een derde partij. Een derde partij kan syntaxisfouten introduceren, of je over de limiet van 10 lookups heen duwen als er later mechanismen worden toegevoegd — let hierop als je al dicht bij de limiet zit.
include kan per ongeluk lookup-lussen tussen records creëren; vermijd dit.
Het exists-mechanisme zou alleen in specifieke, bewuste gevallen gebruikt moeten worden, omdat het de verantwoordelijkheid voor het hele resultaat bij een andere lookup neerlegt.
Gebruik het ptr-mechanisme niet — dit is afgeschreven (RFC 7208, Sectie 5.5).

Beveiliging

Houd SPF-records gericht, kort en to the point. Autoriseer niet te ruim: publiceer bijvoorbeeld geen /24-netblock als daarin maar 2–3 adressen daadwerkelijk mail versturen.
Domeinen die nooit e-mail zouden mogen versturen, moeten alsnog een SPF-record hebben dat expliciet faalt: v=spf1 -all, bij voorkeur ook gepubliceerd als wildcard-record waar technisch mogelijk: Hostname: *.example.com. | Type: TXT | Waarde: "v=spf1 -all".
Vermijd ?all (neutraal resultaat) en gebruik nooit +all (hiermee mag letterlijk iedereen als jou versturen).
Controleer je SPF-record periodiek — maandelijks, of op zijn minst jaarlijks — om te checken of deze nog overeenkomt met je daadwerkelijke verzendinfrastructuur.

Bronnen & verder lezen

RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email: rfc-editor.org/rfc/rfc7208
M3AAWG Best Practices for Managing SPF Records – het document met best practices van de Messaging, Malware and Mobile Anti-Abuse Working Group, een goede aanvulling op de RFC zelf.