SPF, DKIM en DMARC: drie sloten op één deur

Waarom dit nodig is

E-mail is ontworpen in een tijd waarin de deelnemers elkaar kenden. Er zit daarom geen enkele controle in op wie een bericht verstuurt. De afzenderregel is gewoon een veld in het bericht, en dat veld mag je zelf invullen — net zoals je op een envelop kunt schrijven wat je wilt.

Wat daaruit volgt is de fraude die wij in de praktijk het vaakst zien, en het is niet de losse phishingmail met spelfouten. Het is de nette mail van een leverancier waarin staat dat het rekeningnummer is gewijzigd. Of de mail van de directeur aan de administratie, kort en met haast erin, over een betaling die vandaag nog moet.

Beide werken omdat de ontvanger geen reden heeft om te twijfelen: er staat een bekend adres boven. En beide zijn te voorkomen aan de kant van de ontvangende server, mits jij hebt vastgelegd wie er namens jouw domein mag verzenden.

Er is nog een reden om dit te doen die niets met veiligheid te maken heeft: aankomen. De grote mailaanbieders zijn deze records sinds 2024 gaan eisen van partijen die veel mail versturen. Een domein zonder DMARC belandt vaker in de ongewenste map, en dat merk je aan je facturen en je nieuwsbrief voordat je het aan een incident merkt.

SPF: wie mag er namens jou verzenden

SPF is een lijst. In je DNS zet je één regel waarin staat welke servers post mogen versturen met jouw domein als afzender. De ontvangende server kijkt van wie het bericht kwam, leest jouw lijst, en constateert of dat klopt.

Het klinkt eenvoudiger dan het is, want die lijst is bijna nooit alleen je eigen mailserver. Er zit een boekhoudpakket in dat facturen verstuurt, een nieuwsbriefdienst, een sollicitatiesysteem, een ticketsysteem dat bevestigingen stuurt en soms nog een oude server die niemand kent. Elke partij die namens jou mailt, moet erin.

Twee dingen gaan hier standaard mis:

• De limiet van tien opzoekingen. Een SPF-regel mag maximaal tien DNS-opzoekingen kosten. Elke dienst die je toevoegt telt mee, en bij een organisatie met een handvol leveranciers ben je er zo overheen. Zit je erboven, dan is het antwoord niet "ongeldig" maar "mislukt" — en dat kan je eigen mail treffen.
• De staart van de regel. Eindigt hij op ~all, dan zegt je domein "de rest is verdacht, maar lever maar af". Eindigt hij op -all, dan zegt hij "de rest is niet van ons". Dat laatste is de bedoeling, en het is ook wat het risico geeft als je lijst niet compleet is.

Waar SPF sowieso op stukloopt is doorsturen. Zet iemand jouw mail door naar een ander adres, dan verstuurt zijn server hem, en die staat niet in jouw lijst. Dat is geen fout die je kunt oplossen; het is de reden dat SPF alleen niet genoeg is.

DKIM: een handtekening die het doorsturen overleeft

DKIM lost precies dat op. In plaats van te kijken waar een bericht vandaan komt, zet je er een handtekening onder. Je mailserver ondertekent uitgaande berichten met een geheime sleutel; de bijbehorende publieke sleutel staat in je DNS. De ontvanger haalt die op en controleert of de handtekening bij de inhoud past.

Het voordeel is dat die handtekening aan het bericht vastzit en niet aan de server. Wordt de mail doorgestuurd, dan reist de handtekening mee en klopt hij nog steeds. Wordt de inhoud onderweg aangepast, dan klopt hij niet meer — en dat is ook precies wat je wilt weten.

Wat je hier in de gaten houdt:

• Elke verzendende partij ondertekent apart. Je nieuwsbriefdienst heeft zijn eigen sleutel onder zijn eigen selector. Eén DKIM-record voor alles bestaat niet.
• Sleutellengte. Sommige oudere opstellingen staan nog op 1024 bits. Nieuwe sleutels zet je op 2048.
• Vervangen hoort erbij. Een sleutel die er tien jaar in staat is een sleutel die niemand meer beheert. Dat is dezelfde redenering als bij sleutelbeheer.

SPF en DKIM samen dekken bijna alle gevallen. Wat ze allebei niet doen, is zeggen wat er moet gebeuren als het misgaat. Ze geven een oordeel en laten de ontvanger raden.

DMARC: het record waar iets van gebeurt

DMARC is de bovenlaag, en het is het enige van de drie waar een ontvangende server een instructie uit haalt. Het zegt twee dingen: wat je wilt dat er gebeurt met post die niet door SPF of DKIM komt, en waar de rapportage naartoe moet.

Er zijn drie standen, en ze horen in deze volgorde doorlopen te worden:

• Meekijken. Doe niets, maar stuur me elke dag een overzicht van wie er namens mijn domein heeft verzonden. Dit is waar je begint en het kan geen kwaad doen.
• Apart zetten. Wat niet klopt gaat naar de ongewenste map. De post komt nog aan, maar niet meer in de inbox.
• Afwijzen. Wat niet klopt wordt geweigerd en komt nergens aan. Dit is het doel, en dit is ook de stand waarin een vergeten leverancier zichtbaar wordt doordat zijn post verdwijnt.

Er zit één subtiliteit in die vaak wordt gemist. DMARC kijkt niet alleen of SPF of DKIM slaagt, maar ook of het domein dat slaagt hetzelfde is als het domein dat de lezer ziet staan. Een nieuwsbriefdienst die met zijn eigen domein verzendt en ondertekent, komt door SPF en DKIM heen en zakt alsnog voor DMARC. Daarom moet je zulke diensten expliciet op jouw domein laten verzenden — vrijwel elke leverancier heeft daar een instelling voor.

De dagelijkse rapporten die je terugkrijgt zijn XML en niet met de hand te lezen. Er zijn diensten die er een leesbaar overzicht van maken, en dat is de investering waard: zonder die rapporten zet je de laatste stap blind.

De volgorde waarin je het aanzet

De meeste verhalen hierover gaan over de records. Het echte werk zit in de weken ertussen, en dat is ook waar het misgaat als iemand het in één middag wil afronden.

Zo doen wij het:

• Week één: inventariseren en meekijken. SPF en DKIM neerzetten voor de partijen die je kent, DMARC op meekijken. Er verandert nog niets aan de aflevering.
• Week twee tot vier: rapporten lezen. Hier komt de lijst boven van wat er nog meer namens jou verstuurt. Dat is altijd meer dan iemand dacht: een oude webshop, het urenregistratiepakket, een marketingdienst uit een campagne van twee jaar geleden.
• Week vier: opruimen en aansluiten. Wat je wilt houden sluit je netjes aan op jouw domein. Wat niemand meer kent, zet je uit — dat is meestal de helft.
• Week vijf: apart zetten. Naar de tussenstand, en de rapporten blijven lezen. Wat je gemist hebt, meldt zich nu met een collega die zegt dat zijn bevestigingsmails in de spam staan.
• Daarna pas: afwijzen. Als er twee weken lang niets nieuws in de rapporten staat, is dit een niet-gebeurtenis. Doe je het eerder, dan is het dat niet.

Reken op zes tot acht weken van begin tot eind, waarvan het meeste wachten en lezen is. Dat is niet traag; dat is wat het verschil maakt tussen een domein dat dicht staat en een domein waar de facturen niet meer aankomen.

En zet daarna een herinnering. Elke nieuwe dienst die namens jou gaat mailen — een nieuw personeelssysteem, een andere nieuwsbriefpartij — moet erbij, en de dag dat iemand dat vergeet komt zijn post niet aan.