SPF, DKIM en DMARC voor WordPress e-mail deliverability

Als je dit leest, heb je waarschijnlijk al een SMTP-plugin geïnstalleerd en komt je WordPress-mail nog steeds in spam terecht. De SMTP-laag zorgt dat het bericht bij een echte verzendservice aankomt; de DNS-laag vertelt Gmail, Outlook en Yahoo dat die verzendservice namens jouw domein mag praten. Zonder die DNS-laag kunnen ontvangers jouw legitieme mail niet onderscheiden van iemand die je From-adres spooft. Sinds februari 2024 stoppen ze met gokken en beginnen ze met weigeren.

Dit artikel loopt door wat SPF, DKIM en DMARC precies doen, hoe de huidige baseline eruitziet, en hoe je alle drie de records voor een WordPress-site publiceert zonder jezelf uit je eigen inbox te locken.

Waarom WordPress-mail in spam belandt: het authenticatiegat

Het standaard wp_mail()-pad van WordPress geeft elk bericht door aan PHP's mail()-functie, die vervolgens via de lokale MTA vanaf het IP van je webserver verstuurt. Dat IP staat bijna nooit in de SPF-record van je domein, de server heeft geen DKIM-privésleutel voor jouw domein, en de From-header zegt gewoon wordpress@jouwsite.nl. Ontvangende mailservers voeren drie checks uit:

• Mag dit IP namens jouwsite.nl versturen? (SPF)
• Is het bericht gesigneerd met een sleutel die onder jouwsite.nl gepubliceerd staat? (DKIM)
• Komt het From-domein overeen met een van de twee domeinen die zojuist geslaagd zijn? (DMARC-alignment)

Alle drie falen, en het bericht belandt in de spamfolder of wordt geweigerd. Sinds de bulk sender-regels van Google en Yahoo op 1 februari 2024 van kracht zijn, en Microsoft's gelijkwaardige handhaving op 5 mei 2025 is begonnen, is de praktische baseline voor elk WordPress-domein SPF + DKIM + DMARC, ongeacht je volume. De bulk-sender drempels bepalen alleen of handhaving een spam-vlag of een harde weigering wordt; de eis zelf geldt voor iedereen.

Voordat je de DNS-records toevoegt, moet de WordPress-kant klaar zijn: zet een echte SMTP-relay op via een service die DKIM voor jouw domein kan signen. Heb je dat nog niet gedaan, werk dan eerst WordPress SMTP-configuratie door. SPF, DKIM en DMARC helpen alleen als er een echte verzendservice is om te authenticeren; ze repareren PHP mail() niet.

Wat SPF doet en hoe je de record aanmaakt

SPF (Sender Policy Framework, RFC 7208) is een DNS TXT-record die bijhoudt welke mailservers namens jouw domein mogen versturen op basis van de envelope sender. Wanneer een ontvangende mailserver een bericht krijgt dat beweert van jouwsite.nl te komen, kijkt hij naar je SPF-record, vergelijkt het verzendende IP met de lijst, en geeft pass, fail, softfail, neutral of permerror terug.

Een SPF-record ziet er zo uit:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.0/24 -all

Wat elk stukje betekent:

• v=spf1 markeert dit als SPF versie 1. Verplicht.
• include:_spf.google.com delegeert naar Google's SPF-record (dekt Google Workspace uitgaand).
• include:mailgun.org delegeert naar Mailgun's SPF-record (dekt je transactionele verzending).
• ip4:203.0.113.0/24 staat een specifieke IP-range direct toe. Kies dit als je een vast uitgaand IP hebt, bijvoorbeeld bij een dedicated server.
• -all is een hard fail. Alles wat niet matcht met de eerdere mechanisms moet geweigerd worden. Gebruik -all in productie. ~all (softfail) is acceptabel in een testfase als je wilt dat ontvangers wel accepteren maar flaggen in plaats van direct weigeren.

Hoe je de record publiceert

1. Maak in je DNS-zone een TXT-record aan op de apex (de host is @ of leeg, afhankelijk van je DNS-provider).
2. Zet als waarde de SPF-string die je verzendservice aanlevert (Mailgun, SendGrid, Amazon SES en Postmark laten de exacte include zien tijdens de domeinverificatie-wizard).
3. Opslaan. DNS-propagatie gaat bij moderne providers in minuten; oudere providers kunnen tot 24 uur nodig hebben.

