SPF, DKIM en DMARC uitgelegd voor ondernemers

SPF, DKIM en DMARC zijn 3 DNS-records die de rest van het internet vertellen welke servers e-mail mogen versturen voor uw domein en wat er moet gebeuren met mail die niet door die controles komt. SPF somt de toegestane afzenders op, DKIM voegt aan elk bericht een cryptografische handtekening toe, en DMARC koppelt beide aan het adres dat mensen werkelijk in het From-veld zien en legt een beleid vast voor mislukte controles.

Zonder deze records kan iedereen een bericht sturen met From: billing@yourcompany.com, en veel mailboxproviders hebben weinig reden om daaraan te twijfelen. Zijn ze correct ingesteld, dan faalt een vervalst bericht op de authenticatie en kan het worden geweigerd of naar spam gaan voordat uw klant het leest.

Het goede nieuws: alle 3 staan als gewone records in de DNS, dus u kunt de uwe in enkele minuten controleren met de opdrachten hieronder.

SPF: wie mag mailen namens uw domein

SPF (Sender Policy Framework, RFC 7208) is een TXT-record op uw domein met de servers en diensten die er mail voor mogen versturen. Een typisch record ziet er zo uit:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Het einde is het belangrijkst:

• -all (fail): alles wat niet in de lijst staat, is niet geautoriseerd.
• ~all (softfail): alles wat niet in de lijst staat, is verdacht.
• ?all (neutral): het record spreekt zich niet uit, waardoor ontvangers vrijwel niets hebben om mee te werken.
• +all: elke server op het internet mag namens u versturen. Dit is nooit juist.

SPF kent ook een harde grens: een ontvanger die uw record evalueert, mag maximaal 10 DNS-opvragingen doen voor mechanismen zoals include, a, mx en redirect (RFC 7208, sectie 4.6.4). Elke nieuwe marketingtool voegt een include toe, en zodra de teller boven 10 komt, geeft SPF een fout terug in plaats van een pass.

DKIM: een handtekening op elk bericht

Bij DKIM (DomainKeys Identified Mail, RFC 6376) ondertekent de verzendende server elk bericht met een privésleutel. De bijbehorende publieke sleutel staat in de DNS onder een selectornaam, zodat ontvangers kunnen bevestigen dat het bericht niet is gewijzigd en is ondertekend door iemand die uw sleutel bezit.

Elke dienst die namens u verstuurt (uw mailboxprovider, uw CRM, uw facturatietool) hoort te ondertekenen met een eigen selector. Het DNS-record ziet er zo uit:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DKIM faalt geruisloos. De mail gaat gewoon onondertekend de deur uit, en niemand merkt het tot berichten in spam belanden of een provider zijn regels aanscherpt.

DMARC: het beleid dat alles verbindt

DMARC is nu vastgelegd in RFC 9989, gepubliceerd in mei 2026, die de oudere RFC 7489 vervangt. DMARC controleert of SPF of DKIM is geslaagd voor een domein dat overeenkomt (aligned is) met het zichtbare From-adres, en vertelt ontvangers wat ze moeten doen als geen van beide slaagt:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

• p=none: alleen monitoren. Mail die faalt, wordt gewoon afgeleverd; u ontvangt alleen rapporten.
• p=quarantine: mail die faalt, moet als verdacht worden behandeld, meestal naar spam.
• p=reject: mail die faalt, moet worden geweigerd.

Het rua-adres ontvangt geaggregeerde rapporten van grote mailboxproviders (zo leest u een DMARC-aggregaatrapport). Die rapporten tonen elke bron die mail onder uw naam verstuurt, ook bronnen die u vergeten was en bronnen die niet van u zijn.

Zo controleert u uw eigen domein

Voer deze opdrachten uit in een willekeurige terminal (vervang example.com door uw domein):

dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

Voor DKIM hebt u de selectornaam nodig. Open een willekeurige e-mail die uw bedrijf heeft verstuurd, bekijk de originele broncode van het bericht en zoek naar DKIM-Signature: en de waarde s=. Dezelfde headers tonen ook Authentication-Results: met spf=pass, dkim=pass en dmarc=pass, of de fouten.

Waar u op let:

1. Precies 1 SPF-record (2 v=spf1-records maken SPF volledig ongeldig).
2. Een SPF-einde ~all of -all, niet ?all of +all.
3. Een DKIM-handtekening op mail van elke dienst die namens u verstuurt.
4. Een DMARC-record dat bestaat en een rua-adres heeft dat iemand echt leest.
5. Een plan om van p=none naar p=quarantine of p=reject te gaan.

Veelgemaakte fouten en hoe u ze oplost

2 SPF-records. Vaak achtergebleven na een overstap naar een andere provider. Voeg ze samen tot 1 record.

Te veel opvragingen. Verwijder diensten die u niet meer gebruikt en vervang includes door de specifieke adresbereiken waar uw provider dat toestaat.

Vergeten afzenders. Een nieuwsbrieftool of helpdesk die zonder DKIM verstuurt, faalt op DMARC zodra u het beleid afdwingt. Lees eerst een paar weken uw DMARC-rapporten en schakel daarna DKIM in voor elke legitieme bron.

Eeuwig op p=none blijven. Monitoren is de juiste eerste stap, maar p=none vraagt ontvangers om vervalste mail toch af te leveren. Zodra de rapporten tonen dat alle echte mail slaagt, gaat u naar p=quarantine en daarna naar p=reject.

Geparkeerde en ongebruikte domeinen. Een domein dat nooit mail verstuurt, kan toch worden vervalst. Publiceer er v=spf1 -all en een DMARC-record met p=reject op.

Deze records tellen ook mee voor de aflevering. Gmail, Yahoo en Outlook eisen ze inmiddels van afzenders met grote volumes, wat we behandelen in de afzendervereisten van Gmail en Yahoo. En ze vormen een van de verdedigingslagen tegen de fraude met valse facturen die we beschrijven in hoe business email compromise werkt.

Korte checklist

• 1 SPF-record, eindigend op ~all of -all, onder 10 opvragingen.
• DKIM-ondertekening ingeschakeld voor elke dienst die namens u verstuurt.
• DMARC gepubliceerd, met rapporten naar een mailbox die wordt opgevolgd.
• Beleid dat richting p=reject gaat zodra de rapporten schoon zijn.
• Geparkeerde domeinen afgesloten met -all en p=reject.

Hoe Datahorses helpt

E-mailauthenticatie is een van de gebieden die we dagelijks van buitenaf bewaken, samen met uw domeinen, certificaten en website. Wijzigt een SPF-record, verdwijnt een DKIM-selector of wordt DMARC afgezwakt, dan beoordeelt een specialist dat en krijgt u de precieze records om aan te passen. De volledige lijst ziet u bij wat wij bewaken, en waarom er geen toegang tot uw systemen nodig is. Voor het bredere beeld leest u wat monitoring van het externe aanvalsoppervlak is.