SPF, DKIM en DMARC zijn drie DNS-records die twee dingen bepalen: of de e-mail die je verstuurt in de inbox belandt, en of iemand anders e-mail kan versturen die van jou lijkt te komen. Gmail, Yahoo en Outlook.com eisen ze inmiddels alle drie van iedereen die in bulk verstuurt, en voor alle anderen geldt dat berichten zonder deze records eerder in de spam terechtkomen.
De records zijn kort, maar je maakt er makkelijk een subtiele fout in, en ze breken zonder waarschuwing zodra een nieuwe tool namens jou begint te mailen. Deze gids legt uit wat elk record doet, in welke volgorde je ze instelt en hoe je ze werkend houdt.
Hoe ze samenwerken
Elke e-mail heeft twee afzenderadressen: de envelope sender, die mailservers gebruiken om bounces terug te sturen, en het From-adres dat de ontvanger ziet. Fraude maakt gebruik van het verschil tussen die twee: iedereen kan elk willekeurig From-adres invullen. De drie records dichten dat gat.
SPF (Sender Policy Framework) somt de servers op die namens je domein mogen mailen.
DKIM (DomainKeys Identified Mail) voegt aan elk bericht een cryptografische handtekening toe, die ontvangers controleren met een publieke sleutel in je DNS.
DMARC (Domain-based Message Authentication, Reporting and Conformance) koppelt beide aan het zichtbare From-adres en vertelt ontvangers wat ze moeten doen met mail die niet slaagt.
SPF: wie mag er mailen
Een SPF-record is een TXT-record op je domein. Het somt de diensten en servers op die namens jou mailen en eindigt met wat er moet gebeuren met al het andere:
example.com. TXT “v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 ~all”
include: voegt het SPF-record van een ander domein toe, de gebruikelijke manier om een maildienst toe te staan.
ip4: en ip6: staan specifieke adressen toe, zoals die van je eigen mailserver.
~all (soft fail) of -all (fail) bepaalt wat er gebeurt met iedereen die niet in de lijst staat. Gebruik nooit +all, want dat staat het hele internet toe.
Op twee regels gaan de meeste domeinen onderuit:
Maar één record. Een domein moet precies één SPF-record hebben. Bij twee records geven ontvangers een permanente fout en faalt SPF voor elk bericht. Vraagt een nieuwe dienst je om “dit SPF-record toe te voegen”, zet de include dan in het record dat je al hebt.
Hooguit 10 DNS-lookups. Elke include, a, mx en redirect kost een lookup, en includes binnen includes tellen ook mee. Boven de 10 faalt SPF. Een record met Google Workspace, een nieuwsbrieftool, een CRM en een helpdesk kan de grens overschrijden zonder dat iemand het merkt.
SPF heeft een zwakke plek: het controleert de envelope sender, niet het From-adres dat de ontvanger ziet, en het breekt wanneer mail wordt doorgestuurd. Daarom is het op zichzelf niet genoeg.
DKIM: een handtekening op elk bericht
Met DKIM ondertekent je maildienst elk bericht met een privésleutel. De publieke sleutel staat in DNS, onder een naam die selector heet:
google._domainkey.example.com. TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…”
De ontvanger leest de selector uit de DKIM-Signature-header van het bericht, zoekt de sleutel op en controleert of het bericht onderweg niet is gewijzigd. Een DKIM-handtekening overleeft doorsturen, en dat maakt DKIM de betrouwbaarste van de twee.
Elke dienst die namens jou mailt, heeft een eigen DKIM-instelling nodig, meestal in de beheerinstellingen onder “authenticatie” of “geverifieerd domein”. Gebruik 2048-bit sleutels als de dienst die aanbiedt; 1024-bit sleutels werken nog, maar zijn het minimum, en kortere worden geweigerd. Wanneer een dienst zijn sleutels roteert, moet de nieuwe selector in je DNS staan voordat hij wordt gebruikt, anders falen de handtekeningen.
DMARC: koppel het aan het From-adres
DMARC is een TXT-record op _dmarc van je domein:
_dmarc.example.com. TXT “v=DMARC1; p=none; rua=mailto:dmarc@example.com”
Het doet twee dingen die SPF en DKIM alleen niet kunnen.
Ten eerste vereist het alignment. Een bericht slaagt alleen voor DMARC als SPF of DKIM slaagt voor hetzelfde domein als het zichtbare From-adres. Een nieuwsbrief die wordt verstuurd via een dienst die met zijn eigen domein ondertekent, slaagt voor DKIM, maar niet voor jouw domein, en faalt dus voor DMARC. Daarom moet elke dienst met jouw domein ondertekenen.
Ten tweede stelt het een policy in voor mail die faalt:
p=none: gewoon afleveren. Er verandert niets, maar ontvangers kunnen je rapporten sturen.
p=quarantine: in de spam plaatsen.
p=reject: weigeren.
Met de tag rua vraag je ontvangers om dagelijks geaggregeerde rapporten naar een adres naar keuze te sturen. Daarin staat welke servers mail als jouw domein hebben verstuurd en of die slaagde. Zo vind je afzenders die je was vergeten.
Stel ze in de juiste volgorde in
Direct overstappen op p=reject is de klassieke manier om je eigen facturen of wachtwoordresets niet meer te laten aankomen. Doe het in stappen:
Maak een lijst van alles wat als jouw domein mailt. Je mailboxprovider, nieuwsbrieftool, CRM, helpdesk, boekingssysteem, e-commerceplatform, het contactformulier van je website en elke server die notificaties verstuurt.
Stel voor elk daarvan DKIM in met je eigen domein, volgens de instructies van de dienst.
Bouw één SPF-record met de diensten die het nodig hebben, onder de 10 lookups, eindigend op ~all.
Publiceer DMARC met p=none en een rua-adres, en laat het twee tot vier weken staan.
Los elke legitieme afzender op die faalt, meestal een dienst die nog met zijn eigen domein ondertekent.
Stap over op p=quarantine, eventueel met pct=25 om te beginnen met een kwart van de falende mail, en daarna op p=reject zodra er geen legitieme mail meer faalt.
Ook domeinen die nooit e-mail versturen verdienen bescherming, want ze zijn makkelijk te spoofen. Geef ze een record dat dat aangeeft:
example.org. TXT “v=spf1 -all”
_dmarc.example.org. TXT “v=DMARC1; p=reject”
Fouten die e-mail ongemerkt breken
Een tweede SPF-record voor een nieuwe dienst, in plaats van een include in het eerste.
Een SPF-record dat boven de 10 lookups uitkwam toen er nog één tool bij kwam.
Een nieuwsbrieftool of CRM die met een eigen DKIM-domein verstuurt, zodat DMARC faalt ondanks een geldige handtekening.
Een DKIM-sleutel die bij de provider is geroteerd, maar nooit in DNS is gepubliceerd.
Een DMARC-record met een typfout, zoals p=rejected, dat ontvangers negeren.
Overstappen op p=reject voordat je hebt gecontroleerd dat elke afzender slaagt.
Een gewijzigd MX-record of een mailserver die op een blocklist belandt, wat de bezorging schaadt, hoe goed de records ook zijn.
Geen van deze fouten geeft een foutmelding die je ziet. Mail gaat gewoon naar de spam, en je hoort het weken later, wanneer een klant zegt dat de factuur nooit is aangekomen.
Controleer je records
Je kunt je domein nu meteen controleren met onze gratis SPF-, DKIM- en DMARC-checker. Die leest de records uit DNS, telt de lookups van SPF, zoekt DKIM-sleutels op gangbare selectors en legt uit wat je moet oplossen, met het record om te plakken.
Records die vandaag kloppen, breken wanneer iemand volgende maand een dienst toevoegt. De monitoring van e-mailauthenticatie van Uptimecheck controleert SPF, DKIM en DMARC op je domeinmonitors twee keer per dag, legt elk probleem in gewone taal uit, geeft je het DNS-record dat het oplost en waarschuwt je alleen wanneer er een nieuw probleem opduikt. Ook zoekt het de mailservers die je zelf beheert op in blocklists, zodat een vermelding niet onopgemerkt blijft. Voeg het toe aan de domeinmonitoring die je al waarschuwt voordat het domein zelf verloopt.
Checklist
Maak een lijst van elke dienst die e-mail als jouw domein verstuurt.
Stel in elk daarvan DKIM in met je eigen domein, waar mogelijk 2048-bit.
Houd één SPF-record aan, onder de 10 lookups, eindigend op ~all of -all.
Publiceer DMARC met p=none en een rapportadres.
Los elke legitieme afzender op die niet aan alignment voldoet.
Stap over op p=quarantine en daarna op p=reject.
Bescherm domeinen die niet mailen met v=spf1 -all en p=reject.
Controleer de records regelmatig, en telkens wanneer een nieuwe tool namens jou begint te mailen.