Slechts één SPF-record per domein. RFC 7208 verbiedt meerdere SPF TXT-records op dezelfde host expliciet. Publiceer je er twee, dan behandelen de meeste ontvangers het resultaat als permerror en faalt het bericht. Voeg je een tweede verzendprovider toe, merge die dan in het bestaande record door een extra include: toe te voegen in plaats van een nieuw TXT-record aan te maken.

Controleer de record

Plak je domein in MXToolbox SPF lookup en controleer of "SPF Record Valid" en "SPF Syntax Check" groen zijn. Je hoort maar één SPF-record te zien. Meldt MXToolbox er twee, verwijder er dan één in de DNS-zone-editor van je hostingpaneel en merge de includes in het overgebleven record.

Heb je SSH-toegang? Run dig TXT jouwsite.nl +short en check dat je één regel ziet die begint met "v=spf1".

SPF alleen is niet voldoende en is dat al niet meer sinds DMARC werd geïntroduceerd. Het valideert de envelope sender, die ontvangers nooit in de e-mailclient laten zien, en het breekt zodra een bericht wordt doorgestuurd omdat de forwarding-server de envelope aanpast. De andere twee records dichten die gaten.

Wat DKIM doet en waar de sleutel leeft

DKIM (DomainKeys Identified Mail, RFC 6376) ondertekent het bericht cryptografisch (de body en geselecteerde headers) met een privésleutel die bij je verzendservice ligt. De handtekening reist mee in de DKIM-Signature-header van het bericht zelf. Ontvangers halen de bijbehorende publieke sleutel op uit jouw DNS-zone en verifiëren dat de gesigneerde inhoud onderweg niet gewijzigd is en dat het signing-domein voor het bericht instaat.

Een DKIM DNS-record ziet er zo uit:

s1._domainkey.jouwsite.nl.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

De belangrijke onderdelen:

• Selector (s1 in het voorbeeld): een arbitrair label waarmee je meerdere sleutels per domein kunt publiceren. Je verzendservice kiest de naam; jij publiceert gewoon wat ze aanleveren.
• v=DKIM1: DKIM-versie. Verplicht.
• k=rsa: sleutelalgoritme. rsa is de default en wat elke grote service gebruikt.
• p=...: de base64-gecodeerde publieke sleutel. Een lege p= trekt de sleutel in.

De WordPress-site zelf kan geen DKIM-signen. Alleen de SMTP-relay die het bericht daadwerkelijk op de lijn zet, kan signen, want alleen die heeft de privésleutel. Daarom wordt DKIM opgezet bij de verzendservice (Mailgun, SendGrid, Amazon SES, Postmark, Google Workspace, Microsoft 365), niet in WordPress. De service genereert het sleutelpaar, bewaart de privésleutel en geeft jou de publieke sleutel om in je DNS-zone te publiceren.

Gebruik een 2048-bit sleutel, geen 1024

RFC 6376 legt de ondergrens op 1024 bits, maar onderzoek heeft aangetoond dat 1024-bit DKIM-sleutels in minder dan vier dagen met cloud compute te factoriseren zijn, en Gmail heeft publiekelijk voorkeur uitgesproken voor 2048-bit sleutels. Genereer 2048-bit RSA-sleutels voor elke nieuwe opzet. De enige reden om naar 1024 terug te vallen is als je DNS-provider geen TXT-waarde langer dan 255 tekens kan opslaan én die waarde niet automatisch over meerdere quoted strings kan splitsen. Dat is zeldzaam in 2026, maar het gebeurt nog wel bij oudere registrar-interfaces.

Zie je in je verzendservice "1024-bit" en "2048-bit" als opties staan, kies dan 2048. Biedt de service geen keuze, check dan de sleutellengte in DNS door s1._domainkey.jouwsite.nl (vervang s1 door je daadwerkelijke selector) in te voeren in MXToolbox DKIM lookup. Het aantal tekens van de p=-waarde komt ruwweg overeen met de sleutellengte. Een 1024-bit sleutel levert een p= van rond de 216 tekens op; een 2048-bit sleutel rond de 392 tekens. Zit jouw record aan de lage kant, kijk dan in het dashboard van je verzendservice of je een nieuwe sleutel op 2048 bits kunt genereren.

