Wat SPF, DKIM en DMARC echt doen
Zie de drie als één ketting met drie schakels. SPF geeft de servers toestemming die namens je domein mogen versturen. DKIM voegt een cryptografische handtekening toe, zodat een ontvanger kan zien dat het bericht onderweg niet is gewijzigd. DMARC koppelt beide terug aan het domein dat een lezer echt ziet in de From-regel en publiceert een beleid voor wat er moet gebeuren als de controle faalt. Simpel gezegd: SPF controleert de envelop, DKIM controleert de inhoud en DMARC controleert of een van beide overeenkomt met de naam die je ontvanger leest.
SPF: welke servers namens je domein mogen versturen
Een SPF-record is één TXT-record in je DNS dat begint met v=spf1, de hosts en includes opsomt die namens het domein mogen versturen en eindigt met een all-mechanisme. Twee regels zetten mensen op het verkeerde been. Ten eerste mag een domein maar één v=spf1-record publiceren; met een tweede geeft de evaluatie permerror en faalt de authenticatie in de praktijk (RFC 7208, sectie 4.5). Ten tweede mag SPF tijdens de evaluatie hooguit tien mechanismen gebruiken die een DNS-lookup doen (include, a, mx, ptr, exists en de redirect-modifier); boven de tien is het resultaat opnieuw permerror (sectie 4.6.4). De laatste qualifier is het beleid: ~all is een softfail (accepteren maar markeren), -all is een hardfail (afzenders die niet op de lijst staan weigeren) en +all zou alles laten slagen, en daarom publiceer je dat nooit. Een structurele beperking die je moet kennen: SPF authenticeert het verborgen Return-Path-domein, niet het zichtbare From-adres, en het breekt bij doorsturen, omdat het IP-adres van de doorstuurserver niet in je record staat. Precies daarom leunt DMARC niet alleen op SPF.
DKIM: een handtekening die niemand ongemerkt kan wijzigen
DKIM ondertekent elk uitgaand bericht met een privésleutel die je verzendsysteem bewaart en publiceert de bijbehorende publieke sleutel in je DNS. De handtekening dekt gekozen headers en de body, dus als er onderweg iets wordt gewijzigd, valideert de handtekening niet meer. Ontvangers vinden de sleutel via een selector: een DKIM-Signature-header bevat s= (de selector) en d= (je domein), en de controlerende server vraagt selector._domainkey.jouwdomein op voor de publieke sleutel (RFC 6376, sectie 3.6.2.1). Met selectors kun je ook meerdere sleutels tegelijk gebruiken, en dat maakt rotatie overzichtelijk: publiceer een nieuwe selector, laat het ondertekenen daarnaar overgaan en trek dan de oude in (een lege sleutelwaarde markeert hem als ingetrokken). Over sleutellengte: RFC 6376 eist RSA-sleutels van minstens 1024 bits voor langdurig gebruik, en controlerende servers moeten sleutels tot 2048 bits aankunnen; 2048 bits is de verstandige moderne standaard, en door sleutels regelmatig te roteren beperk je de schade als er ooit een uitlekt.
DMARC: het beleid dat alles samenbrengt
DMARC is het record dat SPF en DKIM betekenis geeft voor het domein dat je ontvanger leest. Het kernidee is alignment. Een bericht slaagt alleen voor DMARC als SPF of DKIM een pass oplevert en die pass gebaseerd is op een identifier die overeenkomt met het zichtbare From-domein (RFC 7489, sectie 4.2). Daarom kan een bericht slagen voor de kale SPF-controle en toch falen voor DMARC: als je ESP verstuurt met een eigen Return-Path-domein, slaagt SPF voor de ESP, maar dat domein komt niet overeen met je From-adres, dus de SPF-kant van DMARC faalt. Alignment kent twee modi: relaxed, die een overeenkomend organisatiedomein accepteert (mail.jouwbedrijf.nl komt overeen met jouwbedrijf.nl), en strict, die een exacte match eist. Omdat één mechanisme met alignment genoeg is, loodst DKIM-alignment meestal de mail erdoor die SPF niet aankan, zoals doorgestuurde berichten. Het record zelf luidt v=DMARC1; p=none; rua=mailto:reports@jouwbedrijf.nl; de p-tag bepaalt het beleid (none, quarantine of reject), rua bepaalt waar geaggregeerde rapporten naartoe gaan en sp stelt een apart beleid in voor subdomeinen, dat je p-waarde overneemt als je het weglaat.
Waarom dit in 2024 verplicht werd
Authenticatie was vroeger optionele hygiëne. In februari 2024 werd het een harde eis. Gmail en Yahoo eisen nu van bulkverzenders (Google rekent daartoe iedereen die meer dan 5.000 berichten per dag naar Gmail stuurt) dat ze authenticeren met SPF en DKIM en een DMARC-record publiceren, dat mag beginnen met p=none. Marketingmail en mail waarop mensen zich hebben ingeschreven moeten ook afmelden met één klik ondersteunen: de List-Unsubscribe-header (RFC 2369) plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, het mechanisme voor afmelden met één klik uit RFC 8058, zodat de mailclient van een ontvanger kan afmelden met één HTTPS POST. Je leest de volledige regels van Gmail en Yahoo in het overzicht over deliverability. Twee dingen om op te letten: de handhaving is sinds 2024 strenger geworden, dus bouw volgens de regel, ook onder de 5.000 per dag, en spamklachten laag houden is, net als authenticatie, een eis en geen extraatje.
Veelgemaakte fouten die authenticatie ongemerkt breken
- +all publiceren in je SPF-record, waarmee je het hele internet toestemming geeft om als jou te versturen: precies het omgekeerde van de bedoeling.
- Meer dan één v=spf1-record op hetzelfde domein, wat permerror geeft en SPF ongeldig maakt.
- Over de grens van tien DNS-lookups gaan terwijl je includes van leveranciers toevoegt, wat ook permerror geeft.
- Een DKIM-sleutel die te kort is of nooit wordt geroteerd, zodat een uitgelekte of gekraakte sleutel eindeloos blijft ondertekenen.
- Meteen naar p=reject springen zonder ook maar één geaggregeerd rapport te lezen, waardoor je legitieme mail blokkeert waarvan je vergeten was dat je die verstuurt.
- sp= vergeten voor subdomeinen, zodat een laks subdomeinbeleid marketing.jouwbedrijf.nl openzet voor spoofing.
- Een externe afzender (een ESP, een facturatietool, een helpdesk) die je nooit in SPF- en DKIM-alignment hebt gebracht, zodat de mail ervan faalt voor DMARC.
Waar authenticatie past in je stack
Authenticatie is het fundament waar al het andere op rust. Als je zelf host, zijn de DNS en de ondertekeningssleutels volledig van jou: de sterkste vorm van controle over je eigen afzenderidentiteit. Een customer engagement platform hoort de status van authenticatie en alignment te tonen voor elk verzenddomein in plaats van die te verbergen, zodat je in één oogopslag ziet welke bronnen slagen. Stuur transactionele mail en marketingmail via aparte stromen en liefst via aparte subdomeinen, zodat een piek in spamklachten op marketingmail nooit de aflevering van wachtwoordresets bedreigt. En pak het werk in de goede volgorde aan: eerst authenticatie en alignment, en pas daarna het opwarmen van het domein. Een domein zonder authenticatie opwarmen leert providers alleen sneller om je te wantrouwen.