Slik leser du DMARC-rapporter (RUA)

2026-09-26 · 8 min lesetid · Av MailWatch-teamet

En DMARC-rapport (RUA, aggregert rapport) er en XML-fil som mottakere som Google, Microsoft og Yahoo sender deg, vanligvis én gang i døgnet. Den viser hvilke IP-adresser som har sendt e-post med ditt domene i From-feltet, hvor mange meldinger det var, og om de passerte SPF, DKIM og DMARC. Ved å lese rapportene finner du alle legitime avsendere som må rettes opp, og du ser om noen forsøker å forfalske domenet ditt.

Hva er en DMARC-rapport?

DMARC (RFC 7489) definerer to typer rapporter:

• Aggregerte rapporter (rua): Statistikk per avsender-IP over en periode, typisk 24 timer. Inneholder ikke innholdet i meldingene. Det er disse denne artikkelen handler om.
• Feilrapporter (ruf): Kopier eller utdrag av enkeltmeldinger som feilet. Få store mottakere sender dem i dag, blant annet av personvernhensyn.

Du ber om aggregerte rapporter ved å legge til rua= i DMARC-posten:

_dmarc.firma.no.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@firma.no"

Skal rapportene sendes til en adresse på et annet domene, for eksempel en tjeneste som tolker dem for deg, må mottakerdomenet bekrefte at det tar imot rapporter for ditt domene med en egen DNS-post (firma.no._report._dmarc.mottaker.no). Seriøse rapporttjenester ordner dette automatisk. Er du usikker på grunnlaget, les først hva DMARC er.

XML-strukturen forklart med et eksempel

Her er en forenklet, men realistisk rapport fra en stor mottaker for domenet firma.no. Den inneholder to records: én fra Microsoft 365 som passerer, og én fra en ukjent IP som feiler.

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1758844800</begin>
      <end>1758931199</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>firma.no</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>40.107.22.51</source_ip>
      <count>148</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>firma.no</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>firma.no</domain>
        <selector>selector1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>firma.no</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>203.0.113.77</source_ip>
      <count>12</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>firma.no</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mail.eksempel.net</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

report_metadata

Hvem som har laget rapporten (org_name), en unik rapport-ID og perioden rapporten dekker. Tidspunktene i date_range er Unix-tid i sekunder (UTC). I eksempelet dekker rapporten ett døgn.

policy_published

DMARC-posten slik mottakeren så den da den behandlet meldingene. Nyttig for å bekrefte at en endring faktisk har slått igjennom: står det fortsatt p=none i rapportene etter at du byttet til quarantine, har mottakeren ikke sett den nye posten ennå.

record og row

Hver record samler meldinger med samme kombinasjon av avsender-IP og resultater. source_ip er IP-adressen som leverte meldingene, og count er hvor mange meldinger det gjelder.

policy_evaluated

Dette er DMARC-vurderingen. disposition viser hva mottakeren faktisk gjorde (none, quarantine eller reject). dkim og spf her viser om de passerte med alignment mot From-domenet. DMARC passerer hvis minst én av dem er pass. Feltet kan også ha en reason med typer som forwarded, mailing_list, local_policy eller trusted_forwarder hvis mottakeren har overstyrt policyen.

identifiers

header_from er domenet i From-feltet, altså det mottakeren ser. Noen rapportører tar også med envelope_from (Return-Path-domenet).

auth_results

De rå resultatene for SPF og DKIM, uavhengig av alignment. Her ser du hvilket domene SPF ble sjekket mot, og hvilket domene og hvilken selector DKIM-signaturen brukte.

Hva du skal se etter

Når du går gjennom rapportene, er det lurt å gruppere records etter avsender-IP og organisasjon, og så sortere etter antall meldinger. Still disse spørsmålene for hver kilde:

1. Hvem eier IP-adressen? Slå opp PTR (reverse DNS) og eventuelt hvem som eier IP-blokken. 40.107.x.x tilhører Microsoft, 209.85.x.x Google, og nyhetsbrev- og transaksjonstjenester har gjerne tydelige vertsnavn.
2. Er dette en tjeneste vi bruker? Sammenlign med listen over systemer som skal sende for domenet.
3. Passerer den DMARC? Minst én av dkim og spf i policy_evaluated må være pass.
4. Hvis den feiler – hvorfor? Se i auth_results: mangler DKIM-signatur, signeres det med leverandørens domene, eller står IP-en ikke i SPF?

Legitime kilder eller forfalskning?

De fleste kilder i rapportene havner i en av fire kategorier. Tabellen gir et utgangspunkt for hvordan du tolker og håndterer dem.

Et klassisk forfalskningsmønster er et lite antall meldinger fra IP-adresser i helt andre deler av verden, uten DKIM-signatur og med SPF som enten feiler eller passerer for et helt annet domene. Ser du dette samtidig med at ansatte får falske fakturaer, bør du prioritere å komme til p=reject. Les mer om direktørsvindel og falske fakturaer.

