DMARC faalt maar SPF en DKIM slagen? De alignment-fix (2026)

Gepubliceerd 2026-07-08

Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.

DMARC heeft meer nodig dan een pass — het domein dat voor SPF of DKIM slaagde, moet overeenkomen met uw From-domein. De meeste “SPF pass, DMARC fail”-mail slaagde voor SPF op het bounce-domein van de leverancier, niet het uwe. Slechts 7,4% van de 261.086.232 beoordeelde domeinen slaagt voor SPF met alignment onder een handhavend DMARC-beleid, volgens de Defaults.Exposed-census (2026-06-29).

De oplossing is sneller dan de verwarring doet vermoeden. Lees de Authentication-Results-header om te zien welk been — SPF of DKIM — op het verkeerde domein slaagt; zet vervolgens óf de DKIM-ondertekening met eigen domein van uw verzendende dienst aan (meestal een paar CNAME’s, en de oplossing die doorsturen overleeft), óf stel het custom return-path in zodat SPF op uw domein slaagt. Eén aligned been is alles wat DMARC nodig heeft.

Hoe kan DMARC falen als SPF en DKIM allebei slagen?

Omdat DMARC nooit vraagt: “is SPF geslaagd?” Het vraagt: is SPF of DKIM geslaagd voor een domein dat overeenkomt met het From-adres dat uw ontvanger ziet? Die extra voorwaarde heet alignment, en het is precies waar DMARC om draait — zonder alignment zou iedereen voor SPF kunnen slagen op een domein dat hij zelf bezit, terwijl hij het uwe in de From-header toont.

Elke controle authenticeert een ander domein:

Controle	Domein dat werkelijk wordt geëvalueerd	Waar u het ziet
SPF	Het Return-Path (RFC5321.MailFrom, het bounce-/envelope-from-adres) — niet de From-header	`smtp.mailfrom=` in Authentication-Results
DKIM	Het domein in de `d=`-tag van de handtekening — wat de ondertekenaar ook koos	`header.d=` in Authentication-Results
DMARC	Uw From-header-domein — en het eist dat het domein van SPF of de `d=` van DKIM daarmee overeenkomt	`header.from=` in Authentication-Results

Zo gaan de stukjes meestal mis: uw nieuwsbriefplatform of CRM verzendt met een Return-Path als [email protected], SPF wordt gecontroleerd tegen vendor.com en slaagt, DKIM slaagt met d=vendor.com — en DMARC faalt, want geen van beide slagende domeinen komt overeen met yourcompany.com. Elke controle sprak de waarheid; geen van alle authenticeerde u. Uw eigen SPF-record aanpassen kan dit niet oplossen — het is nooit geraadpleegd. Het is dezelfde valkuil als in SPF faalt voor uw SaaS-tools.

De census toont hoe weinig afzenders deze laatste stap afmaken: 27.640.987 van de 261.086.232 beoordeelde domeinen (10,59%) hebben überhaupt een handhavend DMARC-beleid, en slechts 7,4% slaagt voor SPF met alignment onder zo’n beleid. Van de 77,5 miljoen domeinen waarvan het SPF-record eindigt op softfail (~all) valt maar 9,2% onder een handhavend DMARC-beleid; onder de hardfail-publiceerders (-all) worden er 12.142.351 gehandhaafd en 42.514.532 niet. De meeste domeinen stoppen bij “SPF slaagt” — wat, zonder DMARC dat erop handelt, vrijwel niets beschermt.

Hoe lees ik Authentication-Results om te zien welk been niet alignt?

Stuur uzelf een bericht via de falende dienst, open de ruwe bron en zoek de Authentication-Results-header. Een typisch niet-aligned resultaat ziet er zo uit:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Lees het als drie vergelijkingen:

SPF-been: eindigt smtp.mailfrom= op uw domein? Hier is het bounces.espmail.net — niet aligned.
DKIM-been: eindigt header.d= op uw domein? Hier is het espmail.net — niet aligned.
DMARC-oordeel: header.from= is het domein dat DMARC verdedigt. Geen van beide benen kwam ermee overeen, dus dmarc=fail — ook al zeggen beide afzonderlijke controles pass.

Het been waar uw eigen domein al bij betrokken is (of bij betrokken kan worden), is het been dat u repareert. U hebt er maar één nodig.

Wat is het verschil tussen relaxed en strict alignment?

DMARC kent twee vergelijkingsmodi, ingesteld met de tags aspf (SPF) en adkim (DKIM) in uw DMARC-record:

Relaxed (r, de standaard): de twee domeinen moeten hetzelfde organisatiedomein delen — het registreerbare domein volgens de Public Suffix List. bounce.yourcompany.com alignt met yourcompany.com; een DKIM met d=mail.yourcompany.com ook. Daarom werken custom return-paths en custom DKIM van leveranciers, die op subdomeinen leven.
Strict (s): de domeinen moeten exact overeenkomen, teken voor teken. bounce.yourcompany.com alignt dan niet meer met yourcompany.com.

Vermeldt uw record geen aspf of adkim, dan zit u in relaxed-modus — en daar wilt u vrijwel zeker blijven. Strikte modus voegt voor de meeste afzenders geen wezenlijke beveiliging toe en breekt geruisloos elke legitieme subdomein-afzender die u instelt. Faalt DMARC en bevat uw record aspf=s of adkim=s, dan kan dat op zichzelf al de bug zijn.

Hoe repareer ik DMARC-alignment?

