DMARC-rapporten läsa

Modul 4: Leveransbarhet: SPF, DKIM och DMARC i praktiken · Lästid: 12 minuter

Lärandemål: Efter den här lektionen kan du öppna och läsa ett DMARC-sammanställningsrapport, avgöra per rad vilken källa det gäller och varför den godkänns eller underkänns, och bestämma vad du ska åtgärda, vad du kan ignorera och när du kan skärpa din policy.

Nyckelbegrepp: sammanställningsrapport (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, felrapport (ruf, RFC 9991), rapporteringstjänst, integritet

Vad du får in

Har du angett en rua-adress i ditt DMARC-record (lektion 4.4), skickar stora mottagare som Google, Microsoft och Yahoo dig ungefär varje dag ett sammanställningsrapport. Det är ett mejl med en bilaga, oftast en zippad XML-fil med ett namn som:

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

Det betyder: från mottagaren receiver.example, om ditt domän example.com, om perioden mellan de två tidsstämplarna (sekunder sedan 1970, här 6 november 2026, hela dagen i UTC).

Ett rapport innehåller inget innehåll från mejlen, inga ämnesrader och oftast inga mottagaradresser. Det innehåller per avsändande server antalet meddelanden och resultatet av SPF, DKIM och DMARC. Det gör det till en tillförlitlig översikt över vem som skickar mejl i ditt domäns namn, även källor du själv glömt bort, och bedragare.

Uppbyggnaden av ett rapport

Ett rapport har tre delar. Nedan de viktigaste delarna från exempelfilen till denna lektion (dmarc-rapport-1.xml).

1. Vem rapporterar, under vilken period

<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. Vilken policy mottagaren hittade 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>

Kontrollera alltid detta: om det inte stämmer med vad du tror står i din DNS, läste mottagaren ett annat (eller gammalt) record.

3. Per källa: ett record

Varje record gäller en avsändande IP-adress med en kombination av resultat:

<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 viktigaste skillnaden: auth_results jämfört med policy_evaluated

Här ligger kärnan i läsningen. I exemplet ovan står det i auth_results två gånger pass: DKIM godkändes för mailer.example och SPF godkändes för bounce.mailer.example. Ändå står det i policy_evaluated två gånger fail. Det är ingen motsägelse: policy_evaluated räknar bara en godkänd kontroll som är uppriktad med header_from. Ingen av domänerna hör till example.com, så DMARC underkänns.

Så läser du varje rad:

1. Titta på policy_evaluated. Står det pass vid dkim eller spf? Då godkänns DMARC och källan är i sin ordning.
2. Misslyckas allt? Titta i auth_results på domänerna. Är det en tjänst du själv använder som godkänns, men för sin egen domän? Då ska du hos den tjänsten aktivera DKIM med ditt eget domän (lektion 4.3).
3. Misslyckas det även i auth_results, eller saknas DKIM helt? Ta reda på vem IP-adressen tillhör (reverse DNS, lektion 5.1, eller en whois-sökning). Är det ett av dina egna system: åtgärda det. Är det okänt och rör det sig om misstänkta antal: troligen förfalskning.

Mönster du ser gång på gång

Håll även koll på IPv6: en egen server som ibland skickar via IPv6, medan din SPF bara anger IPv4-adressen, ger softfail på de raderna. Med en DKIM-signatur godkänns DMARC ändå, men det är ett tecken på att din SPF är ofullständig.

Från rapport till beslut

Du är redo att skärpa din policy (från none till quarantine, därefter till reject) när:

• varje källa som är din har minst ett pass i policy_evaluated;
• det har varit så i några veckor, hos alla stora mottagare;
• det som fortfarande misslyckas bara är vidarebefordrat mejl med en giltig DKIM-signatur (som då ändå godkänns) eller tydlig förfalskning.

Misslyckas en stor egen källa, som i exemplet nyhetsbrevstjänsten med 1250 meddelanden, är det för tidigt. Med p=reject skulle mottagaren neka de 1250 nyhetsbreven.

Gör rapporten läsbar

Ett rapport i en texteditor går an. Tjugo om dagen gör det inte. Det finns tre sätt:

• En rapporteringstjänst (det finns många, även med en gratisvariant). Du anger deras adress i rua och de gör grafer och listor av det. Observera: då ger du den tjänsten insyn i vilka servrar som skickar i ditt namn, och rapportadressen ligger på deras domän (se bekräftelsen via _report._dmarc i lektion 4.4). Välj en tjänst du litar på och som följer GDPR (dataskyddsförordningen).
• Ett eget verktyg: det finns öppen källkod-program som hämtar rapporter från en brevlåda och gör en översikt av dem.
• Läsa själv med en XML-visare eller en webbläsare, för tillfällen då och då.

Felrapporter (ruf, RFC 9991) är annorlunda: per misslyckat mejl, ibland med delar av mejlet i sig. Nästan ingen stor mottagare skickar dem, just på grund av integriteten. Du behöver dem inte för att införa DMARC på rätt sätt.

I praktiken: så här ser det ut

Hos WebOké kan du ange rapportadressen i DMARC-hjälpen i DirectAdmin eller Mitt WebOké (se lektion 4.4), och du väljer själv en brevlåda dit rapporterna kommer in; en separat adress som dmarc@ med en egen mapp förhindrar att din vanliga post drunknar. Du läser rapporterna med en rapporteringstjänst eller ett program du väljer själv. Det fungerar likadant hos alla leverantörer: rapporten är ett standardformat.

Sammanfattning

• Ett sammanställningsrapport är en daglig XML-fil (ofta zippad) per mottagare, med antalet meddelanden och resultaten per avsändande IP.
• auth_results ger det råa SPF- och DKIM-resultatet; policy_evaluated bara det som godkändes uppriktat. Ett pass i auth_results kan vara ett fail i DMARC.
• Vidarebefordrat mejl känner du igen på DKIM pass med SPF fail; förfalskning på att allt är fail från ett okänt IP.
• Skärp din policy först när alla dina egna källor har godkänts i några veckor.
• Felrapporter (ruf) är sällsynta och behövs inte.

Quiz

Uppgift

Uppgift Z4.5: Läsa en DMARC-rapport. Öppna exempelfilen dmarc-rapport-1.xml (ett sammanställningsrapport om example.com, med påhittade uppgifter). Besvara frågorna: vilken policy hittade mottagaren, hur många meddelanden finns totalt i rapporten, hur många av dem underkändes av DMARC, vilken rad är nyhetsbrevstjänsten och vad behöver göras där, vilken rad är vidarebefordrat mejl, vilken rad är troligen förfalskning, vad behöver ändras i SPF-recordet enligt rad 6, vilken rad godkänns bara tack vare DKIM hos en tjänst med egen Return-Path, och kan domänen nu gå till p=quarantine? Programmet kontrollerar dina svar mot en facit och förklarar för varje fråga vilken rad i rapporten som ger svaret.

Läs mer

Stegen i dessa artiklar gäller för WebOkés paneler; hos andra leverantörer fungerar det på liknande sätt.

• Vad är DMARC? Förklaring i vanligt språk
• DirectAdmin-guide 5.9: DMARC ställa in
• Gratis DNS-kurs 4.5: DMARC: vad mottagare ska göra med falsk e-post
• RFC 9990 (DMARC Aggregate Reporting), med exempelrapporten i bilaga B; RFC 9991 (Failure Reporting)