Stop met gokken bij je DNS: een ontwikkelaarsvriendelijke rondleiding langs MX, SPF, DKIM en DMARC

Waarom DNS-records voor e-mail nu belangrijk zijn

E-mailauthenticatie was vroeger optioneel. In 2026 is het een basisvoorwaarde. Gmail en Outlook dwingen beide SPF en DKIM af voor bulkverzenders, en DMARC wordt snel verplicht voor elk domein dat transactionele e-mail verstuurt. Als je DNS-records verkeerd zijn, komen je e-mails niet aan—geen bounce, geen waarschuwing, alleen stilte.

Het probleem is dat deze records zijn gedocumenteerd als RFCs, niet als tools. De meeste ontwikkelaars kopiëren voorbeelden uit de installatiehandleiding van hun e-mailprovider en hopen op het beste. Dat werkt totdat je problemen moet oplossen, een tweede verzenddienst moet toevoegen, of aan een klant moet uitleggen waarom e-mails van hun contactformulier in spam belanden.

Deze gids loopt door MX, SPF, DKIM en DMARC in de volgorde waarin je ze in de praktijk tegenkomt, met genoeg detail om ze correct te configureren en genoeg context om ze te debuggen wanneer ze stukgaan.

MX-records: waar inkomende e-mail naartoe gaat

MX-records vertellen het internet welke mailservers e-mail voor je domein accepteren. Ze zijn de eenvoudigste van de vier, maar ook het makkelijkst verkeerd te configureren.

Een MX-record heeft twee delen: een prioriteitsnummer en een hostnaam. Lagere prioriteitsnummers worden eerst geprobeerd. Als je Google Workspace gebruikt, kunnen je MX-records er zo uitzien:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

De punten aan het einde zijn belangrijk—ze geven aan dat de hostnaam volledig gekwalificeerd is. De meeste DNS-providers voegen ze automatisch toe, maar niet allemaal.

Veelgemaakte fouten: MX-records naar een A-record laten wijzen in plaats van naar een hostnaam, alle prioriteiten op hetzelfde nummer zetten (waardoor het nut van back-ups verdwijnt), of vergeten oude MX-records te verwijderen wanneer je van provider migreert. Verouderde MX-records staan daar niet gewoon onschuldig—ze kunnen mailloops veroorzaken of aflevering over twee inboxen verdelen.

Als je je eigen contactformulier draait en spam wilt vermijden zonder afhankelijk te zijn van diensten van derden, is begrijpen hoe formulieren spamvectoren worden een nuttig startpunt.

SPF: welke servers namens jou mogen verzenden

SPF (Sender Policy Framework) is een TXT-record dat de IP-adressen en domeinen opsomt die gemachtigd zijn om namens je domein e-mail te verzenden. Het is de eerste controle die de meeste mailservers uitvoeren wanneer ze een bericht ontvangen dat beweert van jou te zijn.

Een basis-SPF-record ziet er zo uit:

v=spf1 include:_spf.google.com ~all

Uitgesplitst:

• v=spf1 declareert de SPF-versie
• include:_spf.google.com delegeert naar Google's SPF-record
• ~all is een soft fail—wijs mail van niet-vermelde bronnen af, maar wees niet te strikt

Je kunt ook ip4: of ip6: gebruiken om specifieke adressen op een whitelist te zetten, of a en mx om te verwijzen naar de A- en MX-records van je domein. Het all-mechanisme aan het einde bepaalt wat er gebeurt met mail van bronnen die je niet hebt vermeld: -all is een hard fail (weigeren), ~all is soft fail (markeren als verdacht), ?all is neutraal (geen oordeel), en +all is een vrijbrief (gebruik dit niet).

SPF heeft twee scherpe randjes. Ten eerste breekt het wanneer e-mail wordt doorgestuurd, omdat de doorsturende server niet in je SPF-record staat. Ten tweede hebben SPF-records een lookuplimiet van tien DNS-query's. Als je te veel diensten van derden opneemt, overschrijd je de limiet en stopt SPF met werken. De oplossing is je SPF-record flattenen—vervang include:-directives door de daadwerkelijke IP-reeksen—maar dit vereist onderhoud wanneer providers hun IP's wijzigen.

DKIM: cryptografisch bewijs van afzenderidentiteit

DKIM (DomainKeys Identified Mail) voegt een digitale handtekening toe aan je uitgaande e-mail. De ontvangende server controleert de handtekening tegen een publieke sleutel die in je DNS is gepubliceerd. Als de handtekening geldig is en er niet met het bericht is geknoeid, slaagt DKIM.

In tegenstelling tot SPF overleeft DKIM doorsturen, omdat de handtekening met het bericht meereist. Het is ook flexibeler—je kunt meerdere DKIM-sleutels hebben voor verschillende verzenddiensten, elk met een eigen selector.

Een DKIM-DNS-record ziet er zo uit:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

