Lese DMARC-rapporter etter RFC 9990

En DMARC-rapport kan avsløre en glemt nyhetsbrevtjeneste, en feilkonfigurert fakturaløsning eller forsøk på å misbruke domenet ditt. Men den forteller ikke automatisk hvilken tjeneste som står bak en IP-adresse, og et DMARC-resultat er ikke det samme som innboksplassering.

Den gjeldende standarden for aggregerte DMARC-rapporter er RFC 9990, publisert i mai 2026. Den erstatter rapportformatet som fulgte den eldre DMARC-standarden RFC 7489. Har du et verktøy eller en intern parser, bør du kontrollere at den forstår det nye XML-navnerommet og feltene i formatet.

Hva en RUA-rapport kan svare på

rua i DMARC-posten angir hvor aggregerte rapporter skal sendes:

v=DMARC1; p=none; rua=mailto:dmarc@eksempel.no

Rapportene kan vise:

• hvilket domene mottakeren vurderte
• hvilken kilde-IP mottakeren så
• antall meldinger i en gruppe
• om SPF eller DKIM ga et DMARC-justert resultat
• underliggende SPF- og DKIM-resultater, inkludert DKIM-selector
• publisert policy og eventuelle grunner til at mottakeren overstyrte den

Rapportene kan ikke alene fastslå:

• hvilken person som sendte en melding
• hvem som eier eller bruker en delt leverandør-IP
• om meldingen havnet i innboksen, søppelposten eller en intern kø
• om innholdet var legitimt
• om en avsender bør legges til i SPF-posten din

Bruk derfor rapporten som et målegrunnlag, ikke som en automatisk fasit.

Aggregerte rapporter og feilrapporter er forskjellige

DMARC har to separate rapporttyper:

Aggregerte rapporter skal ikke inneholde individuelle brukeradresser, individuelle mottaker-IP-er eller meldingsinnhold. De inneholder likevel metadata om infrastrukturen din. Begrens tilgangen, avklar lagringstid og vurder databehandlerforhold hvis en tredjepart analyserer dem.

Ikke legg til ruf bare fordi feltet finnes. Gjør det bare når dere har et konkret, vurdert behov og en mottaker som kan behandle mer følsomme data forsvarlig.

Bruk en egen rapportadresse

Rapporter kommer gjerne som komprimerte XML-filer. Bruk en separat adresse som faktisk kan motta vedlegg og som behandles av et egnet system. En vanlig innboks som ingen følger med på, gir ingen beskyttelse.

Start gjerne med:

v=DMARC1; p=none; rua=mailto:dmarc@eksempel.no

Ikke endre til håndheving før dere har kartlagt de legitime avsenderne og sett en representativ periode. Lengden avhenger av virksomheten: månedlig fakturering, sesongkampanjer og sjeldne varsler må også være med.

Ekstern rapportadresse må godkjennes i DNS

Sender du rapporter til et annet organisasjonsdomene, må mottakerdomenet normalt bekrefte at det godtar dem. Hvis blue.example.com sender rapporter til dmarc@red.example.net, slås følgende navn opp:

blue.example.com._report._dmarc.red.example.net

Der må det ligge en TXT-post som begynner med:

v=DMARC1

Uten denne godkjenningen kan rapportene utebli. En rapporttjeneste bør oppgi nøyaktig hvilken post du skal publisere.

Slik er en rapport bygget opp

RFC 9990 bruker XML-navnerommet urn:ietf:params:xml:ns:dmarc-2.0. Et forkortet eksempel kan se slik ut:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>Eksempel mottaker</org_name>
    <report_id>2026-08-22-001</report_id>
    <date_range>
      <begin>1787356800</begin>
      <end>1787443200</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>eksempel.no</domain>
    <p>quarantine</p>
    <sp>none</sp>
    <np>none</np>
    <testing>n</testing>
    <discovery_method>treewalk</discovery_method>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>bounce.eksempel.no</envelope_from>
      <header_from>eksempel.no</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>eksempel.no</domain>
        <result>pass</result>
        <selector>mail2026</selector>
      </dkim>
      <spf>
        <domain>bounce.eksempel.no</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Rapporten består i praksis av fem deler:

1. report_metadata identifiserer rapportøren, rapport-ID-en og tidsrommet.
2. policy_published viser policyen mottakeren observerte, blant annet p, sp, np, teststatus og oppslagsmetode.
3. row viser kilde-IP, antall og det DMARC-justerte resultatet.
4. identifiers viser domenene i synlig Fra-felt og envelope-from.
5. auth_results viser de underliggende SPF- og DKIM-kontrollene, inkludert signeringsdomene og selector.

En rapportperiode kan inneholde trafikk vurdert mot både gammel og ny policy hvis DNS-posten ble endret underveis. Ikke anta at én verdi i policy_published forklarer alle radene etter en nylig endring.

Alignment er nøkkelen til riktig tolkning

DMARC spør ikke bare om SPF eller DKIM teknisk sett bestod. Domenet som bestod må også være aligned, altså samsvare med domenet i det synlige Fra-feltet etter reglene i DMARC-policyen.

