GidsenAuthenticatie

DMARC faalt terwijl SPF en DKIM slagen

Beide controles zeggen pass, en DMARC zegt toch fail. De oorzaak is een domein dat niet overeenkomt met je From-adres. Eén testmail laat zien welk domein, en de oplossing is een instelling bij degene die de mail verstuurt.

Bijgewerkt op 5 oktober 20269 min leestijd

In het kort

DMARC slaagt alleen als SPF of DKIM slaagt voor het domein in je From-adres. Een pass voor het domein van je provider telt niet.
Open een verzonden bericht in Gmail met Show original en vergelijk smtp.mailfrom, header.i en header.from in de header Authentication-Results.
Los eerst DKIM op: zet ondertekening met je eigen domein aan bij elke dienst die namens jou verstuurt. Een DKIM-handtekening overleeft doorsturen, SPF niet.
Een subdomein is standaard dichtbij genoeg. Staat adkim=s of aspf=s in je DMARC-record, dan niet.
Warmup herstelt geen alignment. Warmup-mails worden via je mailbox verstuurd en falen mee.

DMARC vraagt niet of SPF en DKIM zijn geslaagd. Het vraagt of een van beide is geslaagd voor het domein in je From-adres. Is SPF geslaagd voor het bouncedomein van je provider en DKIM voor het ondertekeningsdomein van je provider, dan zeggen beide regels ‘pass’ en zegt DMARC toch ‘fail’. De oplossing ligt bij de afzender: laat die ondertekenen met jouw domein, of gebruik een bounceadres op jouw domein. Een van de twee is genoeg.

Het woord voor deze overeenkomst is alignment. Het is het deel van DMARC dat een DNS-checker niet kan zien. Of je mail alignment heeft, blijkt alleen uit een bericht dat echt is verstuurd. Deze pagina laat zien hoe je er een leest.

Met elke e-mail reizen drie domeinen mee

Een e-mail draagt je domein op maximaal drie plekken. Elke controle kijkt naar een andere.

Een marineblauwe wimpel met een envelop-embleem, een postzak met een koperen label en een brief met een lakzegel, naast elkaar op een kade; het zegel herhaalt het embleem van de wimpel, het label niet — De wimpel is de From-regel, het label aan de postzak is het Return-Path, het lakzegel is de DKIM-handtekening. DMARC wil dat het label of het zegel bij de wimpel past.

Waar	Ook wel genoemd	Wie ernaar kijkt
De From-regel die je lezer ziet	Header From, `header.from`	DMARC. Het is de maatstaf voor de andere twee.
Het Return-Path	Envelope sender, MAIL FROM, bounceadres, `smtp.mailfrom`	SPF. Het controleert of de verzendende server dit domein mag gebruiken.
De waarde `d=` in de header DKIM-Signature	Ondertekeningsdomein, `header.d` of `header.i`	DKIM. Het controleert of de handtekening van dit domein geldig is.

SPF (RFC 7208) en DKIM (RFC 6376) beantwoorden elk een smalle vraag, en in geen van beide vragen komt je From-regel voor. Een nieuwsbriefdienst kan voor zijn eigen bouncedomein door SPF komen en met zijn eigen sleutel ondertekenen, en het bericht kan toch beweren van jou te komen. DMARC dicht dat gat. RFC 9989, sinds mei 2026 de DMARC-standaard, accepteert een resultaat alleen als het domein erachter overeenkomt met het From-domein, en geeft de reden voor DKIM in één zin:

DMARC vereist dat Identifier Alignment wordt toegepast op de met DKIM geauthenticeerde identifier, omdat een bericht een geldige handtekening van elk willekeurig domein kan dragen, zelfs van een domein dat door een kwaadwillende wordt gebruikt.

Hetzelfde geldt voor SPF, want iedereen kan een SPF-record publiceren voor een domein dat van hem is. De regel is dus: DMARC slaagt als SPF slaagt en het domein overeenkomt, of als DKIM slaagt en het domein overeenkomt.

Vind de afwijking in één echt bericht

Je hebt één e-mail nodig die is verstuurd zoals je echte mail wordt verstuurd, en een Gmail-adres om hem te ontvangen.

Stuur vanuit de mailbox of tool in kwestie een bericht naar een Gmail-adres dat je kunt openen.
Open het in Gmail op een computer. Klik naast Reply (Beantwoorden) op More (Meer) en daarna op Show original (Origineel weergeven). Google beschrijft dezelfde stappen in Trace an email with its full header.
Zoek de header Authentication-Results, waarin de ontvangende server de uitkomst van zijn controles noteert (RFC 8601). Vergelijk drie waarden: het domein na smtp.mailfrom=, het domein na header.i=@ (sommige ontvangers schrijven header.d=) en het domein na header.from=. E-mailheaders lezen loopt die regel stap voor stap door.

