DMARC utrulling: fra none til reject

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

Læringsmål: Etter denne leksjonen kan du forklare hvordan justering (alignment) fungerer, planlegge en DMARC-utrulling i faser fra p=none til p=reject, velge riktige tagger (rua, sp, np, t) og håndtere de kjente fallgruvene ved videresending og e-postlister.

Nøkkelbegreper: DMARC (RFC 9989), Author Domain (domenet i From), justering (alignment), relaxed og strict (adkim, aspf), organisasjonsdomene, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (testmodus), utgåtte tagger pct, rf, ri, e-postlister, omskriving av From, ARC

Hva DMARC egentlig kontrollerer

DMARC besvarer ett spørsmål for hver innkommende e-post: er SPF eller DKIM godkjent for et domene som hører til From-adressen? Domenet i From-adressen kalles i standarden Author Domain. Grunnlaget for recorden står i DNS-kurset, leksjon 4.5. I mai 2026 kom den reviderte standarden: RFC 9989, med RFC 9990 for aggregerte rapporter og RFC 9991 for feilrapporter. Eksisterende records med v=DMARC1 fortsetter å gjelde som før.

Justering i praksis

"Hører til" kalles justering (alignment). Det finnes to moduser:

• relaxed (standard): domenene har samme organisasjonsdomene. nieuws.example.com og example.com er justert; example.com og example.net er det ikke.
• strict (adkim=s eller aspf=s): domenene må være nøyaktig like.

For SPF sammenligner DMARC domenet til Return-Path med From-domenet. For DKIM sammenlignes d=-domenet til en gyldig signatur. Noen eksempler for en e-post med Fra: info@example.com:

La derfor adkim og aspf stå på relaxed, med mindre du har en god grunn til noe annet.

Hvordan vet en mottaker hva organisasjonsdomenet er? Tidligere med Public Suffix List, en liste med domener som .nl, .co.uk og github.io. RFC 9989 erstatter dette med en DNS tree walk: mottakeren slår opp _dmarc-records for domenet og de overordnede domenene. For en vanlig bruker endrer dette ingenting; du merker det bare hvis du jobber med records på underdomener.

Utrullingen i fire faser

Målet er p=reject: da avviser mottakere e-post som utgir seg for å være deg, og det er den beste beskyttelsen mot falske fakturaer og phishing i ditt navn. Men den som går rett på reject uten å kjenne sine avsendere, kommer til å avvise sine egne fakturaer. Derfor denne rekkefølgen (anbefalingen i dette kurset):

Fase 0: forberedelse

• Lag en oversikt over alle avsenderne dine (leksjon 4.2).
• Sørg for at hver avsender har SPF eller DKIM justert; helst DKIM, siden det overlever videresending.
• Lag en egen adresse for rapporter, for eksempel dmarc@example.com, eller bruk en rapporttjeneste. Du får raskt flere rapporter om dagen.

Fase 1: måling med p=none

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none gjør ingenting med selve e-posten. Mottakere leverer alt som vanlig, men sender deg daglig en aggregert rapport (aggregate report) med hver server som sendte e-post på vegne av domenet ditt, og om SPF, DKIM og DMARC ble godkjent. Dermed oppfyller du også minimumskravet fra Gmail, Yahoo og Microsoft for bulkavsendere (leksjon 5.3).

La dette stå i minst to til fire uker, og lenger hvis du har tjenester som bare sender e-post av og til (en årlig påminnelse, en kvartalsfaktura). Les rapportene (leksjon 4.5) og reparer enhver egen kilde som feiler.

Fase 2: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

E-post som ikke består DMARC, går hos mottakeren til spammappen. Glemmer du likevel en kilde, er e-posten ikke borte, men vanskelig å finne. Vil du være forsiktig, legg da først til t=y (testmodus): mottakere bruker da en mildere policy ett trinn ned (ved quarantine altså none), men du ser i rapportene hva som ville skjedd. Dette er i RFC 9989 erstatningen for den gamle taggen pct=.

Se igjen på rapportene i noen uker.

Fase 3: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

E-post som ikke består DMARC, blir avvist. Avsenderen får en bounce, hos Microsoft for eksempel med koden 5.7.509 og hos Gmail med en henvisning til DMARC-policyen (modul 6). Fortsett å følge rapportene: nye tjenester kommer alltid til.

