E-mail die niet aankomt, ineens in spam belandt of wordt geweigerd door Microsoft 365 of Google Workspace is vaak terug te herleiden naar één ding: ontbrekende of onjuiste e-mailauthenticatie in DNS. Hoe stel je SPF, DKIM en DMARC goed in voor je domein? In dit artikel leggen we dat helder uit, met de juiste nuance voor zakelijke omgevingen en technische teams. Je krijgt grip op wat SPF, DKIM en DMARC precies doen, hoe ze samenwerken, welke valkuilen we in de praktijk het meest zien en hoe je dit netjes beheert zonder je “gewone” e-mailverkeer te verstoren.
Oxilion is sinds 2000 actief als Nederlandse hostingprovider voor domeinnamen, websites, e-mail, webhosting, managed hosting en cloudoplossingen. We houden van duidelijke techniek: liever één correct DNS-record dan tien halve maatregelen. En liever uitleg waarmee je zelf begrijpt wat er gebeurt, dan vage marketingtaal.
Waarom e-mailauthenticatie in DNS onmisbaar is
Het internet vertrouwt e-mail al lang niet meer “op goed geluk”. Ontvangende mailservers beoordelen steeds strenger of een bericht echt namens jouw domein verzonden mag worden. SPF, DKIM en DMARC zijn daarbij de belangrijkste standaarden. Samen vormen ze een controlelaag die helpt tegen spoofing (misbruik van jouw domeinnaam), phishing en onbedoelde spamclassificatie.
Als je SPF, DKIM en DMARC goed instelt voor je domein, bereik je doorgaans drie doelen:
- Je verlaagt de kans dat jouw mail in de spamfolder belandt.
- Je verkleint de kans dat anderen jouw domein misbruiken voor nep-mail.
- Je krijgt beter inzicht in misbruik en fouten via DMARC-rapportages.
Belangrijk om te beseffen: e-maildeliverability is nooit alleen “een recordje zetten”. Het is een combinatie van reputatie, inhoud, verzendgedrag én technische authenticatie. Maar zonder SPF, DKIM en DMARC sta je vrijwel altijd met 1-0 achter.
Hoe stel je SPF, DKIM en DMARC goed in voor je domein? Het overzicht
Voordat we de diepte in gaan, eerst het overzicht. SPF, DKIM en DMARC staan alle drie in je DNS, maar ze doen verschillende dingen:
- SPF vertelt welke mailservers namens jouw domein mogen verzenden.
- DKIM voegt een digitale handtekening toe aan uitgaande e-mail, die de ontvanger kan verifiëren met een sleutel in DNS.
- DMARC koppelt SPF en DKIM aan een beleid: wat moet de ontvanger doen als authenticatie faalt, en waar mogen rapportages naartoe?
In de praktijk draait “Hoe stel je SPF, DKIM en DMARC goed in voor je domein?” vooral om samenhang: SPF en DKIM goed laten slagen, en DMARC zo instellen dat het past bij jouw risicoprofiel en verzendlandschap.
SPF uitgelegd: verzendende servers autoriseren
SPF staat voor Sender Policy Framework. Het is een DNS-record (meestal een TXT-record) waarin je opsomt welke systemen e-mail mogen versturen voor jouw domein. Ontvangende servers vergelijken het IP-adres van de verzendende server met jouw SPF-beleid.
Hoe SPF werkt in gewone taal
Zie SPF als een gastenlijst bij de deur. Staat de verzendserver op de lijst, dan is het “waarschijnlijk oké”. Staat hij er niet op, dan is het verdacht. SPF zegt echter niets over de inhoud van het bericht, en ook niets over of het bericht onderweg gewijzigd is. Daar is DKIM voor.
Veelvoorkomende SPF-valkuilen
- Meerdere SPF-records op hetzelfde domein: dat gaat vaak mis. In de regel hoort er één SPF-beleid te zijn dat alles afdekt.
- Vergeten derde partijen: nieuwsbrieftools, supportdesksoftware of webapplicaties versturen soms ook mail namens jouw domein.
- Te streng beleid zonder overzicht: je zet “hard fail” terwijl niet alle verzenders in kaart zijn gebracht.
- DNS-lookup limieten: SPF heeft een limiet op het aantal DNS-queries tijdens evaluatie. Bij veel “include”-constructies kun je daar tegenaan lopen.
Een typische praktijkcase is een nieuwsbriefplatform. In veel situaties hoef je je “normale” e-mail niet te wijzigen, maar soms vraagt de tool wel dat je jouw bestaande SPF uitbreidt met een include. Bij Mailchimp is dat bijvoorbeeld vaak het toevoegen van include:servers.mcsv.net aan je bestaande SPF-beleid, zodat Mailchimp geautoriseerd is om namens jouw domein te verzenden.
DKIM uitgelegd: aantonen dat je bericht echt is
DKIM staat voor DomainKeys Identified Mail. DKIM werkt met asymmetrische cryptografie: de verzendende mailserver ondertekent elk bericht met een private key, en de ontvangende server controleert die handtekening met de public key die jij in DNS publiceert.
Wat DKIM oplost (en wat niet)
DKIM helpt de ontvanger vaststellen of het bericht onderweg is aangepast en of het ondertekend is door een partij die bij jouw domein hoort. Dat maakt DKIM waardevol voor betrouwbaarheid en reputatie. DKIM garandeert niet dat de afzender “goede bedoelingen” heeft, maar wel dat het bericht niet ongemerkt gemanipuleerd is en dat de ondertekening klopt.
DKIM in DNS: selectors en records
DKIM gebruikt selectors: dat zijn labels waarmee je meerdere sleutels kunt beheren of roteren. Veel e-mailplatformen geven je één of meerdere DKIM-records die je als CNAME of TXT toevoegt. Bij Mailchimp zie je vaak twee DKIM-records die als CNAME worden ingesteld, bijvoorbeeld in de vorm van k2._domainkey en k3._domainkey die verwijzen naar Mailchimp-doelen (zoals dkim2.mcsv.net. en dkim3.mcsv.net.).
Een detail dat in de praktijk vaak fout gaat: bij het invullen van CNAME-records vul je bij “naam” doorgaans alleen het label in (zoals k2._domainkey) en niet je volledige domeinnaam erachter. En het doel van een CNAME wordt regelmatig afgesloten met een punt, afhankelijk van hoe DNS-invoer in het beheerpaneel geïnterpreteerd wordt. Volg hierbij altijd de instructies van je e-mailplatform, omdat de exacte waarden gepersonaliseerd kunnen zijn.
DMARC uitgelegd: beleid en rapportage op domeinniveau
DMARC staat voor Domain-based Message Authentication, Reporting and Conformance. DMARC is het mechanisme dat SPF en DKIM “afmaakt”: je publiceert een beleidsregel in DNS die zegt wat ontvangers moeten doen als een bericht niet door de authenticatie komt, én waar rapportages naartoe gestuurd mogen worden.
Waarom DMARC zoveel verschil maakt
Zonder DMARC kan een ontvanger SPF of DKIM wel controleren, maar ontbreekt een eenduidig beleid. Met DMARC kun je afdwingen dat mislukte authenticatie leidt tot monitoren, quarantainen (bijvoorbeeld spamfolder) of weigeren. Tegelijkertijd kun je via rapportages inzicht krijgen in wie er namens jouw domein probeert te mailen.
Wil je de standaard zelf nalezen: de kern van DMARC is vastgelegd in een IETF RFC, onder andere RFC 7489.
DMARC-record: klein record, grote impact
DMARC staat in DNS meestal als TXT-record op _dmarc.jouwdomein.nl. Ook hier zien we in de praktijk dezelfde fout als bij DKIM: men vult bij “naam” per ongeluk het volledige domein in, terwijl alleen _dmarc bedoeld is (afhankelijk van het DNS-beheersysteem). Daarnaast vragen sommige platforms dat de DMARC-waarde tussen aanhalingstekens staat. Het hangt af van het paneel en de validatie of dat nodig is, maar als jouw platform dit expliciet noemt, houd je daaraan.
DMARC heeft ook “alignment”: dat betekent dat het domein in de zichtbare From-header moet passen bij het domein dat door SPF en of DKIM geauthenticeerd wordt. Dat is precies waarom DMARC zo effectief is tegen spoofing met jouw domeinnaam.
Hoe stel je SPF, DKIM en DMARC goed in voor je domein bij gebruik van externe verzendplatformen
Veel organisaties versturen niet alleen mail vanuit één mailboxomgeving, maar ook via externe systemen. Denk aan nieuwsbrieven, facturatie, applicatiemeldingen, formulieren en marketing automation. Juist dan is het belangrijk om SPF, DKIM en DMARC goed in te richten, omdat je anders “onzichtbare” verzenders krijgt die je deliverability ondermijnen.
Voorbeeld: Mailchimp zonder je reguliere e-mail te verstoren
Een veelgestelde vraag is of het instellen van DNS-records voor Mailchimp je normale e-mail in de weg zit. In de praktijk hoeft dat niet zo te zijn. Je voegt DKIM-records toe die specifiek voor Mailchimp gelden, je zorgt dat je DMARC aanwezig is, en alleen als Mailchimp daarom vraagt pas je je SPF aan door je bestaande beleid uit te breiden met include:servers.mcsv.net. Daarmee maak je jouw domein geschikt voor verzending via Mailchimp, terwijl je reguliere mailstroom gewoon blijft werken, mits je het totaaloverzicht bewaakt.
Belangrijk: de exacte DKIM en verificatierecords die je van een platform krijgt kunnen per account of domein verschillen en kunnen ook veranderen. Gebruik voorbeelden dus alleen als referentie voor het type record en de manier van invoeren, niet als “vaste waarden”.
Praktische checks: zo beoordeel je of je DNS voor e-mailauthenticatie klopt
Als je SPF, DKIM en DMARC goed instelt voor je domein, wil je ook kunnen controleren of het doet wat je verwacht. Zonder een supporthandleiding uit te schrijven, kun je dit op hoofdlijnen zo benaderen:
- Controleer of je domein maar één SPF-beleid publiceert en of alle verzenders daarin zijn meegenomen.
- Controleer of DKIM-records exact overeenkomen met wat je verzendplatform vraagt, inclusief selector en recordtype.
- Controleer of DMARC op _dmarc staat en dat het beleid aansluit bij je volwassenheid: eerst monitoren, dan aanscherpen.
- Verstuur testmails naar meerdere providers en kijk of SPF, DKIM en DMARC slagen in de headers.
Voor achtergrond en uitleg over e-mailspoofing en verdedigingslagen kun je ook het NCSC raadplegen. Zij beschrijven het probleem en de noodzaak van maatregelen vanuit securityperspectief: NCSC over e-mailspoofing.
Veelgemaakte fouten bij “Hoe stel je SPF, DKIM en DMARC goed in voor je domein?”
In audits en migraties komen we een aantal patronen steeds weer tegen. Deze fouten zorgen niet alleen voor lagere deliverability, maar ook voor onnodige complexiteit in beheer.
1) DKIM goed, maar DMARC ontbreekt
DKIM alleen is een goede stap, maar zonder DMARC ontbreekt een duidelijk beleid voor ontvangers. Bovendien mis je rapportage, waardoor je geen zicht hebt op misbruik en misconfiguraties. DMARC maakt het geheel af.
2) SPF breidt uit, maar raakt “rommelig”
SPF groeit vaak organisch: er komt een include bij voor een nieuwsbrief, later nog één voor een ticketingsysteem, en daarna een applicatieplatform. Zonder periodiek onderhoud kan je beleid te lang worden of tegen limieten aanlopen. Dan krijg je foutieve SPF-evaluaties, precies wat je niet wil.
3) Verkeerd invullen van DNS-namen
Bij CNAME-records voor DKIM en bij DMARC zien we regelmatig dat men per ongeluk de volledige domeinnaam in het “naam”-veld zet, terwijl het paneel dat al automatisch aanvult. Het resultaat is een record op de verkeerde plek, waardoor verificatie faalt. Let ook op details die je verzendplatform expliciet noemt, zoals het afsluiten van een CNAME-doel met een punt of het plaatsen van aanhalingstekens rond DMARC-waarden.
4) DMARC te snel op “reject”
Een streng DMARC-beleid kan uitstekend zijn, maar alleen als je zeker weet dat al je legitieme verzenders correct authenticeren. Als je te snel naar “reject” gaat, kun je echte mail blokkeren zoals facturen, orderbevestigingen of supportreacties. Bouw dit gecontroleerd op.
Beheer, eigenaarschap en continuïteit: DNS en je domeinnaam als fundament
E-mailauthenticatie staat of valt met goed domeinbeheer. Je DNS is de plek waar je beleid publiceert, maar ook waar fouten snel impact hebben. Zeker als meerdere partijen aan hetzelfde domein werken, is het verstandig om eigenaarschap en wijzigingen strak te organiseren.
Als je domein nog niet op de juiste plek staat of je wil beheer centraliseren, kan het logisch zijn om je domein onder te brengen bij één partij die DNS, e-mail en hosting goed kan overzien. In dat geval kun je kijken naar een domeinnaam registreren zodat je het beheer overzichtelijk houdt. En als je domein al elders staat maar je wil migreren naar een omgeving waar je DNS en support direct geregeld zijn, dan kan een domeinnaam verhuizen een praktische stap zijn.
Hoe stel je SPF, DKIM en DMARC goed in voor je domein als je groeit
Wat “goed” is, hangt af van je situatie. Een eenmanszaak met alleen Microsoft 365 heeft een ander verzendlandschap dan een organisatie met meerdere applicaties, marketingplatformen en afdelingen. Toch gelden er een paar principes die bijna altijd helpen:
- Breng alle verzenders in kaart: menselijk en geautomatiseerd.
- Houd DNS simpel: liever één SPF die klopt dan meerdere die elkaar tegenspreken.
- Gebruik DKIM waar mogelijk op alle uitgaande stromen, zeker bij bulk en marketing.
- Zet DMARC neer, begin desnoods met monitoren en bouw op naar strenger beleid.
- Plan periodiek onderhoud, bijvoorbeeld bij platformwissels, rebranding of nieuwe tools.
In groeiende omgevingen is het ook verstandig om te kijken naar de plek waar je applicaties draaien. Als je meer mailstromen vanuit webapplicaties krijgt, dan wil je een stabiele basis die je kunt schalen en beheren. In veel gevallen past Cloud Hosting dan beter bij de toekomst dan allerlei losse oplossingen, juist omdat je makkelijker kunt standaardiseren en monitoren.
Veelgestelde vragen
1) Hoe stel je SPF, DKIM en DMARC goed in voor je domein zonder je bestaande e-mail te breken?
Begin met inventariseren welke systemen namens jouw domein mailen: je mailboxplatform, marketingtooling en applicaties. DKIM-records voor een externe verzender kun je vaak toevoegen zonder bestaande mail te beïnvloeden, omdat ze selector specifiek zijn. Wees met SPF en DMARC iets voorzichtiger: breid SPF gecontroleerd uit en start DMARC bij voorkeur met een beleid dat eerst inzicht geeft, zodat je ziet wat er gebeurt voordat je strenger wordt.
2) Moet ik SPF, DKIM en DMARC instellen als ik alleen nieuwsbrieven verstuur?
Ja, zeker bij bulk e-mail is authenticatie belangrijk, omdat ontvangers extra streng zijn op reputatie en spoofing. DKIM helpt je nieuwsbrieven betrouwbaarder te maken en verlaagt de kans op spamclassificatie. DMARC zorgt vervolgens dat jouw domein minder aantrekkelijk is voor misbruik en geeft je rapportage over pogingen tot spoofing.
3) Wat is belangrijker: SPF of DKIM?
In moderne mailflow is DKIM vaak bepalend voor betrouwbare authenticatie, omdat het op berichtniveau werkt en niet alleen op serverniveau. SPF blijft belangrijk om verzenders te autoriseren, maar kan stuklopen op forwarding of complexe routes. DMARC maakt het plaatje compleet door te bepalen hoe ontvangers met failures omgaan en door alignment af te dwingen.
4) Waarom vraagt een platform soms om aanhalingstekens bij een DMARC-record?
Sommige DNS-beheersystemen of validaties verwachten dat de volledige TXT-waarde als één string wordt ingevoerd en adviseren daarom aanhalingstekens. Andere systemen voegen die impliciet toe of verwerken TXT-strings anders. Als jouw verzendplatform of DNS-omgeving expliciet aangeeft dat de waarde tussen aanhalingstekens moet, volg je dat advies om misinterpretatie te voorkomen.
5) Mailchimp vraagt om DKIM CNAME-records. Waarom zijn dat geen TXT-records?
Bij sommige platforms verwijst een CNAME naar een domein waar de sleutelpublicatie en beheer centraal geregeld wordt. Dat maakt sleutelrotatie en beheer voor de dienstverlener eenvoudiger, terwijl jij alleen de verwijzing in DNS hoeft te zetten. Het belangrijkste is dat je exact de naam en het doel overneemt zoals het platform opgeeft, omdat die waarden gepersonaliseerd kunnen zijn.
6) Hoe stel je SPF, DKIM en DMARC goed in voor je domein als je meerdere verzenders hebt?
Dan draait het om regie: je hebt één samenhangend SPF-beleid nodig dat alle verzendbronnen dekt, en je wil per verzender DKIM correct activeren zodat berichten cryptografisch ondertekend zijn. DMARC zet je vervolgens neer als overkoepelend beleid, waarbij je gecontroleerd aanscherpt zodra je ziet dat alles netjes slaagt. In complexere omgevingen loont het om periodiek te herijken, bijvoorbeeld na toolwissels of nieuwe applicaties.
Afsluiting: wil je dat we meekijken naar jouw domein en mailflow?
Als je SPF, DKIM en DMARC goed instelt voor je domein, voorkom je veel ellende met deliverability en verklein je de kans op misbruik van je domeinnaam. Tegelijk snappen we dat DNS en e-mailauthenticatie snel onoverzichtelijk worden zodra je meerdere systemen gebruikt, of als je niet dagelijks met mailheaders en records bezig bent.
Neem gerust contact met ons op. We denken met je mee op een nuchtere manier, controleren samen met jou welke verzenders je gebruikt en helpen je de juiste keuzes te maken in DNS en beheer. Of het nu gaat om het verbeteren van je e-mailauthenticatie, het centraliseren van domeinbeheer of het neerzetten van een stabiele basis op Cloud Hosting: je krijgt bij ons direct iemand aan tafel die de techniek begrijpt en het helder uitlegt.
