E-mailauthenticatie in 2026: zo stel je SPF, DKIM en DMARC in (voordat je mail niet meer aankomt)

Je e-mail werkt prima. Tot het op een dag niet meer zo is.

Dat overkwam duizenden domeineigenaren in 2025 toen Microsoft e-mailauthenticatie ging afdwingen voor Outlook.com, Hotmail.com en Live.com. Afzenders zonder geldige SPF-, DKIM- en DMARC-records kregen ineens een 550 5.7.515-foutmelding terug: "je domein bewijst niet dat het deze e-mail mag versturen." Google en Yahoo hadden hun regels al in februari 2024 aangescherpt. De boodschap is helder: e-mail zonder authenticatie heeft een houdbaarheidsdatum.

Het goede nieuws: e-mailauthenticatie instellen is niet ingewikkeld. Drie DNS-records, even wachten op propagatie, klaar. In dit artikel loop ik je er doorheen: begrijpelijk genoeg als je een site beheert, gedetailleerd genoeg als je klantdomeinen configureert.

Wat je leert:

• Wat SPF, DKIM en DMARC doen en waarom je alle drie nodig hebt
• Welke providers authenticatie afdwingen en wat er misgaat als je het niet regelt
• Stapsgewijs DNS instellen per protocol
• WordPress-specifieke valkuilen (en hoe je die oplost)
• Hoe je je configuratie test en verifieert

Inhoudsopgave

• Waarom e-mailauthenticatie nu belangrijk is
• De drie protocollen: SPF, DKIM en DMARC
• SPF instellen
• DKIM instellen
• DMARC instellen
• WordPress-sites: een veelvoorkomend probleem
• Je configuratie testen
• Veelgemaakte fouten
• Wanneer authenticatie alleen niet genoeg is

Waarom e-mailauthenticatie nu belangrijk is

Er is de afgelopen twee jaar veel veranderd.

Google kondigde in februari 2024 strenge afzendervereisten aan en schakelde in november 2025 over naar harde SMTP-weigering. Stuur je meer dan 5.000 berichten per dag naar Gmail-adressen, dan heb je geldige SPF-, DKIM- en een DMARC-record nodig. Kleinere afzenders moeten minimaal SPF of DKIM op orde hebben. Niet-conforme mail krijgt nu een harde bounce; het bereikt geen enkele map meer.

Microsoft volgde in mei 2025. In hun aankondiging op de Microsoft Defender-blog staat het zwart op wit: domeinen die meer dan 5.000 e-mails per dag versturen naar Outlook.com, Hotmail.com en Live.com moeten SPF, DKIM en DMARC hebben. Ontbreekt er iets? Dan krijgt de ontvanger niets; je mail kaatst terug met foutcode 550 5.7.515.

Yahoo sloot aan bij Google en stelt dezelfde eisen voor bulk-afzenders via Yahoo Mail en AOL.

Die 5.000 berichten per dag klinkt veel, maar het loopt sneller op dan je denkt. WooCommerce-orderbevestigingen, nieuwsbrieven, wachtwoordresets: het telt allemaal mee. En die drempel geldt alleen voor de strengste regels. Ook bij lagere volumes helpt authenticatie, want ontbrekende SPF/DKIM is een van de sterkste spamsignalen bij álle providers.

De drie protocollen: SPF, DKIM en DMARC

Denk aan e-mailauthenticatie als drie lagen bewijs dat een e-mail echt afkomstig is van wie de afzender claimt te zijn.

SPF (Sender Policy Framework) laat je vastleggen welke mailservers namens jouw domein mogen versturen. Het is een DNS TXT-record met een lijst van goedgekeurde IP-adressen en diensten. Ontvangt een mailserver een bericht van jouw domein? Dan controleert die of de verzendende server op de SPF-lijst staat.

DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan elk uitgaand bericht. De verzendende server ondertekent de e-mail met een privésleutel; de ontvangende server verifieert die handtekening met een publieke sleutel in je DNS. Klopt de handtekening, dan is het bericht onderweg niet aangepast.

DMARC (Domain-based Message Authentication, Reporting and Conformance) koppelt SPF en DKIM aan elkaar. Het vertelt ontvangende servers wat ze moeten doen bij een mislukte authenticatie: niets (none), het bericht in quarantaine plaatsen, of weigeren. DMARC controleert ook alignment, wat betekent dat het domein in de From-header moet overeenkomen met het domein dat SPF of DKIM heeft doorstaan.

