DMARC-rapport lezen

Uw rapport bekijken

Waarom wij dit gebouwd hebben

Niet als marketingcadeau. Wij lezen deze rapporten zelf, elke dag, voor onze eigen domeinnamen. Deliverability en misbruik beoordelen is een doorlopend onderdeel van ons werk als hostingpartij, en DMARC-rapportage is daarvan het belangrijkste instrument: het is de enige plek waar u ziet wat ontvangende partijen werkelijk met uw post doen, in plaats van wat u denkt te hebben ingesteld.

Deze lezer is het gereedschap dat wij daarvoor gebruiken, in een vorm die u ook kunt gebruiken. Dat wij het bouwden zegt dus iets over onze infrastructuur: wij weten wat er vanaf onze netwerken verstuurd wordt en of dat uitlijnt, omdat wij ernaar kijken.

Dat vak zit ook in de rest van wat wij doen — zie domeinbescherming voor e-mail voor het stappenplan, en soevereine hosting voor waar uw post staat en wie eraan kan.

Wat u in een DMARC-rapport ziet

Een DMARC-aggregaatrapport is een XML-bestand dat als bijlage binnenkomt op het adres in het rua=-veld van uw DMARC-record, meestal ingepakt als .zip of .gz. Eén rapport beslaat één dag, gezien door één ontvangende partij. Google stuurt er dus één, Microsoft stuurt er één, en elke kleinere mailserver die rapporteert stuurt er ook één — allemaal over dezelfde dag, allemaal met een eigen deel van het verkeer, en soms met overlap.

U krijgt er daardoor veel, van verschillende partijen, en geen enkel rapport is op zichzelf het complete beeld. Hoe die rapportage werkt en hoe u een onbekend IP-adres naloopt, staat in het artikel DMARC-rapporten lezen. Deze pagina gaat over de volgende stap: u heeft zo'n bestand in handen en wilt weten wat er aan de hand is.

De velden die er echt in staan

Per verzendend IP-adres bevat het rapport een record met de volgende velden. Dit is ook wat de lezer hierboven uit uw bestand haalt:

Waarom SPF kan slagen terwijl DMARC faalt

Dit is de verwarring waar vrijwel iedereen op vastloopt, en de reden dat het rapport twee resultaten per controle bevat. auth_results is het ruwe resultaat: slaagde de controle, voor welk domein dan ook. policy_evaluated is het DMARC-resultaat, en dat eist bovendien dat het gecontroleerde domein uitlijnt met header_from — het domein dat uw ontvanger daadwerkelijk ziet. Een pass op het verkeerde domein telt voor DMARC niet.

Dit voorbeeld komt geanonimiseerd uit een echt rapport:

policy_published: adkim=r  aspf=s
header_from:      voorbeeld.nl
SPF ruw:          mailer.voorbeeld.nl -> pass
DMARC-SPF:        fail        (strikt: mailer.voorbeeld.nl is niet voorbeeld.nl)
DKIM ruw:         voorbeeld.nl -> pass
DMARC-DKIM:       pass
disposition:      none        (een van de twee is genoeg)

Wat hier gebeurt: aspf=s betekent strikte uitlijning, en dan telt een subdomein niet — mailer.voorbeeld.nl is niet letterlijk voorbeeld.nl, dus de geslaagde SPF-controle levert voor DMARC een fail op. Met aspf=r (relaxed) zou hetzelfde bericht wél uitlijnen, omdat beide namen onder hetzelfde organisatiedomein vallen.

Het bericht komt hier toch goed door, omdat DKIM wél uitlijnt en één van de twee genoeg is. Maar let op wat dat betekent: dit domein leunt volledig op DKIM. Breekt de DKIM-ondertekening — een verlopen sleutel, een verhuizing, een vergeten selector — dan valt alles in één keer om. In de steekproef van echte rapporten waarop wij deze lezer bouwden, had 7 van de 27 records precies deze vorm. Dit is geen randgeval.

Verkeerd ingesteld of echt misbruik?

Dit is de vraag die u werkelijk heeft als er fails in het rapport staan. Een sluitend antwoord geeft één rapport niet, maar de patronen verschillen duidelijk:

De linkerkolom is een systeem van uzelf of van een leverancier dat nog niet goed staat — een nieuwsbriefdienst, een boekhoudpakket, een ticketsysteem. Dat lost u op met configuratie. De rechterkolom is iemand anders die uw domeinnaam gebruikt; daar is uw DMARC-beleid het antwoord op.

Doorsturen ziet eruit als een fout, maar is het niet

Stuurt iemand een bericht van u door — een oud adres dat doorverwijst, een collega die forwardt — dan komt het bij de eindontvanger aan vanaf het IP-adres van de doorsturende server. SPF faalt dan per definitie: dat IP staat niet in uw record. DKIM breekt daarbij niet, want de ondertekening zit in het bericht zelf en reist mee.

Zo herkent u het in het rapport: DMARC-DKIM slaagt, DMARC-SPF faalt, de aantallen zijn laag en de IP-adressen zijn talrijk en steeds anders. Dat patroon is geen probleem en geen misbruik; het is de reden dat u naast SPF ook DKIM nodig heeft.

Eén uitzondering verdient het benoemen: mailinglijsten die een voettekst of een label aan het onderwerp toevoegen, wijzigen daarmee het bericht — en breken daardoor juist wél de DKIM-handtekening.

Wat u met pct moet doen

De pct-tag ("pas dit beleid toe op een percentage van de berichten") is in RFC 9989 (mei 2026) niet gedeprecieerd maar verwijderd. De motivatie: tussenwaarden werden bij elke ontvanger anders toegepast, alleen 0 en 100 deden betrouwbaar wat ze beloofden. De vervanger is de t-tag: p=reject; t=y past het beleid één niveau lager toe, dus feitelijk quarantine.

Daar zit een concreet risico in. Een ontvanger die RFC 9989 volgt, negeert onbekende tags — en dus ook een bestaande pct=25. Bij die ontvanger gedraagt uw record zich dan als volledige handhaving. Wie nu een geleidelijke uitrol doet met pct onder de 100, krijgt naarmate ontvangers migreren stilzwijgend strengere handhaving dan bedoeld.

Staat er pct onder de 100 in uw record, rond de uitrol dan af of stap over op t=y. Het stappenplan voor een veilige uitrol staat op Domeinbescherming voor e-mail.

Waar uw rapport blijft

Het rapport wordt in uw browser uitgepakt en gelezen. Er gaat geen bestand naar onze servers, en u kunt dat controleren in het netwerktabblad van uw browser.

Dat is geen detail. Een DMARC-rapport bevat IP-adressen van verzendende servers en soms een e-mailadres in de metadata. Wie zo'n bestand naar een server uploadt, laat een derde partij die gegevens verwerken — ook als die partij er verder niets mee doet.

Voor de volledigheid: uw browser haalt deze pagina en het script bij ons op, dus ons webserverlog bevat uw IP-adres, zoals bij elk websitebezoek.

Veelgestelde vragen