Lees je DMARC-rapporten

Heeft jouw domein een DMARC-record, dan sturen de grote mailproviders je dagelijks een rapport (een gecomprimeerd XML-bestand) met daarin elke server die mail namens jouw domein verstuurde. Het is de enige lijst die je ooit krijgt van alles wat als jou verstuurt — inclusief de delen van je eigen bedrijf die je was vergeten.

De tool wordt geladen…

Hoe het werkt

  1. Bewaar de rapportbijlagen uit de mailbox die je DMARC-record aanwijst (het rua=-adres), of sleep ze rechtstreeks uit het bericht.
  2. Sleep ze hier allemaal tegelijk naartoe — .xml, .xml.gz en .zip worden alle drie begrepen.
  3. Bekijk eerst de bronnen die falen: elk daarvan is óf iets van jezelf dat hersteld moet worden, óf iemand die je domein vervalst.

Waarom er niets wordt geüpload

Alles wat deze pagina doet, doet code die in je browsertabblad draait, met dezelfde engine die ook webpagina’s tekent. Je bestand wordt van schijf naar het geheugen van dat tabblad gelezen, daar bewerkt en weer weggeschreven als download. Het wordt nergens naartoe gestuurd — niet naar ons, en niet naar een derde partij.

Controleer het zelf

  1. Open de ontwikkelaarstools van je browser (F12) en kies het tabblad Netwerk.
  2. Laad je bestand en start de tool.
  3. De enige verzoeken die je ziet, halen de code van de tool zelf op — en bij een paar zware tools hun opensource-engine van een openbare CDN — plus één kleine bezoekmelding aan loreatec.jp (adres en titel van de pagina, meer niet). In geen van die verzoeken zit jouw bestand.

Bewijs dat het lokaal blijft →

Veelgestelde vragen

Waarom komen mijn rapporten binnen als .gz en .zip?

De standaard laat elke rapporterende organisatie zelf kiezen. Google stuurt .zip, Microsoft en de meeste andere sturen .xml.gz. Deze viewer opent alle drie in de browser — gzip via de eigen decompressie van de browser, zip via een meegeleverde opensourcebibliotheek.

Een bron toont SPF geslaagd maar DMARC mislukt. Hoe kan dat?

Dat noemt DMARC “alignment” (afstemming). SPF slaagt betekent dat een domein die server heeft geautoriseerd — maar het gecontroleerde domein is het verborgen retouradres, niet de From-regel die je ontvangers zien. DMARC vereist bovendien dat die twee overeenkomen. Een maildienst die met zijn eigen retouradres verstuurt, slaagt voor SPF voor zichzelf en mislukt op alignment voor jou. De oplossing is een eigen retouradres (return-path) instellen bij de dienst — of vertrouwen op DKIM dat met je eigen domein is ondertekend.

Wat moet ik doen voordat ik naar p=reject overstap?

Elke falende bron in deze tabel moet geïdentificeerd worden. Sommige zijn legitiem — een oude server, een CRM, een betaalprovider, een scanner. Elk daarvan heeft SPF of DKIM nodig die goed is ingesteld. Wat daarna overblijft, is vervalsing, en die afwijzen is precies het doel. Schakel je over naar reject terwijl er nog niet-geïdentificeerde bronnen in de lijst staan, dan gaat echte mail zonder waarschuwing verloren.

Verlaten deze bestanden mijn browser?

Nee. Ze worden hier gedecomprimeerd en verwerkt. Dat weegt bij DMARC-rapporten zwaarder dan gewoonlijk: ze bevatten de IP-adressen van alles wat namens jou verstuurt, wat een plattegrond van je infrastructuur is.

En forensische (ruf-)rapporten?

Dat zijn geen samenvattingen — elk daarvan is één mislukt bericht, aan jou gestuurd als gewone e-mail. Open er een met de .eml-viewer of de headeranalyse. De meeste grote ontvangers sturen ze om privacyredenen helemaal niet.