Je hebt alle drie nodig. SPF alleen is te manipuleren via header-spoofing. DKIM alleen vertelt ontvangers niet wat ze moeten doen bij fouten. DMARC zonder SPF of DKIM heeft niets om op af te stemmen.

SPF instellen

SPF is een enkel DNS TXT-record op je hoofddomein. Het begint met v=spf1, somt je geautoriseerde afzenders op en eindigt met een all-mechanisme.

Een basis SPF-record voor een domein met Google Workspace:

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

Voor Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Gebruik je daarnaast een transactionele e-maildienst (Mailgun, SendGrid, Postmark)? Voeg hun include toe:

v=spf1 include:_spf.google.com include:_netblocks.mailgun.org ~all

De ~all aan het eind is een soft fail: het vertelt ontvangers "alles wat niet op deze lijst staat is verdacht, maar weiger het niet meteen." Als je zeker weet dat je setup klopt, kun je overschakelen naar -all (hard fail).

De 10-lookup-limiet

SPF heeft een harde grens: maximaal 10 DNS-lookups per evaluatie. Elke include, a, mx en redirect telt als één lookup, en geneste includes tellen ook mee. Ga je over de 10? Dan faalt de hele SPF-controle met een permerror.

In de praktijk loop je hier tegenaan als je meerdere diensten combineert. Google Workspace alleen verbruikt al 3-4 lookups achter zijn include. Voeg daar Microsoft 365, een marketingplatform en een transactionele dienst aan toe en je zit over de limiet.

Hoe je eronder blijft:

• Gebruik ip4 en ip6 waar mogelijk, want die tellen niet mee voor de lookup-limiet
• Verwijder diensten die je niet meer gebruikt
• Overweeg een SPF-flattening dienst als je echt veel providers nodig hebt (tools als autospf.com automatiseren dit)

Belangrijk: één SPF-record per domein

Je domein mag maar één SPF TXT-record hebben. Meerdere SPF-records zorgen ervoor dat beide falen. Voeg je een nieuwe dienst toe? Combineer dan de include in je bestaande record in plaats van een tweede record aan te maken.

DKIM instellen

DKIM vereist twee dingen: je e-mailprovider genereert een sleutelpaar, en jij publiceert de publieke sleutel in DNS.

Het DNS-record is een TXT-record op selector._domainkey.jouwdomein.nl. De selector is een label dat je e-mailprovider kiest; het identificeert welk sleutelpaar wordt gebruikt.

Google Workspace

In de Google Workspace Admin Console ga je naar Apps → Google Workspace → Gmail → E-mail verifiëren. Je krijgt een TXT-record dat je toevoegt aan je DNS. De standaardselector is google, dus het record komt op:

google._domainkey.jouwdomein.nl

De DKIM-documentatie van Google beschrijft elke stap. Kies een 2048-bit sleutel, want dat is de huidige aanbeveling en Google gebruikt het als standaard.

Microsoft 365

Microsoft gebruikt CNAME-records in plaats van TXT-records. Je maakt twee CNAME-entries die verwijzen naar Microsofts DKIM-infrastructuur. Het formaat volgt de Microsoft DKIM-configuratiegids:

selector1._domainkey.jouwdomein.nl → selector1-jouwdomein-nl._domainkey.jouwdomein.onmicrosoft.com
selector2._domainkey.jouwdomein.nl → selector2-jouwdomein-nl._domainkey.jouwdomein.onmicrosoft.com

Na het toevoegen van beide CNAMEs schakel je DKIM-ondertekening in via het Microsoft 365 Defender-portaal. Laat beide selectors in DNS staan, want Microsoft wisselt er automatisch tussen.

Transactionele e-maildiensten

Mailgun, SendGrid, Postmark en Amazon SES geven je allemaal DKIM-records tijdens de domeinverificatie. Het proces is steeds hetzelfde: voeg de DNS-records toe die ze je geven, verifieer in hun dashboard, klaar. Volg de documentatie van je specifieke provider in plaats van te gokken op de syntax.

Sleutelgrootte: minimaal 2048-bit

