DMARC-rapporter læse

Modul 4: Leveringsevne: SPF, DKIM og DMARC i praksis · Læsetid: 12 minutter

Læringsmål: Efter denne lektion kan du åbne og læse en DMARC-samlerapport, for hver række afgøre hvilken kilde det er og hvorfor den består eller fejler, og beslutte hvad du reparerer, hvad du kan ignorere, og hvornår du kan stramme din politik op.

Nøglebegreber: samlerapport (aggregate report, RFC 9990), rua, XML, gzip eller zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, fejlrapport (ruf, RFC 9991), rapporttjeneste, privatliv

Hvad du modtager

Har du sat en rua-adresse i dit DMARC-record (lektion 4.4), så sender store modtagere som Google, Microsoft og Yahoo dig cirka hver dag en samlerapport. Det er en mail med en vedhæftet fil, som regel en zippet XML-fil med et navn som:

receiver.example!example.com!1793923200!1794009599.xml.gz

Det betyder: fra modtager receiver.example, om dit domæne example.com, for perioden mellem de to tidsstempler (sekunder siden 1970; her 6. november 2026, hele dagen i UTC).

En rapport indeholder intet indhold af mail, ingen emner og som regel ingen adresser på modtagere. Den indeholder for hver afsendende server antallet af beskeder og resultatet af SPF, DKIM og DMARC. Derfor er det et pålideligt overblik over hvem der sender mail på vegne af dit domæne, også kilder du selv havde glemt, og svindlere.

Opbygningen af en rapport

En rapport har tre dele. Herunder de vigtigste dele fra eksempelfilen til denne lektion (dmarc-rapport-1.xml).

1. Hvem rapporterer, for hvilken periode

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Hvilken politik modtageren fandt hos dig

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Kontrollér altid dette: står der ikke det du tror der står i din DNS, så har modtageren læst et andet (eller gammelt) record.

3. Per kilde: et record

Hvert record handler om én afsendende IP-adresse med én kombination af resultater:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Den vigtigste forskel: auth_results over for policy_evaluated

Her ligger kernen i at læse rapporten. I eksemplet ovenfor står der i auth_results to gange pass: DKIM lykkedes for mailer.example og SPF lykkedes for bounce.mailer.example. Alligevel står der i policy_evaluated to gange fail. Det er ikke modsigende: policy_evaluated tæller kun en vellykket kontrol der er justeret med header_from. Ingen af de to domæner hører til example.com, så DMARC fejler.

Sådan læser du hver række:

1. Kig på policy_evaluated. Står der pass ved dkim eller spf? Så lykkes DMARC, og denne kilde er i orden.
2. Fejler alt? Kig i auth_results på domænerne. Er det en tjeneste der tilhører dig, som lykkes, men for sit eget domæne? Så skal du hos den tjeneste slå DKIM til med dit eget domæne (lektion 4.3).
3. Fejler det også i auth_results, eller mangler DKIM helt? Find ud af hvem IP-adressen tilhører (reverse DNS, lektion 5.1, eller et whois-opslag). Er det et af dine egne systemer: reparér det. Er det ukendt og handler det om mistænkelige antal: sandsynligvis forfalskning.

Mønstre du ser igen og igen

Vær også opmærksom på IPv6: en egen server der nogle gange sender over IPv6, mens din SPF kun nævner IPv4-adressen, giver en softfail på de rækker. Med en DKIM-signatur lykkes DMARC alligevel, men det er et tegn på at din SPF er ufuldstændig.

Fra rapport til beslutning

Du er klar til at stramme din politik op (fra none til quarantine, derefter til reject) når:

• hver kilde der er din, i policy_evaluated har mindst én pass;
• det har været sådan i et par uger allerede, hos alle store modtagere;
• det der stadig fejler, kun er videresendt mail med en gyldig DKIM-signatur (den lykkes alligevel) eller tydeligvis forfalskning.

Fejler en stor egen kilde, som i eksemplet nyhedsbrevstjenesten med 1250 beskeder, så er det for tidligt. Med p=reject ville modtageren afvise de 1250 nyhedsbreve.

Gør rapporter læsbare

Én rapport i en teksteditor kan man klare. Tyve om dagen kan man ikke. Der er tre måder:

• En rapporttjeneste (der findes mange, også med en gratis variant). Du indsætter deres adresse i rua, og de laver grafer og lister af det. Bemærk: så giver du den tjeneste indsigt i hvilke servere der sender mail på dine vegne, og rapportadressen ligger på deres domæne (se tilladelsen via _report._dmarc i lektion 4.4). Vælg en tjeneste du stoler på, og som overholder GDPR (databeskyttelsesforordningen).
• Et eget værktøj: der findes open source-programmer der henter rapporter fra en mailboks og sætter dem op i et overblik.
• Selv læse med en XML-viewer eller en browser, til lejlighedsvis brug.

Fejlrapporter (ruf, RFC 9991) er anderledes: pr. mislykket mail, nogle gange med dele af mailen i. Næsten ingen store modtagere sender dem, netop på grund af privatlivet. Du har ikke brug for dem for at indføre DMARC korrekt.

I praksis: sådan ser det ud

Hos WebOké kan du indtaste rapportadressen i DMARC-hjælpen i DirectAdmin eller Mit WebOké (se lektion 4.4), og du vælger selv en mailboks hvor rapporterne kommer ind; en separat adresse som dmarc@ med en egen mappe forhindrer at din almindelige mail drukner. Du læser dem med en rapporttjeneste eller et program efter eget valg. Det fungerer ens hos alle udbydere: rapporten er et standardformat.

Opsummering

• En samlerapport er en daglig XML-fil (ofte zippet) pr. modtager, med for hver afsendende IP antallet af beskeder og resultaterne.
• auth_results viser det rå SPF- og DKIM-resultat; policy_evaluated kun det der lykkedes justeret. En pass i auth_results kan være en fail i DMARC.
• Videresendt mail genkender du på DKIM pass med SPF fail; forfalskning på alt fail fra en ukendt IP.
• Stram først din politik op når alle dine egne kilder har lykkedes i et par uger.
• Fejlrapporter (ruf) er sjældne og ikke nødvendige.

Quiz

Opgave

Opgave Z4.5: Læs en DMARC-rapport. Åbn eksempelfilen dmarc-rapport-1.xml (en samlerapport om example.com, med opdigtede data). Besvar spørgsmålene: hvilken politik fandt modtageren, hvor mange beskeder står der i alt i rapporten, hvor mange af dem fejlede DMARC, hvilken række er nyhedsbrevstjenesten og hvad skal der ske der, hvilken række er videresendt mail, hvilken række er sandsynligvis forfalskning, hvad skal ændres i SPF-recorden ifølge række 6, hvilken række lykkes kun takket være DKIM hos en tjeneste med egen Return-Path, og må domænet nu gå til p=quarantine? Programmet kontrollerer dine svar med en fast facitliste og forklarer for hvert spørgsmål hvilken linje i rapporten der giver svaret.

Læs mere

Trinnene i disse artikler gælder for WebOkés paneler; hos andre udbydere fungerer det på lignende vis.

• Hvad er DMARC? Forklaring i almindeligt sprog
• DirectAdmin vejledning 5.9: DMARC indstilling
• Gratis DNS-kursus 4.5: DMARC: hvad modtagere skal gøre med falsk mail
• RFC 9990 (DMARC Aggregate Reporting), med eksempelrapporten i bilag B; RFC 9991 (Failure Reporting)