Breng eerst in kaart welke systemen legitieme mail versturen met jouw domein, voordat je je DMARC-beleid aanscherpt. Rapporten kunnen een afzender aan het licht brengen die authenticatiewijzigingen nodig heeft voordat handhaving de mail zou blokkeren.
Welk rapport gebruik je?
Gebruik aggregatierapporten om verzendbronnen en authenticatieresultaten over een rapportageperiode te vergelijken. Het rua-adres in je DMARC-record vraagt deze XML-samenvattingen op bij deelnemende ontvangers.
Het ruf-adres vraagt individuele foutrapporten op, ook wel forensische rapporten genoemd. Ze gebruiken een authenticatie-foutrapportageformaat en kunnen headers of berichtinhoud bevatten. Ontvangers kunnen ze redigeren of weglaten, omdat de inhoud persoonlijke informatie kan blootstellen. De rapportageregels van RFC 7489 beschrijven de twee rapporttypen.
Aggregatierapporten dekken het verkeer dat elke rapporterende ontvanger heeft waargenomen. Een ontbrekend rapport bewijst niet dat er geen berichten met jouw domein zijn verzonden. De uitleg over het DMARC-record behandelt waar je de rapportageadressen instelt.
Wat bevat een aggregatierapport?
Een aggregatierapport vermeldt de rapporterende organisatie, de rapportageperiode en het gepubliceerde beleid, gevolgd door records die berichten met gedeelde kenmerken groeperen. Een bron-IP kan in meerdere records voorkomen wanneer de authenticatieresultaten of andere groeperingsvelden verschillen.
Dit illustratieve fragment bevat de velden die nodig zijn om een bron met zijn authenticatieresultaten te vergelijken:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>Dit record vertegenwoordigt 42 berichten van 203.0.113.10 met example.com in het zichtbare From-adres. Beide authenticatiemethoden zijn geslaagd en uitgelijnd. De ontvanger heeft geen DMARC-handhaving op die berichten toegepast; dit zegt niets over de inboxplaatsing.
Welke velden wijzen op een authenticatieprobleem?
Vergelijk policy_evaluated met auth_results om een authenticatiefout te onderscheiden van een domeinuitlijningsfout.
| Veld | Wat je controleert |
|---|---|
source_ip | Identificeer de verzendende server en de verantwoordelijke dienst. |
count | Tel de berichten die dit record vertegenwoordigt, niet het hele rapport. |
header_from | Bevestig het domein dat aan de ontvanger wordt getoond. |
disposition | Controleer of de ontvanger none, quarantine of reject heeft toegepast. |
dkim en spf in policy_evaluated | Controleer of elke methode is geslaagd en uitgelijnd voor DMARC. |
auth_results | Vergelijk de ruwe authenticatieresultaten en de domeinen die ze hebben geauthenticeerd. |
SPF kan bijvoorbeeld slagen onder auth_results maar falen onder policy_evaluated wanneer het geauthenticeerde domein niet is uitgelijnd met het From-domein. Een uitgelijnde DKIM-pass kan dat bericht alsnog laten slagen voor DMARC. Hoe DMARC werkt legt die relatie uit.
Wat doe je met elke verzendbron?
Koppel elke bron aan een dienst die je autoriseert voordat je het beleid wijzigt. Authenticatieresultaten alleen vertellen je niet of je organisatie de bedoeling had dat die dienst zou verzenden.
- Bevestig bij een bekende afzender die slaagt en is uitgelijnd dat het gerapporteerde volume overeenkomt met het verkeer dat je verwacht.
- Corrigeer bij een bekende afzender die faalt de authenticatie of uitlijning en controleer latere rapporten op het resultaat.
- Stel bij een onbekende afzender die slaagt vast wie deze heeft geconfigureerd en of deze autorisatie moet behouden.
- Onderzoek bij een onbekende afzender die faalt of het een verkeerd geconfigureerde legitieme dienst is of ongeautoriseerd gebruik van je domein.
Los legitieme fouten op voordat je van monitoring overgaat naar quarantaine of weigering, want die berichten zouden anders kandidaten voor handhaving zijn. DMARC-fouten oplossen behandelt veelvoorkomende oorzaken.
Hoe inspecteer je rapporten voor een Bird-verzenddomein?
Je kunt aggregatierapporten naar je eigen mailbox laten sturen via het rua-adres in je DMARC-record. Gebruik de DMARC-rapportanalyzer om de XML te inspecteren, of open een rapport in een teksteditor.
De DNS-verificatie van Bird controleert je gepubliceerde beleid; ontvangerrapporten beschrijven authenticatieresultaten voor berichten. Dit zijn afzonderlijke controles. De authenticatiegids behandelt het beleid en de DNS-records die je publiceert.