Dit is het patroon van een bericht dat door SPF en DKIM komt en bij DMARC faalt. De header is ingekort en gebruikt voorbeelddomeinen:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Lees van onder naar boven. Het From-domein is example.com. SPF is geslaagd, maar voor send.vendor-mail.example. DKIM is geslaagd, maar de handtekening hoort bij vendor-mail.example. Geen van beide is example.com, dus niets staat in voor de naam in de From-regel.

Nadat de dienst is ingesteld om met jouw domein te ondertekenen, ziet hetzelfde bericht er zo uit:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF wijst nog steeds naar de leverancier. Dat is in orde. DKIM komt nu overeen, en één pass met alignment is alles wat DMARC nodig heeft.

Hoe dichtbij is dichtbij genoeg: relaxed en strict

De twee domeinen hoeven niet identiek te zijn. Standaard is alignment soepel (relaxed): het is genoeg dat beide bij hetzelfde geregistreerde domein horen, dat de standaard het organisatiedomein noemt. Strikte alignment (strict) eist een exacte overeenkomst. Je kiest met de tags adkim voor DKIM en aspf voor SPF in je DMARC-record.

SPF of DKIM geslaagd voor	From-domein	Relaxed (standaard)	Strict
`example.com`	`example.com`	Alignment	Alignment
`mail.example.com`	`example.com`	Alignment	Geen alignment
`example.com`	`news.example.com`	Alignment	Geen alignment
`vendor-mail.example`	`example.com`	Geen alignment	Geen alignment

De standaard merkt op dat ‘vrijwel alle domeineigenaren hebben ervaren dat soepele alignment in hun behoeften voorziet’. Controleer je eigen record toch. Het voorbeeldrecord bovenaan de pagina Set up DMARC van Google eindigt op adkim=s; aspf=s, dus een record dat daar is gekopieerd, is strikt. Heeft het jouwe die twee tags en verstuurt een tool vanaf een subdomein, verwijder ze dan. Google waarschuwt op die pagina zelf dat strikte alignment ‘ertoe kan leiden dat berichten van bijbehorende subdomeinen worden geweigerd of naar spam worden gestuurd’.

Waar de afwijking meestal vandaan komt

Een dienst die vanaf zijn eigen servers verstuurt

Nieuwsbriefplatforms, CRM’s, factuurtools en helpdesks versturen je mail vanaf hun infrastructuur. Totdat je je domein koppelt, gebruiken ze doorgaans een bounceadres op hun domein en ondertekenen ze met hun eigen sleutel. De documentatie van Amazon zegt ronduit waarom SPF-alignment hier zeldzaam is: het Return-Path ‘wordt gebruikt voor bounces en klachten die de provider (SES) bijhoudt met een adres dat van hem is’ (Amazon SES). De instelling die dit oplost, heeft bij elke dienst een andere naam en komt neer op een paar DNS-records aan jouw kant.

Dienst	Voordat je je domein koppelt	De instelling waarnaar je zoekt
Twilio SendGrid	Mail wordt getoond als verzonden ‘via sendgrid.net’.	Domain authentication: CNAME-records voor een bouncesubdomein en twee DKIM-sleutels.
Amazon SES	Het Return-Path is een subdomein van `amazonses.com`.	Easy DKIM voor de handtekening, en een custom MAIL FROM domain voor SPF.
Mailchimp	Het domein is geverifieerd maar niet geauthenticeerd.	Email domain authentication: twee CNAME-records voor DKIM.

Dit zijn de eigen beschrijvingen van de aanbieders, stand oktober 2026. Andere diensten werken op dezelfde manier. Zoek in hun help naar ‘authenticate domain’, ‘custom DKIM’ of ‘branded sending domain’.

Je e-mailprovider ondertekent met zijn eigen domein, of helemaal niet

Bij een mailbox op je eigen domein is het Return-Path normaal gesproken je eigen adres, dus SPF heeft alignment zodra je SPF-record de provider vermeldt. De waarde na smtp.mailfrom= laat het zien. DKIM is het deel waarvoor je iets moet aanzetten.