Videresending, e-postlister og ARC

Videresending er den vanligste grunnen til at legitim e-post feiler i rapportene. Når en mottaker videresender e-post fra jobbadressen til en privat Gmail-konto, blir meldingen levert fra videresenderens server. Den IP-adressen står selvfølgelig ikke i din SPF-post, så SPF feiler.

DKIM overlever derimot som regel, fordi signaturen følger med meldingen. Så lenge innholdet og de signerte headerne ikke endres, passerer DKIM fortsatt med alignment, og DMARC passerer. Dette er hovedgrunnen til at alle avsendere bør ha DKIM for eget domene.

E-postlister er vanskeligere. De endrer ofte emnefeltet (for eksempel ved å legge til [liste]) eller legger til en bunntekst, og da brytes DKIM-signaturen. Mange listeservere løser det ved å skrive om From-adressen til listens egen adresse.

ARC (Authenticated Received Chain, RFC 8617) er laget for dette problemet. En videresender som støtter ARC registrerer autentiseringsresultatene slik de var da meldingen kom inn, og signerer dem. Neste mottaker kan da velge å stole på den kjeden og la meldingen passere selv om SPF og DKIM nå feiler. I rapportene ser du det ofte som en reason med type forwarded, trusted_forwarder eller local_policy i policy_evaluated. Du kan ikke styre ARC selv som avsender, men det er nyttig å vite hvorfor noen meldinger som feiler DMARC likevel ikke blir avvist.

Manuell lesing eller automatisk analyse?

For et lite domene med én eller to avsendere kan du fint lese noen rapporter manuelt for å forstå hvordan de fungerer. Men volumet vokser raskt: hver mottaker sender én rapport per døgn, rapportene er komprimerte vedlegg, og samme avsender dukker opp i mange rapporter fra ulike mottakere. Det er uoversiktlig å følge utviklingen over tid.

Et verktøy som mottar og tolker rapportene automatisk slår sammen dataene per avsender, slår opp hvem som eier IP-adressene og viser trender. Det gjør det mye enklere å gå trygt fra p=none til p=reject, slik vi beskriver i DMARC-oppsett steg for steg.

Ofte stilte spørsmål

Hvor ofte kommer DMARC-rapporter?

De fleste store mottakere sender aggregerte DMARC-rapporter én gang i døgnet, og hver rapport dekker vanligvis 24 timer. Du får én rapport fra hver mottaker som har fått e-post fra domenet ditt i perioden. Små mottakere sender ofte ikke rapporter i det hele tatt.

Hva er forskjellen på rua og ruf?

rua er adressen for aggregerte rapporter, som inneholder statistikk per avsender-IP uten meldingsinnhold. ruf er adressen for feilrapporter, som kan inneholde utdrag av enkeltmeldinger som feilet. Få store mottakere sender feilrapporter i dag, så rua er den viktigste.

Hvorfor passerer SPF i auth_results, men feiler i policy_evaluated?

auth_results viser det rå SPF-resultatet for domenet i envelope-from, mens policy_evaluated viser om resultatet var alignet med From-domenet. Hvis SPF passerte for leverandørens domene og ikke ditt, feiler SPF i DMARC-sammenheng. Løsningen er vanligvis å sette opp DKIM for ditt eget domene hos tjenesten.

Er alle ukjente IP-adresser i rapporten svindlere?

Nei. Mange ukjente IP-er er videresendere, e-postlister eller tjenester noen i bedriften har tatt i bruk uten å si fra. Sjekk PTR og hvem som eier IP-blokken før du konkluderer. Kilder som feiler både SPF og DKIM og ikke kan knyttes til en kjent tjeneste, er som regel forfalskning.

Kan jeg sende DMARC-rapporter til en annen adresse enn mitt eget domene?

Ja, rua kan peke til en adresse på et annet domene, for eksempel en rapporttjeneste. Da må mottakerdomenet publisere en DNS-post som bekrefter at det tar imot rapporter for ditt domene. Uten den posten vil mange mottakere ikke sende rapportene.

Oppsummering

DMARC-rapporter er det beste verktøyet du har for å forstå hvem som sender e-post i ditt navn. Se på policy_evaluated for DMARC-resultatet, bruk auth_results for å finne årsaken når noe feiler, og skill mellom legitime tjenester, videresending og forfalskning. MailWatch tar imot og tolker rapportene automatisk, viser avsenderne dine med SPF- og DKIM-resultat, og varsler deg hvis noe endrer seg. Start med å sjekke domenet ditt gratis, eller prøv MailWatch gratis i 30 dager.

Prøv MailWatch gratis i 30 dager · Sjekk domenet ditt gratis