Så läser du DMARC-rapporter: fält för fält genom aggregerad XML

För att läsa en DMARC-rapport öppnar du den komprimerade XML-bilagan, tittar på policy_published för att bekräfta vilken policy mottagarna tillämpade och går sedan igenom varje record-block: source_ip och count visar vem som skickade hur mycket, policy_evaluated ger DMARC-domen och auth_results visar de råa SPF- och DKIM-resultaten under den. En rad som klarar SPF eller DKIM men underkänns i DMARC har ett alignment-problem. En rad som underkänns på allt är antingen en bortglömd avsändare eller någon som spoofar din domän. Den här guiden går igenom en riktig rapport fält för fält, visar de sju mönster du oftast ser och förklarar vad du gör åt vart och ett.

Vad en DMARC-rapport egentligen är

Varje mottagare som stöder DMARC (Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho och många fler) räknar de meddelanden den ser som påstår sig komma från din domän i From-rubriken. En gång per UTC-dygn packar den ihop räkningen i en XML-fil, komprimerar den och mejlar den till adressen i rua=-taggen i din DMARC-post. Det är aggregerade rapporter, ibland kallade RUA-rapporter. De innehåller inget meddelandeinnehåll, bara antal per avsändar-IP med autentiseringsresultaten för varje.

Enligt RFC 9990, publicerad av IETF i maj 2026 som Standards Track-specifikation för aggregerad rapportering, är rapportperioden normalt ett enda UTC-dygn med start 0000 UTC, XML-filen ska i normalfallet vara gzip-komprimerad och varje rapport täcker exakt en policydomän. Rapporterna kommer oavsett om din policy är p=none, p=quarantine eller p=reject. De är den enda återkopplingen DMARC ger dig, och att läsa dem är skillnaden mellan att gå skarpt på ett säkert sätt och att blockera sina egna fakturor.

Av de 1,8 miljoner största domänerna publicerar 937 931 (52,1 %) DMARC, drygt 553 000 samlar in aggregerade rapporter och 411 935 kör skarp policy. Bara omkring 9 % gör bådadera. Källa: EasyDMARC, 2026 DMARC Adoption Report, 30 mars 2026.

Gapet i diagrammet är problemet den här artikeln löser. EasyDMARC:s studie från mars 2026 av de 1,8 miljoner största domänerna fann att bara cirka 9 % kombinerar skarp policy med rapportering. En separat skanning från DMARCguard av 5 499 028 Tranco-domäner den 27 februari 2026 fann att 776 918 av de 1 670 975 DMARC-domänerna (46,5 %) helt saknar rua=-tagg. De flesta domänägare som faktiskt får rapporter öppnar dem aldrig, eftersom rå XML ser avskräckande ut. Det är den inte. Det finns bara tre sektioner.

Steg 1: öppna bilagan

Ett äkta rapportmejl har en ämnesrad i stil med Report Domain: example.com Submitter: google.com Report-ID: 1234567890 och en enda bilaga. RFC 9990 avsnitt 3.5.2 låser filnamnsformatet till mottagare!policydomän!starttid!sluttid.xml.gz, till exempel google.com!example.com!1757462400!1757548799.xml.gz. De två talen är Unix-tidsstämplar för rapportfönstrets början och slut, så du ser vilket dygn som täcks innan du öppnar något.

Packa upp den på kommandoraden:

gunzip google.com!example.com!1757462400!1757548799.xml.gz

Vissa avsändare, däribland Microsoft, använder zip i stället för gzip. Använd då unzip på filen. För att formatera resultatet läsbart:

xmllint --format google.com!example.com!1757462400!1757548799.xml

Vilken textredigerare som helst fungerar också. Det du ser är ett enda feedback-element som innehåller report_metadata, policy_published och ett eller flera record-block.

Steg 2: läs de tre sektionerna

Här är en rapport nedskuren till en post, med strukturen från RFC 9990 bilaga B:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1757548799.example.com</report_id>
    <date_range>
      <begin>1757462400</begin>
      <end>1757548799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>abc123</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Äldre rapporter använder namnrymden http://dmarc.org/dmarc-xml/0.1 från RFC 7489. Fälten är desamma, så du läser dem på samma sätt.

Den distinktion som fäller nästan alla: auth_results är den råa kontrollen, policy_evaluated är kontrollen efter alignment. DMARC räknar bara SPF eller DKIM som godkänt om den autentiserade domänen matchar din header_from-domän. En marknadsföringsplattform som signerar med sin egen domän visar DKIM pass i auth_results och DKIM fail i policy_evaluated. Det är ingen trasig signatur. Det är en oalignad signatur.