Gebruik 2048-bit sleutels. De oudere 1024-bit sleutels worden als zwak beschouwd en sommige beveiligingsscanners markeren ze. De meeste providers gebruiken inmiddels 2048-bit als standaard. Ondersteunt je DNS-provider geen TXT-records langer dan 255 tekens? Dan moet je de sleutel over meerdere strings splitsen, maar dat komt bij moderne DNS-hosts zelden voor.

DMARC instellen

DMARC is een TXT-record op _dmarc.jouwdomein.nl. Een startconfiguratie:

v=DMARC1; p=none; rua=mailto:dmarc-reports@jouwdomein.nl

Het p=none-beleid vertelt ontvangers: stuur me rapporten, maar doe verder niets met falende e-mails. Hier begin je. Altijd.

Het uitrolpad

Meteen naar p=reject gaan zonder data is hoe je je eigen legitieme e-mail blokkeert. De aanbevolen aanpak:

1. p=none: monitor 2-4 weken. Lees de rapporten om alle diensten te identificeren die e-mail namens jouw domein versturen.
2. p=quarantine: falende e-mails gaan naar spam. Houd je bezorgpercentages nog 2-4 weken in de gaten.
3. p=reject: falende e-mails worden geblokkeerd. Dit is het einddoel en de sterkste bescherming tegen spoofing.

DMARC-rapporten begrijpen

De rua-tag bepaalt waar aggregaatrapportages naartoe worden gestuurd: XML-bestanden die vertellen welke IP-adressen e-mail stuurden namens jouw domein en of SPF/DKIM slaagde. Ruwe XML is niet prettig lezen. Gratis tools die het omzetten naar iets bruikbaars:

• Postmarks DMARC-monitoring: gratis wekelijkse samenvattingen, overzichtelijk dashboard
• Google Postmaster Tools: bezorgstatistieken specifiek voor Gmail
• MXToolbox DMARC Report Analyzer: upload en analyseer losse rapporten

De ruf-tag stuurt forensische (per-bericht) foutrapporten. De meeste grote providers sturen die niet meer vanwege privacy, dus rua is in de praktijk de enige die ertoe doet.

DMARC-alignment

Hier wordt het even technisch. DMARC vereist alignment: het domein in de zichtbare From-header moet overeenkomen met het domein dat SPF of DKIM heeft doorstaan. Als je contactformulier e-mail verstuurt met een From-adres op jouwdomein.nl, maar de daadwerkelijke verzendserver zich authenticeert als mailgun.org, dan redt DKIM-alignment je, omdat Mailgun ondertekent met de DKIM-sleutel van jouw domein. Zonder DKIM slaagt de alignment niet, ook al passeert SPF wel.

Daarom heb je beide nodig, niet maar één.

WordPress-sites: een veelvoorkomend probleem

WordPress heeft een specifiek probleem met e-mailauthenticatie. Standaard gebruikt wp_mail() PHP's ingebouwde mail()-functie, die e-mail rechtstreeks vanaf de webserver stuurt. Het From-adres zegt misschien wordpress@jouwdomein.nl, maar het bericht komt van het IP van je hostingserver, dat waarschijnlijk niet in je SPF-record staat. Een DKIM-handtekening ontbreekt ook.

Het resultaat: je contactformulier-bevestigingen, WooCommerce-orderemails en wachtwoordresets zakken door de authenticatiecontrole. Ze belanden in spam of worden geweigerd. Als je wel eens te maken hebt gehad met WordPress die geen e-mail verstuurt, is ontbrekende authenticatie vaak de onderliggende oorzaak. Dit is trouwens een bekend probleem in WordPress core sinds 2012, en het is op platformniveau nog steeds niet opgelost.

De oplossing: WordPress e-mail via SMTP routeren

Een SMTP-plugin verbindt WordPress met een echte e-maildienst die authenticatie voor je regelt. De belangrijkste opties:

• WP Mail SMTP: de populairste keuze. Ondersteunt Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, Amazon SES en generiek SMTP.
• FluentSMTP: gratis, lichtgewicht, ondersteunt dezelfde providers. Goed als je de extra functies van WP Mail SMTP Pro niet nodig hebt.
• Post SMTP: inclusief e-maillogging en foutmeldingen.