Heb je SSH-toegang? Run dig TXT s1._domainkey.jouwsite.nl +short om de raw record direct te bekijken.

De managed hosting DKIM-val

Verschillende managed WordPress-hosts configureren DKIM vooraf in voor hun eigen verzenddomein, niet voor het jouwe. De MailChannels-integratie van Kinsta bijvoorbeeld ondertekent uitgaande mail met d=kinstamailservice.com. De signature slaagt voor dat domein, maar DMARC checkt vervolgens of het signing-domein overeenkomt met de From-header. kinstamailservice.com komt niet overeen met jouwsite.nl, dus DMARC faalt, ook al slaagde DKIM zelf.

De oplossing: gebruik een transactionele e-mailservice (Mailgun, SendGrid, Postmark, Amazon SES, Resend) waarbij je je eigen verzenddomein kunt verifiëren en die een DKIM-sleutel onder jouwsite.nl publiceert. Dan slagen zowel DKIM-verificatie als DMARC-alignment. Biedt je managed host "custom domain DKIM" aan, gebruik dat; zo niet, route je mail dan via een aparte transactionele service.

Controleer de record

Na publiceren test je de hele signing-keten door een echt bericht vanuit WordPress naar een Gmail-inbox te sturen, het bericht te openen, op het drie-puntjes-menu te klikken en Origineel weergeven te kiezen. De Authentication-Results-header hoort er dan zo uit te zien:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@jouwsite.nl header.s=s1

dkim=pass en header.i=@jouwsite.nl zijn waar je naar zoekt. Als header.i een ander domein toont, is de handtekening gealignd tegen iets anders dan je From-domein en zal DMARC falen.

Wat DMARC doet en hoe je het in fases opzet

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) doet twee dingen: het vertelt ontvangers wat ze met authenticatie-fouten moeten doen, én het vraagt ze om aggregate reports terug te sturen zodat je kunt zien wie er namens jouw domein mail verstuurt.

Het kernconcept dat DMARC toevoegt bovenop SPF en DKIM is alignment. Een geslaagde SPF- of DKIM-check is op zichzelf niet genoeg; het domein dat is geslaagd, moet ook overeenkomen met het From-domein dat de gebruiker ziet. Zonder alignment kan een spammer goedkoop-domein.com kopen, een geldige SPF-record voor dat domein publiceren, en mail versturen met From: jij@jouwsite.nl die gewoon voor SPF slaagt. DMARC vangt dat af.

Een DMARC DNS-record ziet er zo uit:

_dmarc.jouwsite.nl.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@jouwsite.nl; fo=1"

De belangrijke tags:

• v=DMARC1: versie. Verplicht.
• p=none | p=quarantine | p=reject: de handhavingspolicy. none is monitor-only, quarantine routeert fouten naar spam, reject weigert fouten al op de server. Begin bij none en werk omhoog.
• rua=mailto:dmarc@jouwsite.nl: waar dagelijkse aggregate reports naartoe moeten.
• fo=1: vraag om een forensisch rapport als óf SPF óf DKIM faalt (niet alleen als beide falen). Vooral nog symbolisch; zie de volgende sectie.
• sp=reject: optioneel, past de policy apart toe op subdomeinen. Zonder sp erven subdomeinen de waarde van p.
• pct=10: optioneel, past de policy toe op een percentage van de falende berichten. Nuttig tijdens uitrol.

De gefaseerde uitrol: none naar quarantine naar reject

Publiceer niet op dag één p=reject. Direct naar p=reject gaan is de snelste manier om je legitieme WordPress-mail voor weken te breken. Elke vergeten verzendbron (backup-notificaties, uptime-monitors, nieuwsbrief-platforms, de WooCommerce order queue van een tweede plugin, het CRM dat je twee jaar terug opzette) zal zijn mail geweigerd zien worden. Zonder retry, zonder logging aan de ontvangerkant, zonder zichtbaarheid voor jou. Ik heb kleine ondernemers daardoor twee weken aan klantfacturen zien missen.