De selector (default in dit voorbeeld) is willekeurig—je e-mailprovider kiest die. De p=-waarde is de publieke sleutel, meestal een lange base64-gecodeerde string. Je e-mailprovider genereert de private sleutel en gebruikt die om uitgaande berichten te ondertekenen.

DKIM-instelling wordt bijna altijd door je e-mailprovider afgehandeld. Jouw taak is het TXT-record dat zij geven te kopiëren en in je DNS te plakken. Het lastige is dat sommige DNS-providers niet goed omgaan met lange TXT-records—ze kappen ze af of vereisen dat je de waarde opsplitst in meerdere strings tussen aanhalingstekens.

Om te verifiëren dat DKIM werkt, stuur je een testmail naar een Gmail-adres en controleer je de headers. Zoek naar dkim=pass in de header Authentication-Results.

DMARC: beleid afdwingen en rapportage

DMARC (Domain-based Message Authentication, Reporting and Conformance) brengt SPF en DKIM samen en vertelt ontvangende servers wat ze moeten doen wanneer authenticatie faalt. Het schakelt ook rapportage in, zodat je kunt zien wie e-mail als jouw domein verzendt—zowel legitiem als gespooft.

Een minimaal DMARC-record ziet er zo uit:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none betekent alleen monitoren—mislukte berichten niet weigeren of in quarantaine plaatsen
• rua=mailto:[email protected] specificeert waar aggregatierapporten naartoe moeten worden gestuurd

Zodra je zeker weet dat SPF en DKIM werken, kun je het beleid aanscherpen naar p=quarantine (mislukkingen naar spam sturen) of p=reject (ze direct bouncen). Je kunt ook een subdomeinbeleid instellen met sp= en met pct= specificeren op welk percentage berichten het beleid moet worden toegepast.

DMARC-rapporten zijn XML-bestanden die dagelijks door grote ontvangers worden verstuurd. Ze zijn uitgebreid en rauw moeilijk te lezen, maar ze vertellen je precies welke berichten wel of niet door authenticatie kwamen en waarom. Als je ziet dat legitieme mail wordt geweigerd, laten de rapporten zien welke SPF- of DKIM-controle faalt.

Eén valkuil: DMARC vereist alignment. Voor SPF moet het domein in de header Return-Path overeenkomen met het domein in de header From (of een subdomein zijn). Voor DKIM moet het d=-domein in de DKIM-handtekening overeenkomen met het From-domein. Als je een verzenddienst van derden gebruikt, moeten zij aangepaste return paths of DKIM-ondertekening met jouw domein ondersteunen, niet met dat van hen.

Je huidige setup auditen

De meeste DNS-problemen zijn onzichtbaar totdat ze een probleem veroorzaken. Zo controleer je je records voordat er iets breekt:

1. Query je MX-records: dig MX example.com zou de hostnamen en prioriteiten van je mailservers moeten teruggeven. Controleer of ze overeenkomen met de documentatie van je e-mailprovider.

1. Controleer SPF-syntax: dig TXT example.com en zoek naar het v=spf1-record. Haal het door een SPF-validator om syntaxfouten en schendingen van de lookuplimiet te vinden.

1. Verifieer DKIM-sleutels: Stuur een testmail en inspecteer de header DKIM-Signature. Extraheer de selector en het domein, en query daarna dig TXT selector._domainkey.example.com om te bevestigen dat de publieke sleutel bestaat.

1. Valideer DMARC-beleid: dig TXT _dmarc.example.com zou je DMARC-record moeten teruggeven. Zorg dat rua= wijst naar een adres dat je daadwerkelijk monitort.

1. Test end-to-end: Gebruik een dienst zoals mail-tester.com of stuur naar een Gmail-adres en controleer de volledige headers. Zoek naar spf=pass, dkim=pass en dmarc=pass in de header Authentication-Results.

Als je debugt waarom e-mails niet aankomen, zijn de headers je beste hulpmiddel. In de meeste mailclients kun je ruwe headers bekijken—in Gmail open je het bericht, klik je op de drie puntjes en selecteer je 'Origineel weergeven'. De header Authentication-Results vertelt je precies welke controle faalde en waarom.

Wanneer je subdomeinbeleid gebruikt

Als je e-mail verzendt vanaf meerdere subdomeinen—bijvoorbeeld newsletter.example.com voor marketing en app.example.com voor transactionele mail—kun je per subdomein DMARC-beleid instellen. Zo kun je strikte beleidsregels afdwingen op subdomeinen die je beheert, terwijl je een losser beleid op je hoofddomein houdt.

De afweging is complexiteit. Elk subdomein heeft zijn eigen SPF-, DKIM- en DMARC-records nodig, en je moet bijhouden welke verzenddiensten voor welke subdomeinen zijn gemachtigd. Voor de meeste kleine teams is één goed geconfigureerd domein eenvoudiger en net zo veilig.

Wat te doen wanneer authenticatie breekt

