DMARC-rapporter lese

Modul 4: Leveringsdyktighet: SPF, DKIM og DMARC i praksis · Lesetid: 12 minutter

Læringsmål: Etter denne leksjonen kan du åpne og lese en DMARC-samlerapport, avgjøre per rad hvilken kilde det er og hvorfor den består eller feiler, og bestemme hva du skal reparere, hva du kan ignorere og når du kan stramme inn policyen din.

Nøkkelbegreper: 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, feilrapport (ruf, RFC 9991), rapporttjeneste, personvern

Hva du mottar

Har du satt opp en rua-adresse i DMARC-posten din (leksjon 4.4), sender store mottakere som Google, Microsoft og Yahoo deg omtrent hver dag en samlerapport. Det er en e-post med et vedlegg, som regel en zippet XML-fil med et navn som:

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

Det betyr: fra mottakeren receiver.example, om domenet ditt example.com, om perioden mellom de to tidsstemplene (sekunder siden 1970, her 6. november 2026, hele dagen i UTC).

En rapport inneholder ikke innholdet i e-postene, ingen emnefelt og som regel ingen adresser til mottakere. Den inneholder, per avsendende server, antall meldinger og utfallet av SPF, DKIM og DMARC. Dermed gir den en pålitelig oversikt over hvem som sender e-post på vegne av domenet ditt, også kilder du selv hadde glemt, og svindlere.

Oppbygningen av en rapport

En rapport har tre deler. Under følger de viktigste delene fra eksempelfilen til denne leksjonen (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 policy mottakeren fant hos deg

<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>

Sjekk alltid dette: står det ikke det du tror står i DNS-en din, har mottakeren lest en annen (eller gammel) post.

3. Per kilde: en record

Hver record gjelder én avsendende IP-adresse med én kombinasjon av utfall:

<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 viktigste forskjellen: auth_results versus policy_evaluated

Her ligger kjernen i lesingen. I eksempelet over står det i auth_results to ganger pass: DKIM besto for mailer.example, og SPF besto for bounce.mailer.example. Likevel står det i policy_evaluated to ganger fail. Det er ikke en motsigelse: policy_evaluated teller bare en bestått kontroll som er justert (aligned) med header_from. Ingen av domenene hører til example.com, så DMARC feiler.

Slik leser du hver rad:

1. Se på policy_evaluated. Står det pass ved dkim eller spf? Da består DMARC, og denne kilden er i orden.
2. Feiler alt? Se i auth_results på domenene. Er det en av dine egne tjenester som faktisk består, men for sitt eget domene? Da må du slå på DKIM med ditt eget domene hos den tjenesten (leksjon 4.3).
3. Feiler det også i auth_results, eller mangler DKIM helt? Finn ut hvem IP-adressen tilhører (reverse DNS, leksjon 5.1, eller et whois-oppslag). Er det et av dine egne systemer: reparer det. Er det ukjent og gjelder mistenkelige mengder: trolig forfalskning.

Mønstre du stadig ser

Vær også oppmerksom på IPv6: en egen server som av og til sender over IPv6, mens SPF-en din bare nevner IPv4-adressen, gir softfail på de radene. Med en DKIM-signatur består DMARC likevel, men det er et tegn på at SPF-en din er ufullstendig.

Fra rapport til beslutning

Du er klar til å stramme inn policyen din (fra none til quarantine, deretter til reject) når:

• hver kilde som er din, har minst én pass i policy_evaluated;
• det har vært slik i noen uker, hos alle de store mottakerne;
• det som fortsatt feiler, bare er videresendt e-post med en gyldig DKIM-signatur (som da likevel består) eller tydelig forfalskning.

Feiler en stor egen kilde, som i eksempelet nyhetsbrevtjenesten med 1250 meldinger, er det for tidlig. Med p=reject ville mottakeren avvist de 1250 nyhetsbrevene.

Gjøre rapportene leselige

Én rapport i en teksteditor går greit. Tjue om dagen gjør det ikke. Det finnes tre måter:

• En rapporttjeneste (det finnes mange, også med en gratis variant). Du setter adressen deres i rua, og de lager grafer og lister av dataene. Vær oppmerksom: da gir du den tjenesten innsyn i hvilke servere som sender e-post på dine vegne, og rapportadressen ligger på deres domene (se godkjenningen via _report._dmarc i leksjon 4.4). Velg en tjeneste du stoler på, og som overholder GDPR (personvernforordningen).
• Et eget verktøy: det finnes åpen kildekode-programmer som henter rapporter fra en mailboks og setter dem i en oversikt.
• Lese selv med en XML-viewer eller en nettleser, for sporadisk bruk.

Feilrapporter (ruf, RFC 9991) er annerledes: per mislykket e-post, noen ganger med deler av e-posten inkludert. Nesten ingen store mottakere sender dem, nettopp på grunn av personvernet. Du trenger dem ikke for å innføre DMARC på riktig måte.

I praksis: slik ser det ut

Hos WebOké kan du fylle inn rapportadressen i DMARC-hjelpen i DirectAdmin eller Min side (se leksjon 4.4), og du velger selv en mailboks der rapportene kommer inn; en egen adresse som dmarc@ med en egen mappe hindrer at den vanlige e-posten din drukner. Lesingen gjør du med en rapporttjeneste eller et program etter eget valg. Det fungerer likt hos alle leverandører: rapporten er et standardformat.

Oppsummering

• En samlerapport er en daglig XML-fil (ofte zippet) per mottaker, med antall meldinger og utfall per avsendende IP.
• auth_results gir det rå SPF- og DKIM-utfallet; policy_evaluated viser bare det som besto justert. En pass i auth_results kan være en fail i DMARC.
• Videresendt e-post kjenner du igjen på DKIM pass med SPF fail; forfalskning på alt fail fra en ukjent IP.
• Stram inn policyen din først når alle dine egne kilder har bestått i noen uker.
• Feilrapporter (ruf) er sjeldne og ikke nødvendige.

Quiz

Oppgave

Oppgave Z4.5: Lese en DMARC-rapport. Åpne eksempelfilen dmarc-rapport-1.xml (en samlerapport om example.com, med oppdiktede data). Svar på spørsmålene: hvilken policy fant mottakeren, hvor mange meldinger står det til sammen i rapporten, hvor mange av dem feilet DMARC, hvilken rad er nyhetsbrevtjenesten og hva må gjøres der, hvilken rad er videresendt e-post, hvilken rad er sannsynligvis forfalskning, hva må endres i SPF-posten ifølge rad 6, hvilken rad består bare takket være DKIM hos en tjeneste med egen Return-Path, og kan domenet nå gå til p=quarantine? Programmet sjekker svarene dine mot en fasit og forklarer per spørsmål hvilken linje i rapporten som gir svaret.

Les mer

Trinnene i disse artiklene gjelder for panelene til WebOké; hos andre leverandører fungerer det på lignende måte.

• Hva er DMARC? Forklart på en enkel måte
• DirectAdmin-veiledning 5.9: DMARC instellen
• Gratis DNS-kurs 4.5: DMARC: hva mottakere skal gjøre med falsk e-post
• RFC 9990 (DMARC Aggregate Reporting), med eksempelrapporten i vedlegg B; RFC 9991 (Failure Reporting)