De juiste uitrolvolgorde van dmarcian is:

1. Week 0: publiceer p=none; rua=mailto:dmarc@jouwsite.nl. Geen handhaving. Alleen data verzamelen.
2. Week 1 tot 4: lees de aggregate reports. Elke legitieme verzendbron hoort zichtbaar te zijn en te slagen voor SPF-alignment en DKIM-alignment. Repareer wat faalt. Bij een drukke WooCommerce-winkel zijn vier weken verstandig; bij een kleine brochure-site met één contactformulier zijn twee weken genoeg.
3. Week 4 of 5: ga naar p=quarantine; pct=10. Nu gaat 10 procent van de falende berichten naar de spamfolder van de ontvanger. Blijf de rapporten volgen voor legitieme bronnen die opeens beginnen te falen.
4. Week 6: verhoog naar p=quarantine; pct=25, daarna pct=50, daarna pct=100 in een tot twee weken.
5. Week 8 tot 10: ga naar p=reject; pct=10, daarna pct=25, pct=50, pct=100.

Voor een typische kleine WordPress-site met één of twee verzendbronnen kun je vier tot acht weken uittrekken. Voor een complexe site met meerdere geïntegreerde services (CRM, e-mailmarketing, transactioneel, interne notificaties) drie tot zes maanden. Dit haasten is dé meest voorkomende manier om je eigen mail te breken.

DMARC aggregate reports lezen, en waarom forensische rapporten dood zijn

DMARC-rapporten komen in twee smaken. Maar eentje daarvan is nog nuttig.

Aggregate reports (rua) zijn dagelijkse XML-bestanden die elke grote ontvanger terugstuurt naar het adres in je rua=-tag. Elk rapport somt de verzendende IP's op die namens jou probeerden te sturen, het volume per bron, de SPF- en DKIM-resultaten, de alignment-resultaten en de DMARC-dispositie (none, quarantine of reject). Ze bevatten nooit onderwerpen, bodies of ontvangeradressen, en dáárom hebben ze de privacy-regelgevingsgolf overleefd.

Ruwe XML is pijnlijk om te lezen. Pijp je rapporten in plaats daarvan naar een DMARC-analyzer. De gratis tiers bij dmarcian, EasyDMARC en MXToolbox DMARC reports geven je een dashboard-view van verzendbronnen, alignment-rates en trends. Wijs je rua=-tag naar het adres dat de analyzer je geeft (of naar je eigen inbox en forward het).

Forensische rapporten (ruf) geven in theorie een real-time geredacteerde kopie van individuele falende berichten. In de praktijk zijn ze grotendeels dood. Gmail stuurt geen ruf. Yahoo ook niet. De meeste grote providers zijn tussen 2020 en 2022 gestopt vanwege GDPR en gerelateerde privacy-zorgen. Je mag fo=1 best in je DMARC-record houden voor de kleinere ontvangers die nog wel forensische rapporten sturen, maar reken niet op ruf voor zichtbaarheid. Aggregate reports zijn je diagnostische tool.

Wat doe je in week 1 met aggregate reports:

1. Open je analyzer-dashboard.
2. Kijk naar de lijst met "sending sources". Elke legitieme afzender hoort daar te staan.
3. Controleer voor elke bron dat DKIM-alignment of SPF-alignment als geslaagd wordt weergegeven. Eén van de twee is genoeg voor DMARC om te slagen (DKIM is te verkiezen omdat het forwarding overleeft).
4. Als er een bron opduikt die je niet herkent, is dat óf een vergeten legitieme service, óf spoofing. Onderzoek het voordat je de policy verhoogt.
5. Als een legitieme bron faalt, repareer dat eerst, anders quarantaine je straks je eigen mail.

Je records end-to-end testen

Voor en na elke policy-wijziging run je twee end-to-end checks.

Check 1: MXToolbox SuperTool. Richt het op je domein en run de SPF-, DKIM- en DMARC-lookups. Verwachte output: drie groene "record found" resultaten zonder syntaxfouten. MXToolbox flagt ook SPF 10-lookup problemen, wat een ruwe DNS-query niet doet.