De meest voorkomende foutmodus is een nieuwe verzenddienst toevoegen zonder DNS bij te werken. Als je een nieuwe provider voor transactionele e-mail gaat gebruiken, moet je hun SPF-include of IP-reeks toevoegen, DKIM-ondertekening met je domein configureren en DMARC-alignment verifiëren.

Het op één na meest voorkomende probleem is doorsturen. Als gebruikers je e-mail naar een ander adres doorsturen, faalt SPF omdat de doorsturende server niet in je SPF-record staat. DKIM overleeft doorsturen meestal, dus zolang DKIM slaagt en je DMARC-beleid gedeeltelijke alignment toestaat, zou het bericht nog steeds moeten worden afgeleverd. Als je ziet dat doorgestuurde mail wordt geweigerd, controleer dan je DMARC-beleid—p=reject met strikte alignment breekt doorsturen.

Het derde probleem is DNS-propagatie. Wijzigingen in DNS-records kunnen uren nodig hebben om te propageren, en verschillende mailservers cachen records voor verschillende lengtes. Als je net een record hebt bijgewerkt en het werkt niet, wacht dan een paar uur en test opnieuw. Je kunt propagatie controleren met een tool zoals whatsmydns.net.

Belangrijkste punten

• MX-records routeren inkomende mail; SPF, DKIM en DMARC authenticeren uitgaande mail. Ze lossen verschillende problemen op en je hebt ze alle vier nodig.
• SPF breekt bij doorsturen en heeft een lookuplimiet van tien. DKIM overleeft doorsturen maar vereist configuratie per dienst. DMARC brengt ze samen en maakt rapportage mogelijk.
• Begin met p=none in DMARC, monitor de rapporten een paar weken en verscherp daarna naar p=quarantine of p=reject zodra je zeker weet dat legitieme mail slaagt.
• DNS-fouten zijn stil. Test je configuratie met echte e-mail en inspecteer de headers om te bevestigen dat SPF, DKIM en DMARC slagen.
• Als authenticatie breekt nadat je een nieuwe verzenddienst hebt toegevoegd, controleer dan SPF-includes, DKIM-selectors en DMARC-alignment. De headers vertellen je welke controle faalde.

FAQ

Q: Kan ik meerdere SPF-records hebben?

A: Nee. Meerdere SPF-records zorgen ervoor dat ze allemaal worden genegeerd. Als je meerdere diensten moet autoriseren, gebruik dan include:-directives binnen één SPF-record, of vermeld IP-reeksen direct. Let op de lookuplimiet van tien.

Q: Heb ik DMARC nodig als ik maar een paar e-mails per dag verstuur?

A: Ja. DMARC gaat niet over volume—het gaat erom te bewijzen dat je bent wie je zegt dat je bent. Zelfs kleine domeinen profiteren van DMARC, omdat het spoofing voorkomt en je zicht geeft op afleverproblemen. Begin met p=none en een rapportageadres.

Q: Wat gebeurt er als DKIM en SPF allebei falen, maar de e-mail legitiem lijkt?

A: Dat hangt af van je DMARC-beleid. Als p=none, wordt de mail met een waarschuwing afgeleverd. Als p=quarantine, gaat hij naar spam. Als p=reject, wordt hij gebouncet. Daarom moet je DMARC-rapporten monitoren voordat je een strikt beleid afdwingt—mogelijk heb je legitieme afzenders waar je niets van wist.

Q: Kan ik dezelfde DKIM-sleutel voor meerdere domeinen gebruiken?

A: Technisch gezien ja, maar doe het niet. Elk domein zou zijn eigen DKIM-sleutelpaar moeten hebben. Sleutels delen maakt rotatie moeilijker en vergroot de blast radius als een private sleutel wordt gecompromitteerd.

Q: Hoe vaak moet ik DKIM-sleutels roteren?

A: Er is geen universele regel, maar één keer per jaar is redelijk voor de meeste domeinen. Als je vermoedt dat een sleutel is gecompromitteerd, roteer dan onmiddellijk. Zorg dat je de nieuwe publieke sleutel in DNS publiceert voordat je begint te ondertekenen met de nieuwe private sleutel, en laat de oude sleutel na rotatie nog een paar dagen in DNS staan om vertraagde mail af te handelen.

<!-- tool-cta:start -->

💡 Probeer dit: Inspecteer het gepubliceerde beleid van elk domein met DMARC Lookup om te zien hoe MX-, SPF- en DMARC-records in de praktijk samenhangen.

<!-- tool-cta:end -->

Bronnen

• RFC 7208: Sender Policy Framework (SPF) — De SPF-specificatie, inclusief syntaxregels en de lookuplimiet van tien.
• RFC 6376: DomainKeys Identified Mail (DKIM) — De DKIM-specificatie, over het genereren en verifiëren van handtekeningen.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — De DMARC-specificatie, inclusief beleidssyntax en formaat voor aggregatierapportage.
• Google Workspace: Prevent spoofing and spam — Praktische richtlijnen voor SPF-, DKIM- en DMARC-configuratie voor Google Workspace-domeinen.