Steg 3: klassificera varje rad

När fälten väl sitter blir rapportläsning mönsterigenkänning. De här sju mönstren täcker nästan varje rad du kommer att stöta på.

För en rad du inte kan placera gör du en omvänd uppslagning av IP-adressen med dig -x 192.0.2.123 +short eller host 192.0.2.123 och kontrollerar sedan SPF-include för den leverantör du misstänker. En PTR-post som slutar på outbound.protection.outlook.com, google.com, amazonses.com, sendgrid.net eller mailgun.org pekar oftast rakt på den ansvariga tjänsten.

Läsa rapporter i volym

En domän med några få avsändare ger en handfull filer per dag, och då fungerar handläsning. Över det använder du ett analysverktyg. Ett typiskt verktyg läser rua=-brevlådan, packar upp varje fil och summerar raderna per källa, så att du ser "Microsoft 365: 12 400 meddelanden, 100 % alignade" i stället för fyrtio XML-filer. Det finns gratisalternativ, och FortifyNets egen skanning talar om ifall en rua=-tagg ens finns och är korrekt skriven.

Två vanor betyder mer än verktyget. För det första: håll koll på policy_published efter varje DNS-ändring. Mottagare cachar DMARC-poster, så en rapport som täcker dagen du ändrade p= kan visa den gamla policyn, och RFC 9990 avsnitt 3.3 tillåter uttryckligen en blandning. För det andra: fortsätt läsa efter att du nått p=reject. Nya SaaS-verktyg, roterade DKIM-nycklar och redigerade SPF-poster dyker upp som en ny rad av mönster 2, 4 eller 5 redan nästa dag, långt innan dina kunder märker studsar.

Vad RFC 9990 ändrade för dig som läser

Standarden från maj 2026, som ersätter rapportdelarna i RFC 7489 från 2015, spelar roll om du tolkar rapporter själv eller utvärderar en leverantör.

Alla stora mottagare skickar fortfarande rapporter i det gamla formatet i september 2026, och kommer att göra det länge. Läs båda formaten på samma sätt och kasta aldrig en rapport bara för att den har ett fält du inte känner igen.

Vanliga frågor

Varför får jag DMARC-rapporter för mejl jag aldrig skickat? För att någon annan skickar dem. Aggregerade rapporter täcker varje meddelande som påstått sig komma från din domän i From-rubriken, även förfalskade. En rad med högt antal, okänd IP och underkänt på både SPF och DKIM är exakt den spoofing du satte upp DMARC för att fånga.

Hur många rapporter ska jag förvänta mig per dag? En per rapporterande mottagare per dag och domän, alltså normalt 3 till 15 filer för ett mindre företag. RFC 9990 sätter perioden till ett enda UTC-dygn. Mycket stora mottagare kan dela upp ett dygn i flera filer.

Vad betyder disposition none när jag har p=quarantine? Antingen godkändes meddelandet i DMARC, så ingen policy tillämpades, eller så åsidosatte mottagaren din policy och reason-elementet säger varför. Kontrollera policy_evaluated: om båda alignade resultaten är pass är none rätt disposition.

Innehåller DMARC-rapporter mejlinnehåll eller personuppgifter? Aggregerade rapporter innehåller avsändar-IP, antal och autentiseringsresultat, inget från meddelandekroppen eller rubrikerna utöver From-domänen. Felrapporter (RUF, definierade i RFC 9991) kan innehålla rubriker och skickas sällan av de stora leverantörerna.

Kan jag sluta ta emot rapporter? Ta bort rua=-taggen så slutar mottagarna inom ett dygn. Du förlorar då all insyn i spoofing och felkonfiguration, så att peka rua= mot ett analysverktyg är det bättre alternativet.

Kontrollera om dina rapporter ens kommer fram

Innan du ägnar en kväll åt XML är det bra att veta om din DMARC-post över huvud taget begär rapporter, om rua=-adressen är auktoriserad och om SPF och DKIM är uppsatta hos de avsändare du redan känner till. FortifyNets kostnadsfria skanning läser dina DMARC-, SPF- och DKIM-poster och flaggar det som saknas på cirka 60 sekunder, utan registrering. Kör en gratis skanning hos FortifyNet.

Relaterade guider: DMARC-övervakning: så når du p=reject säkert · Så sätter du upp DMARC steg för steg · Vad är DKIM? · SPF Record Checker