Google Workspace. Zolang je DKIM voor je domein niet hebt aangezet, heeft Google steeds ondertekend met een van zijn eigen domeinen. Een eerdere versie van de helppagina van Google zei dat Gmail dan ondertekent ‘met deze standaard-DKIM-domeinsleutel: d=*.gappssmtp.com’. De huidige pagina noemt het domein niet meer, dus controleer je eigen header: een header.i die eindigt op gappssmtp.com betekent dat je sleutel niet actief is. Genereer hem in de Admin console onder Apps, Google Workspace, Gmail, Authenticate email (e-mail verifiëren), voeg het TXT-record toe dat je daar ziet en klik daarna op Start authentication (verificatie starten) (Set up DKIM).
Microsoft 365. De documentatie van Microsoft, bijgewerkt in augustus 2026, zegt: ‘Momenteel wordt uitgaande mail van aangepaste domeinen niet met DKIM ondertekend’. Je publiceert twee CNAME-records en schakelt ondertekening in via de Defender-portal (How to use DKIM for email in your custom domain).

Het record dat je voor een DKIM-sleutel toevoegt, staat altijd onder _domainkey, onder een naam die de provider kiest. Voor Google Workspace ziet het er zo uit, met ingekorte sleutel:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Een tool die verbinding maakt met je mailbox en via die mailbox verstuurt, voegt geen eigen handtekening toe. Mail van zo’n tool ziet er precies zo uit als mail die je met de hand schrijft, dus de oplossing ligt bij de e-mailprovider en niet in de tool.

Het bericht is doorgestuurd

Stuurt een ontvanger je mail automatisch door, dan komt die aan vanaf een server die niet in je SPF-record staat. SPF faalt, of slaagt voor het domein van de doorstuurder. Een DKIM-handtekening overleeft de reis zolang niemand het bericht wijzigt. Mailinglijsten die een voettekst of een onderwerptag toevoegen, breken de handtekening ook. Dit kun je vanaf jouw kant niet repareren. De FAQ voor afzenders van Google zegt dat voor Gmail ‘DMARC-alignment niet vereist is voor doorgestuurde berichten of berichten van mailinglijsten’. Het is de reden om alignment voor DKIM te hebben en niet alleen op SPF te vertrouwen.

Een verzegelde brief gaat van de ene postboot naar de andere; elke boot heeft een eigen postzak met label, en het lakzegel op de brief is ongebroken — Doorsturen verwisselt de postzak en het label. Het zegel op de brief blijft heel.

Het is niet jouw mail

Tonen je DMARC-rapporten mislukkingen van servers die je nooit hebt gebruikt, dan verstuurt iemand mogelijk met jouw adres. Die berichten horen te falen. Er hoeft niets te worden gerepareerd, en ze zijn het argument voor een strenger beleid later.

Los eerst DKIM op, daarna SPF

Met elk van beide krijg je een pass. DKIM is de betere om te hebben, omdat het met het bericht meereist. De best practices van M3AAWG maken er een regel van: ‘Onderteken alle uitgaande mail met een DKIM-sleutel die overeenkomt met het domein van de RFC5322.From-header.’ RFC 9989 raadt aan beide te gebruiken.

Maak een lijst van alles wat als jouw domein verstuurt. Mailboxen, de nieuwsbrieftool, het CRM, facturen, het contactformulier op je website. Je DMARC-rapporten noemen wat je bent vergeten.
Test elk ervan met de headercontrole hierboven en noteer welk van de twee domeinen niet van jou is.
Zet ondertekening met jouw domein aan overal waar header.i een andere naam toont, en publiceer de records die de dienst je geeft. Kies een sleutel van 2048 bits als je DNS-host dat accepteert. Gmail eist ten minste 1024 bits en raadt 2048 aan.
Stel een eigen bouncedomein in waar de dienst dat aanbiedt, op een subdomein zoals bounce.example.com. Daarmee krijgt ook SPF alignment.
Verstuur de test opnieuw en zoek naar dmarc=pass. DNS-wijzigingen kunnen even duren. Google rekent tot 48 uur voordat een nieuwe DKIM-sleutel gaat werken.

Wat niet werkt, is de leverancier aan je eigen records toevoegen. Een include: voor de leverancier in je SPF-record verandert niets als het Return-Path op het domein van de leverancier staat, want SPF zoekt het record van dat domein op en niet het jouwe. Een DMARC-record kan ook geen vertrouwde derden opsommen. De standaard zegt dat daarvoor ‘geen algemeen aanvaard mechanisme’ bestaat.

Toont de header dmarc=pass en belandt het bericht toch in de spam, dan is authenticatie niet langer de oorzaak. SPF, DKIM en DMARC slagen, maar de e-mail belandt toch in de spam gaat daar verder.

Wat een falende DMARC kost zolang je beleid p=none is

Met p=none vraag je ontvangers om bij een mislukking niets te doen, dus door je beleid wordt niets geweigerd. Het telt toch op twee manieren tegen je.