Voer de gratis scan uit op defaults.exposed voordat u DNS aanraakt. Die toont uw DMARC-record en -beleid, of uw SPF en DKIM zo zijn ingesteld dat ze alignen, en wat er verder kapot is — zodat u eerst het juiste been repareert.
Test elke verzendende dienst en lees zijn Authentication-Results (zoals hierboven). Maak een lijst van elke bron — mailboxprovider, nieuwsbrieftool, CRM, factuurapp — en noteer per bron of smtp.mailfrom en header.d uw domein zijn of dat van de leverancier.
Zet DKIM-ondertekening met eigen domein aan bij elke leverancier — de oplossing die standhoudt. Elke serieuze verzendende dienst biedt “domeinauthenticatie”: een paar CNAME-records waarmee hij ondertekent als d=yourcompany.com (of een subdomein, dat in relaxed-modus alignt). Aligned DKIM is doorgaans de gemakkelijkere oplossing en de enige die doorsturen overleeft, want doorsturen breekt SPF by design.
Zet voor SPF-alignment het custom return-path van de leverancier aan (vaak “custom bounce domain” genoemd) — meestal één CNAME zoals bounce.yourcompany.com die naar de leverancier wijst. SPF slaagt dan op uw organisatiedomein en alignt. Doe dit waar het wordt aangeboden, maar beschouw het als het tweede been, niet als vervanging van aligned DKIM.
Laat alignment in relaxed-modus staan, tenzij u een specifieke, goed begrepen reden hebt voor aspf=s/adkim=s.
Scan opnieuw, bevestig beide benen en beweeg dan richting handhaving. Een DMARC-beleid van p=none rapporteert maar blokkeert niets; zodra uw echte afzenders alignen, staat het volledige pad naar een beleid dat u beschermt op de pagina DMARC repareren, en dekken provider-walkthroughs zoals DMARC op IONOS de klikpaden in het DNS-paneel.

Moet ik SPF-alignment of DKIM-alignment repareren?

U hebt één aligned been per verzendbron nodig. Kunt u er maar één doen, dan is de keuze niet spannend:

Oplossing	Wat het inhoudt	Overleeft doorsturen?
Aligned DKIM (ondertekening met eigen domein)	Een paar CNAME’s in het “domeinauthenticatie”-paneel van de leverancier	Ja — de handtekening reist met het bericht mee
Aligned SPF (custom return-path/bounce-domein)	Eén CNAME, waar de leverancier het aanbiedt	Nee — het IP van elke doorstuurder vervangt dat van de leverancier

Het speciale geval dat u moet kennen: Google Workspace en Microsoft 365 ondertekenen uw mail standaard met DKIM op hun eigen fallback-domeinen (gappssmtp.com, onmicrosoft.com) — DKIM toont dus pass terwijl DMARC alsnog faalt. Het is verreweg de meest voorkomende concrete variant van dit hele probleem, en heeft een eigen gids: DKIM slaagt maar DMARC faalt alsnog: de standaardhandtekening-valkuil.

Veelgestelde vragen

Moeten SPF én DKIM allebei alignen om DMARC te laten slagen? Nee — één aligned pass is voldoende. Best practice is toch beide te alignen, zodat wanneer doorsturen het SPF-been breekt, het DKIM-been de DMARC-pass blijft dragen. Van de 261.086.232 domeinen die in de census van 2026-06-29 zijn beoordeeld, maakt slechts 3,87% de volledige triade SPF + DMARC + DKIM compleet.

Mijn ESP-dashboard zegt dat SPF en DKIM “verified” zijn — waarom faalt DMARC dan nog? “Verified” betekent meestal dat de eigen verzending van de leverancier slaagt op de domeinen van de leverancier. Tenzij u hun stappen voor een eigen domein hebt afgerond (DKIM-CNAME’s, custom return-path), authenticeert de mail zich als de leverancier, niet als u — en DMARC vergelijkt met uw From-domein.

Is een strikt -all-SPF-record genoeg zonder alignment? Nee. Een strikte qualifier verscherpt het SPF-oordeel over het Return-Path-domein, maar DMARC heeft nog steeds nodig dat dat domein het uwe is. Per de census van 2026-06-29 vallen slechts 12.142.351 van de domeinen die -all publiceren onder een handhavend DMARC-beleid — de overige 42.514.532 hebben een strikt record waar geen beleid op handelt.

Moet ik overstappen op strikte alignment (aspf=s/adkim=s) voor meer beveiliging? Vrijwel nooit. Relaxed alignment vereist al hetzelfde registreerbare domein, en daar heeft een spoofer geen controle over. Strikte modus breekt vooral uw eigen subdomein-afzenders — controleer erop wanneer alignment onverwacht faalt.

DMARC faalt alleen op mail die ontvangers doorsturen — zelfde oplossing? Dat is het SPF-been dat onderweg sneuvelt: de server van de doorstuurder staat in niemands SPF-record voor uw return-path. U kunt SPF voor doorgestuurde mail niet repareren; aligned DKIM is het antwoord, want de handtekening overleeft doorsturen intact. Details in doorgestuurde e-mail faalt op SPF.

Stuur de eigenaar het rapport

Repareert u dit voor een klant of uw werkgever, sluit dan de cirkel met bewijs. Voer de gratis scan opnieuw uit zodra de CNAME’s zijn doorgevoerd en stuur het beoordeelde rapport door naar de bedrijfseigenaar: gedateerd, in gewone taal, en het laat zien dat SPF, DKIM en DMARC alignen en slagen. Dat is het bewijsstuk dat hij nodig heeft voor de cyberverzekeringsverlenging en de volgende beveiligingsvragenlijst van leveranciers — bewijs van een werkende configuratie, niet alleen “ik heb wat DNS-records toegevoegd”.

Controleer uw domein → · DKIM slaagt maar DMARC faalt alsnog → · Repareer DMARC → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.