Dette skillet er viktig:

• policy_evaluated viser om SPF og DKIM bestod som DMARC-justerte mekanismer.
• auth_results viser de underliggende kontrollene, også signaturer og SPF-domener som ikke er aligned.
• DMARC består når minst én av mekanismene både består og er aligned.

En DKIM-signatur kan derfor stå som pass under auth_results, mens DKIM står som fail under policy_evaluated. Det betyr ofte at signaturen var gyldig, men brukte feil domene for DMARC.

Vanlige mønstre og riktig handling

En ukjent kilde som består er ofte viktigere å undersøke enn en tilfeldig kilde som feiler. Den kan ha tilgang gjennom en gammel API-nøkkel, en fortsatt publisert DKIM-nøkkel eller en for bred SPF-autorisasjon.

En arbeidsflyt som skalerer

1. Valider rapporten. Kontroller format, rapportør, tidsrom og domene før den tas inn.
2. Fjern duplikater. Bruk rapportør, rapport-ID og tidsrom. Vær forberedt på overlappende perioder.
3. Grupper trafikken. Bruk synlig Fra-domene, kilde-IP, SPF-domene, DKIM-domene og selector.
4. Koble gruppene til en avsenderoversikt. Faktura, CRM, supportsystem, nyhetsbrev og skytjenester bør ha en navngitt eier.
5. Klassifiser. Legitim og riktig satt opp, legitim med feil, ukjent autorisert eller uautorisert.
6. Test den faktiske tjenesten. Undersøk meldingshoder og leverandørens dokumentasjon før DNS endres.
7. Rett eller fjern tilgang. Korriger alignment, roter nøkkel eller opphev autorisasjon.
8. Mål på nytt. Se om feilen forsvinner uten at en annen legitim strøm blir borte.

Ikke legg en IP-adresse i SPF bare fordi den dukker opp i en rapport. Delte IP-er kan brukes av mange kunder, og leverandøren kan kreve en annen mekanisme. Følg den dokumenterte oppskriften for avsenderdomenet.

Behandle rapportfiler som utrygge data

Rapportene kommer fra eksterne systemer og kan være feilaktige, forfalskede eller konstruert for å angripe parseren. En robust mottaker bør:

• begrense størrelse før og etter dekomprimering
• avvise uventede arkivformater og svært mange filer
• bruke en XML-parser uten eksterne entiteter eller nettverkstilgang
• validere struktur, datatyper, tidsrom og domene
• håndtere duplikater og overlapp uten å blåse opp tallene
• rense verdier før de vises i et nettgrensesnitt
• aldri endre DNS eller autorisasjoner automatisk fra én rapport

Dette gjelder også når du kjøper en rapporttjeneste. Be om et konkret svar på hvordan komprimerte filer, XML-angrep og duplikater håndteres.

Velge verktøy eller rapporttjeneste

Et pent diagram er ikke nok. Vurder om løsningen:

• støtter RFC 9990 og XML-navnerommet for DMARC 2.0
• hjelper med DNS-godkjenning av ekstern rapportadresse
• viser forskjellen på aligned resultat og underliggende autentisering
• viser DKIM-selector, SPF-domene, kilde-IP og policyoverstyringer
• kan skille organisasjonsdomener, underdomener og flere kunder
• lar deg eksportere rådata og ferdige klassifiseringer
• oppdager nye autoriserte kilder, ikke bare feilende trafikk
• dokumenterer datalagring, sletting, tilgang og underleverandører
• lar deg flytte historikk og rapportadresse uten å bli låst inne

Kontroller støtte i praksis. En tjeneste kan markedsføre «DMARC-støtte» og likevel bare forstå det gamle rapportformatet.

Fra observasjon til håndheving

Ikke bruk en fast regel om at p=none alltid skal stå i to eller fire uker. Samle data lenge nok til å dekke de sendingene virksomheten faktisk har. Sørg deretter for at legitime avsendere har alignment, fjern gamle autorisasjoner og definer hvem som godkjenner policyendringen.

RFC 9989 bruker ikke den gamle pct-taggen. Planlegg derfor overgangen med kontrollerte policyendringer og reell overvåking, ikke med en prosentverdi kopiert fra eldre guider. Se DMARC-policy fra kartlegging til håndheving for en oppdatert fremgangsmåte.

Hva Vymo leverer

Vymos publiserte e-postpakker omfatter e-postkonto, lagringsplass, aliaser og tilgangsprotokoller. De lover ikke en administrert DMARC-rapporttjeneste eller løpende analyse av rapportene. Bruk en egen rapportmottaker eller avklar et konkret oppdrag før du baserer sikkerhetsarbeidet på at noen følger med.

Trenger du hjelp med en bestemt feil, kan du sende oss domenet og en kort beskrivelse . Oppgi gjerne kildekategori, omtrentlig volum og hvilke justerte resultater som feiler. Ikke send rå rapportarkiver eller meldingsinnhold gjennom et vanlig kontaktskjema.