Configureer de plugin om te versturen via de e-maildienst waarvoor je SPF en DKIM hebt ingesteld. De e-mails slagen dan voor authenticatie omdat ze via een geautoriseerde server gaan met DKIM-ondertekening, niet via PHP's mail().

Je configuratie testen

Ga er niet vanuit dat het werkt. Controleer het.

MXToolbox: voer je domein in en controleer SPF-, DKIM- en DMARC-records afzonderlijk. Toont syntaxfouten, lookup-aantallen en waarschuwingen.

Google Admin Toolbox Check MX: controleert DNS-configuratie op veelvoorkomende fouten. Vooral handig voor Google Workspace-setups.

mail-tester.com: stuur een test-e-mail naar een gegenereerd adres en krijg een gedetailleerde score. Controleert SPF, DKIM, DMARC, spaminhoud en blacklists in één keer. De meest praktische "doet mijn e-mail het?" test.

Stuur na het instellen een testmail naar een Gmail-adres en bekijk de headers. In Gmail klik je op de drie puntjes → "Origineel weergeven." Je zou spf=pass, dkim=pass en dmarc=pass moeten zien. Staat er ergens fail? Ga dan terug naar de setup van dat specifieke protocol.

Veelgemaakte fouten

Meerdere SPF-records. Een tweede TXT-record toevoegen dat begint met v=spf1 in plaats van samen te voegen met het bestaande record. Beide worden dan ongeldig.

De transactionele afzender vergeten. Je stelt SPF in voor Google Workspace, maar je WordPress-site verstuurt via SendGrid. De servers van SendGrid staan niet in je SPF-record. Resultaat: SPF faalt voor elke geautomatiseerde e-mail.

DMARC meteen op p=reject zetten. Je mist een legitieme verzendbron (een CRM, een facturatiesysteem, een oud marketingtool) en die e-mail stopt met aankomen. Begin altijd met p=none.

Verouderde DNS-records. Je bent een half jaar geleden overgestapt van Mailgun naar Postmark, maar het oude DKIM-record staat nog in DNS. Het veroorzaakt geen fouten, maar het maakt je zone rommelig en verwarrend voor iedereen die het later bekijkt.

SPF-lookup-limiet overschreden. Je stapelt vijf diensten met include-mechanismen en vraagt je af waarom SPF-evaluatie permerror retourneert. Controleer je lookup-aantal met MXToolbox voordat je nieuwe diensten toevoegt.

Cloudflare-proxy op e-mailrecords. Gebruik je Cloudflare? Dan moeten alle e-mailgerelateerde TXT- en CNAME-records op "DNS only" staan (het grijze wolkicoon). Een geproxied DKIM CNAME-record breekt de validatie, omdat ontvangende servers de publieke sleutel niet via Cloudflare's proxy kunnen ophalen.

Wanneer authenticatie alleen niet genoeg is

SPF, DKIM en DMARC bewijzen dat een e-mail geautoriseerd en ongewijzigd is. Ze garanderen geen bezorging. Een correct geauthenticeerde e-mail kan nog steeds in spam belanden als de inhoud filters triggert, als het verzendende IP een slechte reputatie heeft, of als de server van de ontvanger aanvullende regels heeft.

Voor WordPress-sites die een handjevol transactionele e-mails per dag versturen (orderbevestigingen, contactformulier-notificaties, wachtwoordresets), is authenticatie meestal de grootste verbetering die je kunt doorvoeren. Maar als je op volume verstuurt (nieuwsbrieven, marketingcampagnes), moet je ook je afzenderreputatie monitoren via Google Postmaster Tools en best practices volgen: schone lijsten, consistent verzendpatroon, goede afmeldmogelijkheden.

E-mailauthenticatie is de basis, niet het plafond. Maar zonder die basis maakt de rest niet uit, want je e-mail komt gewoon niet aan.

Samenvatting:

• SPF, DKIM en DMARC zijn nu verplicht voor betrouwbare bezorging bij Gmail, Outlook en Yahoo
• WordPress-sites hebben een SMTP-plugin nodig om geauthenticeerde e-mail te versturen; wp_mail() alleen is niet genoeg
• Begin DMARC op p=none, monitor de rapporten, verscherp geleidelijk
• Eén SPF-record per domein, let op de 10-lookup-limiet
• Test met MXToolbox en mail-tester.com na elke wijziging