Når kan det gå raskere?

Går all e-posten din gjennom én leverandør som ordner SPF og DKIM for deg, og sender du ellers ingenting i domenets navn? Da kan en streng policy settes med én gang. Enkelte hostingselskaper setter derfor p=reject som standard. Begynner du etterpå likevel å bruke en nyhetsbrevtjeneste eller et regnskapsprogram, sett det da først midlertidig tilbake til p=none med en rapportadresse, til den tjenesten er korrekt satt opp.

De andre taggene

En rapportadresse på et annet domene (for eksempel en rapporttjeneste) fungerer bare hvis det domenet gir tillatelse med en record som example.com._report._dmarc.rapportdienst.example. Tjenesten ordner dette som regel selv (RFC 9990, kapittel 4).

Fallgruver

E-postlister

En klassisk e-postliste videresender e-posten din til alle medlemmer, fra sin egen server, og legger ofte til [liste] i emnefeltet eller en bunntekst. Da feiler SPF (annen server) og DKIM (e-posten er endret). Med p=reject avviser mottakerne meldingen din til listen. Moderne listeprogramvare løser dette ved å skrive om From-adressen til listeadressen ("Jan via Medlemmer"), eller ved å videresende e-posten uendret. Bruker du en liste som ikke gjør dette, ser du det igjen i rapportene dine.

Videresending

Se leksjon 3.3: SPF brytes, DKIM overlever som regel. En mottaker kan med ARC velge å stole på en kjent videresender. I rapportene kjenner du dette igjen som e-post fra en ukjent server med DKIM pass og SPF fail; det er ingen grunn til å gjøre policyen mildere.

To records eller en skrivefeil

To DMARC-records på _dmarc gjør policyen ugyldig, og en skrivefeil i p= gjør det samme (p=rejected finnes ikke). Kontroller etter hver endring.

I praksis: slik ser det ut i et panel

Ved en hostingpakke fra WebOké er v=DMARC1;p=reject satt som standard, uten rapportadresse. Det er trygt hvis all e-posten din går gjennom disse serverne. Sender du også via andre tjenester, sett det da på p=none med en rua-adresse og arbeid deg gjennom fasene. I DirectAdmin gjør du dette i DNS Administration med blyanten bak _dmarc-recorden (feltene Domain policy type og Aggregate Email (RUA)); i Min side med DMARC-hjelpen på fanen DNS. Hos andre leverandører lager du en TXT-record på navnet _dmarc og skriver teksten selv; resultatet er det samme.

Oppsummering

• DMARC består hvis SPF eller DKIM består for et domene som er justert med From-domenet; relaxed justering godtar underdomener.
• Utrulling: kartlegging, p=none med rua og lesing av rapporter, p=quarantine (eventuelt med t=y), og deretter p=reject.
• Bruk np=reject for underdomener som ikke finnes, så snart hovedpolicyen er streng. pct, rf og ri er utgått.
• E-postlister og videresending gir forventede feil; DKIM og ARC fanger opp en del av dette.
• Nøyaktig én record på _dmarc, uten skrivefeil.

Quiz

Oppgave

Oppgave Z4.4: Kontrollere DMARC for domenet ditt og velge neste steg. Fyll inn ditt eget domene (eller internet.nl). Fyll inn DMARC-recorden slik du fant den, verdien av p= og om det finnes en rua-adresse i den. Velg deretter hvilken fase av utrullingen du mener er neste steg, og hvorfor. Programmet slår opp recorden i sanntid, kontrollerer syntaksen i henhold til RFC 9989 (én record, gyldig p, kjente tagger, utgåtte tagger som advarsel), og setter svarene dine ved siden av.

Les mer

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

• Gratis DNS-kurs 4.5: DMARC: hva mottakere skal gjøre med falsk e-post
• DirectAdmin-veiledning 5.9: DMARC instellen
• Hva er DMARC? Forklart på en enkel måte
• Opprett DMARC-post i DirectAdmin
• RFC 9989 (DMARC), særlig 4.7 (tagger) og vedlegg C (endringer siden RFC 7489)