Check 2: mail-tester.com. Open mail-tester.com, kopieer het unieke adres dat ze tonen, en stuur een testmail vanuit WordPress naar dat adres (een wachtwoord-reset, een contactformulier-inzending, of welke echte wp_mail()-call dan ook). Klik daarna op "Then check your score". Een goed resultaat is 10 uit 10 met groene vinkjes op SPF, DKIM en DMARC. Rood vertelt je precies welke record fout zit.

Combineer beide: MXToolbox bevestigt dat de records syntactisch kloppen, mail-tester bevestigt dat een echt WordPress-bericht ze ook daadwerkelijk end-to-end authentiseert. Ik run beide elke keer als ik DNS aanpas of een verzendbron toevoeg.

Veelvoorkomende fouten die alles stilletjes slopen

Bijna elk "mijn DKIM slaagt maar DMARC faalt nog steeds"-ticket komt neer op één van deze.

Meerdere SPF-records op hetzelfde domein

RFC 7208 verbiedt dit, en ontvangers behandelen het als permerror. Het gebeurt wanneer iemand een tweede include toevoegt door een nieuw TXT-record aan te maken in plaats van het bestaande aan te passen, of wanneer een hosting-controlepaneel stilletjes een eigen SPF-record publiceert naast het record dat jij zelf hebt gezet. Check door je domein in MXToolbox SPF lookup te plakken. Meldt het meerdere SPF-records, merge de includes dan in één record via de DNS-zone-editor van je hostingpaneel en verwijder de andere.

De SPF 10-lookup limiet overschrijden

RFC 7208 sectie 4.6.4 staat maximaal 10 DNS-lookups per SPF-evaluatie toe. Mechanisms die meetellen: include, a, mx, ptr, exists, en de redirect-modifier. Mechanisms die niet meetellen: ip4, ip6, all.

De val is dat include: transitief is. include:_spf.google.com op zichzelf is één lookup, maar het SPF-record van Google bevat weer andere includes, die stuk voor stuk óók meetellen. Een WordPress-site die Google Workspace voor mail gebruikt, SendGrid voor transactioneel, Mailchimp voor nieuwsbrieven en een SaaS-CRM die vanuit nog een andere service verstuurt, zit zo op 11 of 12 lookups en belandt in permerror. DMARC behandelt het hele verhaal daarna als SPF-fail.

Oplossingen, in volgorde van voorkeur:

1. Consolideer je verzending. Heb je alle vier services écht nodig? Kies de kleinste set.
2. Vervang includes door ip4: voor services die een stabiele IP-range publiceren.
3. Vertrouw op DKIM-alignment voor DMARC, zodat een incidentele SPF-fail niet meteen DMARC omlegt.
4. SPF flattening services (Valimail legt de kanttekeningen uit): die vervangen je includes door de actuele IP-lijst. Goedkoop en effectief, totdat de IP's van je provider veranderen en je flattened record veroudert. Gebruik flattening alleen als je het kunt monitoren.

Void lookups die het record doen kantelen

SPF handhaaft ook een zachtere limiet: maximaal twee "void lookups" (DNS-queries die NXDOMAIN of een lege respons teruggeven) per evaluatie. Typefouten in include-targets en includes die naar uitgefaseerde domeinen wijzen triggeren allebei een void lookup. Boven de twee komen resulteert ook in permerror. Audit je includes telkens als je van verzendprovider wisselt.

Verkeerde DKIM-selector

Elke verzendservice hanteert z'n eigen selector-naamgeving: Mailgun gebruikt k1._domainkey, SendGrid gebruikt s1._domainkey en s2._domainkey, Google Workspace gebruikt google._domainkey. De selector verkeerd overnemen (of onder _domainkey publiceren zonder selector, wat sommige registrar-interfaces stilletjes doen) levert een DKIM-lookup op die niets oplevert. Het bericht is dan of ongesigneerd, of gesigneerd met een selector die niemand kan vinden. Controleer door de selector en het domein in te voeren in MXToolbox DKIM lookup, met de exacte selector die je service heeft gedocumenteerd. Heb je SSH-toegang? dig TXT selector._domainkey.jouwsite.nl +short geeft hetzelfde antwoord vanaf de command line.