Regels voor bulkafzenders. Gmail, Yahoo en Outlook.com eisen mail met alignment van bulkafzenders, wat voor Gmail en Outlook.com betekent: vanaf 5.000 berichten per dag. De FAQ voor afzenders van Google noemt de tijdelijke fout 4.7.32 voor mail waarvan de From-header ‘niet overeenkomt met het geauthenticeerde organisatiedomein van SPF of van DKIM’, en noemt als gevolg ‘tijdelijke of permanente foutcodes, of plaatsing in de spammap’.
Het blokkeert de volgende stap. Zodra je overstapt op p=quarantine of p=reject, moet elk eigen bericht zonder alignment als spam worden behandeld of geweigerd. Bij Gmail luidt de bounce ‘Unauthenticated email from domain-name is not accepted due to domain's DMARC policy’, fout 5.7.26 (Troubleshoot DMARC issues).

Heb je helemaal geen DMARC-record, begin dan met het record dat je toevoegt. Daarmee zet je ook de rapporten aan die de alignment van al je afzenders tegelijk laten zien.

Wat warmup hier wel en niet kan

Een warmup herstelt geen alignment. WarmupBay maakt verbinding met je mailbox en verstuurt daaruit, dus de warmup-mails worden door je provider verstuurd en ondertekend, precies zoals de mail die je zelf schrijft. Faalt je mailbox bij DMARC, dan falen ze mee. Repareer eerst de records.

WarmupBay helpt met het deel ervoor en het deel erna. Wanneer je een mailbox koppelt, controleert het SPF, DKIM en DMARC van het domein, en het stopt de warmup als ze na 72 uur nog steeds ontbreken. Staan ze er eenmaal, dan wisselt je mailbox een paar e-mails per dag uit met andere in een gedeelde pool, en het dashboard laat zien waar ze zijn beland: inbox, een Gmail-tabblad of spam, apart voor Google en voor andere providers. Het test geen mail van je nieuwsbrieftool of CRM, want die komt nooit door je mailbox, en het kan mailboxen van Microsoft 365 en Outlook.com nog niet koppelen. Het is gratis voor 10 warmup-mails per dag. Koppel je mailbox zodra de header dmarc=pass toont.

Veelgestelde vragen

SPF slaagt met alignment, DKIM heeft geen alignment. Is dat genoeg?

Voor DMARC wel. Eén pass met alignment is genoeg. Het is niet meer genoeg zodra een ontvanger je mail doorstuurt, want dan klopt SPF niet meer. Google schrijft in zijn FAQ voor afzenders ook dat alignment met zowel SPF als DKIM waarschijnlijk een eis wordt, dus stel DKIM voor je domein hoe dan ook in.

Waarom faalt DMARC bij sommige ontvangers en slaagt het bij andere?

Omdat de mail hen via verschillende routes of van verschillende afzenders bereikt. Een ontvanger die doorstuurt naar een andere mailbox, of een mailinglijst, verandert wat SPF en soms DKIM zien. Het kan ook één van meerdere verzenddiensten zijn die nog niet is ingesteld. Verzamelrapporten tonen de resultaten per verzendende server en laten zien welk geval het is.

Speelt het Reply-To-adres een rol bij DMARC?

Nee. DMARC gebruikt alleen het domein in de From-header. Het Reply-To-adres, de weergavenaam en de Sender-header maken geen deel uit van de controle.

Hoe zie ik alignmentproblemen zonder headers te openen?

In de verzamelrapporten van DMARC. Elk record heeft een blok policy_evaluated met een dkim- en een spf-resultaat; dat zijn de resultaten na de alignmenttoets. Het blok auth_results eronder toont de ruwe resultaten en de domeinen waarvoor ze golden. Een ruwe pass naast een beoordeelde fail is precies het geval op deze pagina. Je krijgt de rapporten door een rua-adres aan je DMARC-record toe te voegen.

In de header staat dkim=fail of dkim=neutral. Is dat hetzelfde probleem?

Nee. Dan is de handtekening zelf niet geverifieerd, en dat is een andere fout. Staat er body hash did not verify, dan noemt de pagina voor probleemoplossing van Google de oorzaak: het bericht is gewijzigd nadat het was ondertekend, bijvoorbeeld door een gateway die een voettekst toevoegt. Alignment gaat over een handtekening die geldig is maar bij een ander domein hoort.

Heb ik een aparte DKIM-sleutel nodig voor elke dienst die namens mij verstuurt?

In de praktijk wel. Elke dienst ondertekent met zijn eigen sleutel en publiceert die onder een eigen selectornaam onder _domainkey op jouw domein, dus meerdere sleutels staan zonder conflict naast elkaar. Dat is anders dan bij SPF, waar een domein maar één record mag hebben.