SPF, DKIM en DMARC: de drie pijlers van e-mailauthenticatie
Een diepgaande technische gids over hoe SPF, DKIM en DMARC samenwerken om je domeinen te beschermen tegen spoofing en phishing.
Waarom e-mailauthenticatie niet optioneel is
In 2024 hebben Google en Yahoo hun beleid aangescherpt: bulk-afzenders zonder correcte SPF, DKIM en DMARC-configuratie worden simpelweg geweigerd. Microsoft volgde in 2025. Dit is niet langer een "nice to have" — het is een harde vereiste.
Toch zien we dagelijks bedrijven die met meerdere domeinen werken en geen idee hebben hoe deze drie protocollen samenwerken. Het resultaat? Mails die in spam belanden, klanten die phishing-mails ontvangen "van" jouw domein, en een reputatie die langzaam afbrokkelt.
De huidige stand van zaken:
- 91% van alle cyberaanvallen begint met een phishing-e-mail
- Slechts 34% van alle domeinen heeft een geldig DMARC-beleid
- Bedrijven met correcte authenticatie zien 10-15% hogere inbox-plaatsing
SPF: wie mag namens jou versturen?
SPF (Sender Policy Framework) is de eerste verdedigingslinie. Het werkt via een DNS TXT-record dat specificeert welke IP-adressen en servers e-mail mogen verzenden namens jouw domein.
Hoe SPF technisch werkt
Wanneer een ontvangende mailserver een bericht krijgt, kijkt deze naar het Return-Path (envelope sender) domein en doet een DNS-lookup:
dnsvoorbeeld.nl. IN TXT "v=spf1 include:_spf.google.com include:mailbelly.com ip4:203.0.113.0/24 -all"
Laten we dit ontleden:
| Onderdeel | Betekenis |
|---|---|
| `v=spf1` | SPF versie 1 (verplicht) |
| `include:_spf.google.com` | Google Workspace mag versturen |
| `include:mailbelly.com` | MailBelly mag versturen |
| `ip4:203.0.113.0/24` | Dit IP-bereik mag versturen |
| `-all` | Alles anders: **afwijzen** |
De valkuilen van SPF
1. De 10-lookup limiet
SPF staat maximaal 10 DNS-lookups toe. Elke include: telt als een lookup, en geneste includes tellen ook mee. Met meerdere SaaS-tools (Google Workspace, een CRM, een marketingtool, MailBelly) zit je hier snel aan.
Lookup 1: include:_spf.google.com
Lookup 2: include:_netblocks.google.com
Lookup 3: include:_netblocks2.google.com
Lookup 4: include:_netblocks3.google.com
Lookup 5: include:mailbelly.com
Lookup 6: include:spf.protection.outlook.com
Lookup 7: include:sendgrid.net
Lookup 8: ...Oplossing: Gebruik SPF-flattening of consolideer je verzendinfrastructuur. MailBelly optimaliseert dit automatisch voor multi-domain setups.
2. Het `~all` vs `-all` debat
-all(hard fail): Wijs alles af wat niet in de lijst staat~all(soft fail): Markeer als verdacht, maar wijs niet af
Ons advies: begin met ~all tijdens de configuratiefase, schakel over naar -all zodra je zeker weet dat alle legitieme bronnen zijn opgenomen.
DKIM: digitale handtekening voor elke mail
DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan elk uitgaand bericht. De ontvangende server kan deze verifiëren via een publieke sleutel in je DNS.
De technische werking
Bij het versturen van een e-mail:
- De verzendende server selecteert specifieke headers en de body
- Berekent een hash met SHA-256
- Ondertekent de hash met een privésleutel
- Voegt de handtekening toe als
DKIM-Signatureheader
DKIM-Signature: v=1; a=rsa-sha256; d=voorbeeld.nl;
s=mailbelly2026; c=relaxed/relaxed;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...Het bijbehorende DNS-record:
dnsmailbelly2026._domainkey.voorbeeld.nl. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
DKIM-sleutelrotatie
Een veelgemaakte fout: DKIM-sleutels nooit roteren. Best practice is om elke 6-12 maanden je sleutels te vernieuwen. Met meerdere domeinen wordt dit snel een administratieve nachtmerrie — tenzij je het automatiseert.
MailBelly beheert DKIM-sleutels automatisch per domein en roteert ze op schema, zonder dat je er naar hoeft om te kijken.
DKIM alignment
Een subtiel maar cruciaal punt: het d= domein in de DKIM-handtekening moet overeenkomen met (of een subdomein zijn van) het From: domein. Dit heet alignment en is essentieel voor DMARC.
DMARC: de dirigent van het orkest
DMARC (Domain-based Message Authentication, Reporting & Conformance) brengt SPF en DKIM samen. Het vertelt ontvangende servers wat ze moeten doen als authenticatie faalt, en geeft je rapportages over wie namens jouw domein verstuurt.
Het DMARC-record
dns_dmarc.voorbeeld.nl. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@voorbeeld.nl; ruf=mailto:forensics@voorbeeld.nl; adkim=s; aspf=s; pct=100"
| Parameter | Waarde | Betekenis |
|---|---|---|
| `p` | none/quarantine/reject | Beleid bij falen |
| `rua` | mailto:... | Aggregate reports ontvangen |
| `ruf` | mailto:... | Forensische reports ontvangen |
| `adkim` | r(elaxed)/s(trict) | DKIM alignment mode |
| `aspf` | r(elaxed)/s(trict) | SPF alignment mode |
| `pct` | 0-100 | Percentage berichten waarop beleid van toepassing is |
Het DMARC-stappenplan
Ga nooit direct naar p=reject. Volg dit pad:
DMARC-rapportages lezen
De aggregate reports (RUA) zijn XML-bestanden die dagelijks binnenkomen van ontvangende servers. Ze bevatten:
- Welke IP-adressen namens jouw domein versturen
- Of SPF en DKIM slaagden of faalden
- Welk DMARC-beleid werd toegepast
Een voorbeeld uit een rapport:
xml<record> <row> <source_ip>203.0.113.42</source_ip> <count>1547</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> </record>
Dit vertelt je: IP 203.0.113.42 verstuurde 1.547 berichten, en zowel DKIM als SPF slaagden. Als je dit IP niet herkent, heb je een probleem.
Multi-domain authenticatie: de echte uitdaging
Voor bedrijven met één domein is authenticatie relatief eenvoudig. Maar zodra je 5, 10 of 50 domeinen beheert, wordt het exponentieel complexer:
- Elk domein heeft zijn eigen SPF-record nodig
- Elk domein heeft DKIM-sleutels nodig (mogelijk meerdere per verzendservice)
- Elk domein heeft een DMARC-record nodig
- Elk record moet consistent en up-to-date blijven
Veelvoorkomende fouten bij multi-domain setups
- Copy-paste SPF-records — Elk domein heeft mogelijk andere verzendservices
- Vergeten DKIM-keys te deployen na het toevoegen van een nieuw domein
- DMARC op `p=none` laten staan "omdat het toch werkt"
- Subdomeinen vergeten —
support.voorbeeld.nlerft niet automatisch SPF vanvoorbeeld.nl - Geen monitoring — Zonder DMARC-rapportages vlieg je blind
Praktische checklist
Gebruik deze checklist voor elk domein:
Hoe MailBelly dit vereenvoudigt
MailBelly is gebouwd voor multi-domain authenticatie:
- Automatische SPF-optimalisatie — We houden je onder de 10-lookup limiet
- Beheerde DKIM-sleutels — Automatische rotatie per domein
- DMARC-monitoring dashboard — Begrijpelijke visualisaties in plaats van ruwe XML
- Proactieve waarschuwingen — We laten je weten als er iets misgaat vóórdat het een probleem wordt
- Eén klik configuratie — DNS-records worden automatisch gegenereerd per domein
Conclusie
SPF, DKIM en DMARC zijn niet drie losse technologieën — ze vormen een samenhangend systeem. SPF bepaalt wie mag versturen, DKIM bewijst dat het bericht niet is gewijzigd, en DMARC definieert het beleid en levert rapportages.
Voor bedrijven met meerdere domeinen is handmatig beheer van deze records niet houdbaar. Automatisering is geen luxe, het is een noodzaak. En dat is precies wat MailBelly biedt.
Begin vandaag: controleer je huidige authenticatie-status op [MXToolbox](https://mxtoolbox.com) of [dmarcian](https://dmarcian.com), en zet een plan op om naar p=reject te migreren.