p=reject zetten voordat je vergeten bronnen hebt gerepareerd

Hierboven al behandeld in de gefaseerde uitrol, maar het verdient herhaling: zet niet op dag één p=reject, en sla p=quarantine niet over. Elke keer dat ik een WordPress-site zijn eigen mail zag breken met DMARC, was het omdat iemand p=reject had gepubliceerd zonder eerst de aggregate reports te lezen.

WooCommerce en andere high-volume WordPress-afzenders

WooCommerce stuurt bestelbevestigingen, betalingsmeldingen, refund-notificaties, verzendupdates en klantfacturen, allemaal via wp_mail(). Dat betekent dat ze allemaal het SMTP-pad en de DKIM-opzet erven die je op WordPress-niveau hebt geconfigureerd. Er is geen aparte WooCommerce-authenticatielaag om te configureren.

Wat WooCommerce wel toevoegt is volume. Op een drukke webwinkel kun je de 5.000-berichten-per-dag-drempel passeren die Google en Microsoft gebruiken om domeinen als "bulk sender" te classificeren. Eenmaal geclassificeerd, is die status permanent, ongeacht je toekomstige volume. De bulk sender-eisen gaan verder dan de minimale baseline:

• Spam-complaint rate moet onder de 0,10 procent blijven (waarschuwingsdrempel) en strikt onder de 0,30 procent (harde limiet met handhaving).
• One-click unsubscribe (RFC 8058 List-Unsubscribe-Post) voor marketing- en promotieberichten.
• Geldige forward- en reverse DNS op de verzendende IP's.
• TLS op de transmissie.
• Functionele From- en Reply-To-adressen (een noreply@ dat hard bouncet wordt afgeraden).

Voor de meeste WooCommerce-shops is de praktische consequentie: gebruik een aparte transactionele e-mailservice (Postmark, Mailgun, Amazon SES) voor order-mail, gebruik een apart verzenddomein of subdomein voor marketing-mail die via Mailchimp of vergelijkbaar wordt verstuurd, en houd DMARC op allebei gealigned. Als je ooit hetzelfde domein via twee services wilt sturen, is een gangbaar patroon: transactionele mail vanaf jouwsite.nl en marketing-mail vanaf mail.jouwsite.nl, elk met zijn eigen gealignde authenticatieketen. De WooCommerce e-mail transport-documentatie bevestigt dat WooCommerce zelf transport-agnostisch is: elke mail gaat via wp_mail(), wat betekent dat elke mail de SMTP- en DKIM-opzet op WordPress-niveau erft.

Wanneer je moet escaleren

Heb je dit artikel doorlopen en faalt DMARC nog steeds af en toe, verzamel dan het volgende voordat je je host of verzendservice om hulp vraagt:

• Screenshots of tekstkopieën van je SPF-, DKIM- en DMARC-records zoals ze nu gepubliceerd zijn. Het snelst: run alle drie de lookups in MXToolbox SuperTool en kopieer de resultaten. Heb je SSH-toegang, dan geven dig TXT jouwsite.nl +short, dig TXT selector._domainkey.jouwsite.nl +short en dig TXT _dmarc.jouwsite.nl +short dezelfde data.
• Een recent DMARC aggregate report dat de falende bron en het alignment-resultaat toont.
• De volledige Authentication-Results-header van een falend bericht, gekopieerd uit de "Origineel weergeven"-view in Gmail.
• De naam, het pakket en het exacte verzenddomein dat je bij je verzendservice hebt geverifieerd.
• De naam en versie van je WordPress SMTP-plugin.
• Of de falende berichten transactioneel zijn (wp_mail() vanuit WordPress) of marketing (vanuit een apart platform zoals Mailchimp).

Met dat lijstje kan een support-engineer bij je verzendservice of een DNS-savvy collega het probleem meestal in minuten aanwijzen. Zonder dat lijstje krijg je een meerdaags heen-en-weer. Voor de bredere "WordPress verstuurt überhaupt geen mail"-situatie behandelt de laag-voor-laag-diagnose in waarom WordPress geen e-mail verstuurt de WordPress-, hosting- en DNS-laag samen, en dat is de juiste plek om te beginnen als je niet zeker weet welke laag stuk is.