DMARC-aggregaatrapporten gebruiken om verzendbronnen te onderzoeken
Lees DMARC-aggregaatrapporten als technische aanwijzingen voor verzendbronnen en domeinafstemming. Onderzoek afwijkingen voordat u beleid of DNS laat aanpassen.
.jpg){kind=link}
In dit artikel
DMARC-aggregaatrapporten bundelen technische waarnemingen over mail die uw domein als zichtbare afzender gebruikt. Ze kunnen helpen geautoriseerde en onbekende verzendbronnen onderzoeken. Lees ze als rapportages van ontvangende systemen, niet als een complete lijst van al uw mail of als bewijs dat ieder mislukt bericht misbruik is.
Begin met een inventaris van bekende verzenddiensten en vergelijk die met de gerapporteerde bronnen. Pas daarna beslist een bevoegde beheerder of een configuratie of beleid moet veranderen. Een onbekend IP-adres is een onderzoeksvraag, geen automatische toelating of blokkade.
Begrijp de velden die u vergelijkt
Een aggregaatrapport kan informatie bevatten over de rapporterende organisatie, periode, bron-IP, aantallen en authenticatiebeoordelingen. De precieze presentatie hangt af van de ontvanger en de rapportagetool die het bestand verwerkt.
DMARC in RFC 7489 beschrijft het mechanisme en de rapportagevormen. Het relevante onderscheid is dat DMARC beoordeelt of een geslaagde SPF- of DKIM-controle ook voldoende aansluit op het zichtbare From-domein.
Lees eerst SPF, DKIM en DMARC begrijpen als die domeinrollen nog onduidelijk zijn. Een technisch “pass” bij een onderliggend mechanisme en een geslaagde DMARC-uitkomst zijn niet zonder meer dezelfde conclusie.
Vergelijk rapportperiode en bronnen zorgvuldig
Rapporten kunnen later aankomen en verschillende periodes beslaan. Tel niet zonder controle dezelfde melding twee keer mee wanneer een bestand opnieuw wordt aangeleverd. Noteer welke periode en rapporteurs uw analyse omvat.
De rapporterende systemen vormen geen gegarandeerde volledige dekking van alle ontvangers. Een daling in gemelde aantallen kan door andere rapportage of een andere doelgroep komen. Trek daarom geen directe conclusie over bezorging of totale verzendvolumes.
Zet de uitkomsten in een marketingdashboard apart van campagnegedrag. Het rapport zegt iets over technische waarnemingen bij een deel van de ontvangende infrastructuur. Het toont niet hoeveel mensen de inhoud hebben gelezen of nuttig vonden.
Onderzoek een mislukking in meerdere stappen
Begin met de vraag of de bron bij een bekende dienst hoort. Controleer daarna welk domein voor SPF en welke DKIM-identiteit wordt gebruikt. Onderzoek of het probleem authenticatie, afstemming, doorsturen of een andere route betreft.
SPF in RFC 7208 beschrijft de controle van de relevante SMTP-identiteit. DKIM in RFC 6376 beschrijft domeinhandtekeningen. Die bronnen helpen begrijpen waarom een dienst een geslaagde eigen handtekening kan hebben zonder dat die voor uw zichtbare domein voldoende afstemt.
Voeg een onbekende bron niet voor de zekerheid toe aan DNS. Daarmee kunt u onbedoeld extra verzendrechten geven. Laat de concrete eigenaar en functie van de bron eerst vaststellen.
Een fictief rapportoverzicht voor drie systemen
De verzonnen Advieslijn Berken gebruikt zakelijke mail, facturatie en een nieuwsbriefdienst. In een fictieve rapportperiode worden duizend berichten gezien: zevenhonderd van de zakelijke route, tweehonderd van facturatie en honderd van de nieuwsbriefroute.
De eerste negenhonderd hebben in dit oefenvoorbeeld een geslaagde DMARC-uitkomst. De nieuwsbriefroute heeft een geldige DKIM-handtekening met een dienstendomein, maar geen passende afstemming met het zichtbare organisatiedomein. Het team onderzoekt daarom de domeinconfiguratie van die dienst.
De conclusie is niet “tien procent van alle mail is geweigerd”. De duizend zijn alleen de fictief gerapporteerde waarnemingen, en een DMARC-uitkomst is niet hetzelfde als de uiteindelijke bezorglocatie. Er is geen echte DNS- of afleveringscontrole uitgevoerd.
Prioriteer op functie en onzekerheid
Een onbekende bron die mogelijk facturen verstuurt verdient andere opvolging dan een duidelijk verlaten testomgeving. Noteer eigenaar, gewenste functie, waargenomen probleem en volgende onderzoekstap.
Maak drie werkstatussen: bekend en verklaard, bekend maar afwijkend, onbekend. “Verklaard” betekent niet automatisch veilig; het betekent alleen dat de herkomst en bedoeling voldoende zijn vastgesteld voor de volgende technische beoordeling.
Vraag bij een afwijking om een ontvangen testbericht uit de betreffende route. Vergelijk de concrete headers met de aggregaatwaarneming. Zo voorkomt u dat een algemene rapportgrafiek de enige basis voor een ingrijpende beleidswijziging wordt.
Controleer ook de eenheid van een grafiek. Sommige overzichten groeperen op bron, andere op domein of rapporteur. Een wijziging van groepering kan een trend anders laten lijken zonder dat het onderliggende verzendgedrag veranderde. Bewaar daarom de gebruikte selectie bij belangrijke conclusies.
Beperk toegang tot rapportagegegevens
Ook technische rapporten kunnen gegevens bevatten die niet overal thuishoren. Beoordeel wie ze ontvangt, waar ze worden opgeslagen en welke externe dienst ze verwerkt. Het gebruik van een rapportagetool vraagt een eigen beoordeling van contract en gegevensstroom.
Aggregaatrapporten zijn iets anders dan uitgebreide fout- of forensische rapportage. Zet aanvullende rapportage niet automatisch aan zonder te begrijpen welke berichtinformatie kan worden gedeeld. De bruikbaarheid en privacygevolgen verschillen.
Bewaar bevindingen zo dat een beheerder het onderzoek kan volgen zonder onnodig ruwe bestanden breed te verspreiden. Een geschoonde tabel met periode, broncategorie en actie kan voor een managementbespreking voldoende zijn.
Beschrijf bij een onderzoek welke alternatieve verklaring nog openstaat. Een onbekende bron kan bijvoorbeeld bij een vergeten legitieme dienst horen, maar die mogelijkheid is geen reden om haar meteen te autoriseren. Vraag de contracteigenaar of systeembeheerder om concreet bewijs van gebruik. Pas daarna volgt een wijzigingsvoorstel met de gevolgen voor bestaande mail.
Koppel conclusies aan gecontroleerde wijzigingen
Laat DNS- en beleidswijzigingen uitvoeren door iemand die alle geautoriseerde stromen overziet. Bewaar de eerdere configuratie en een herstelplan. Controleer na de wijziging opnieuw ontvangen berichten en passende volgende rapportperiodes.
Bij een mailmigratie kunnen oude en nieuwe bronnen tijdelijk tegelijk zichtbaar zijn. Dat hoeft niet onjuist te zijn, maar vraagt een duidelijke einddatum en gecontroleerde intrekking van oude rechten.
Gebruik meten zonder schijnzekerheid voor de rapporttaal. Schrijf welke bronnen en periodes zijn onderzocht en wat nog onbekend blijft. Een betere authenticatie-uitkomst is een technische verbetering, geen garantie op inboxplaatsing of commerciële resultaten.
Bronnen en grenzen
Advieslijn Berken en de aantallen zijn fictief. De specificaties zijn documentaire vertrekpunten; controleer bij uitvoering ook actuele standaarden en de concrete verzendroute.