DMARC udrulning: fra none til reject

Modul 4: Leveringsevne: SPF, DKIM og DMARC i praksis · Læsetid: 12 minutter

Læringsmål: Efter denne lektion kan du forklare hvordan tilpasning (alignment) virker, planlægge en DMARC udrulning i faser fra p=none til p=reject, vælge de rigtige tags (rua, sp, np, t) og håndtere de kendte faldgruber ved videresendelse og mailinglister.

Nøglebegreber: DMARC (RFC 9989), Author Domain (domænet i Fra), tilpasning (alignment), relaxed og strict (adkim, aspf), organisationsdomæne, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (testtilstand), udgåede tags pct, rf, ri, mailinglister, omskrivning af From, ARC

Hvad DMARC helt præcist kontrollerer

DMARC besvarer ét spørgsmål for hver indkommende mail: bestod SPF eller DKIM for et domæne der hører til Fra-adressen? Domænet i Fra-adressen kaldes i standarden Author Domain. Grundlaget for recorden står i DNS-kurset, lektion 4.5. I maj 2026 udkom den reviderede standard: RFC 9989, med RFC 9990 til de aggregerede rapporter og RFC 9991 til fejlrapporterne. Eksisterende records med v=DMARC1 forbliver gyldige.

Tilpasning i praksis

"Hører til" kaldes tilpasning (alignment). Der findes to tilstande:

• relaxed (standard): domænerne har samme organisationsdomæne. nieuws.example.com og example.com er tilpassede; example.com og example.net er det ikke.
• strict (adkim=s eller aspf=s): domænerne skal være præcis ens.

Til SPF sammenligner DMARC domænet i Return-Path med Fra-domænet. Til DKIM d=-domænet i en gyldig signatur. Nogle eksempler for en mail med Fra: info@example.com:

Lad derfor adkim og aspf stå på relaxed, medmindre du har en god grund til andet.

Hvordan ved en modtager hvad organisationsdomænet er? Tidligere med Public Suffix List, en liste med domæner som .nl, .co.uk og github.io. RFC 9989 erstatter det med en DNS tree walk: modtageren slår _dmarc-records op for domænet og de overliggende domæner. For en almindelig bruger ændrer intet sig; du mærker det kun hvis du arbejder med records på subdomæner.

Udrulningen i fire faser

Målet er p=reject: så afviser modtagere mail der udgiver sig for at være fra dig, og det er den bedste beskyttelse mod falske fakturaer og phishing i dit navn. Men den der går direkte til reject uden at kende sine afsendere, kommer til at afvise sine egne fakturaer. Derfor denne rækkefølge (denne kursusets anbefaling):

Fase 0: forberedelse

• Lav en oversigt over alle dine afsendere (lektion 4.2).
• Sørg for at hver afsender har SPF eller DKIM tilpasset; helst DKIM, da det overlever videresendelse.
• Opret en separat adresse til rapporter, for eksempel dmarc@example.com, eller brug en rapporttjeneste. Du vil hurtigt modtage flere rapporter om dagen.

Fase 1: mål med p=none

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

p=none gør ikke noget med selve mailen. Modtagere leverer alt som sædvanligt, men sender dig dagligt en aggregeret rapport (aggregate report) med hver server der sendte mail på vegne af dit domæne, og om SPF, DKIM og DMARC bestod. Dermed opfylder du også minimumskravet fra Gmail, Yahoo og Microsoft til bulkafsendere (lektion 5.3).

Lad dette stå mindst to til fire uger, og længere hvis du har tjenester der kun sender mail af og til (en årlig påmindelse, en kvartalsvis faktura). Læs rapporterne (lektion 4.5) og reparer hver egen kilde der fejler.

Fase 2: p=quarantine

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

Mail der ikke kommer igennem DMARC, går hos modtageren til spammappen. Glemmer du alligevel en kilde, så er mailen ikke væk, men svær at finde. Vil du være forsigtig, så tilføj først t=y (testtilstand): modtagere anvender så et trin mildere politik (ved quarantine altså none), men du kan se i rapporterne hvad der ville ske. Dette er i RFC 9989 erstatningen for den gamle tag pct=.

Hold igen øje med rapporterne i et par uger.

Fase 3: p=reject

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

Mail der ikke kommer igennem DMARC, bliver afvist. Afsenderen får en bounce, hos Microsoft for eksempel med koden 5.7.509 og hos Gmail med en henvisning til DMARC-politikken (modul 6). Bliv ved med at følge rapporterne: der kommer altid nye tjenester til.

Hvornår kan det gå hurtigere?

Går al din mail gennem én udbyder der klarer SPF og DKIM for dig, og sender intet andet på vegne af dit domæne? Så kan en streng politik indføres med det samme. Nogle hostingvirksomheder sætter derfor p=reject som standard. Begynder du derefter alligevel at bruge en nyhedsbrevstjeneste eller et regnskabsprogram, så sæt det først midlertidigt tilbage til p=none med en rapportadresse, indtil den tjeneste fungerer korrekt.

De andre tags

En rapportadresse på et andet domæne (for eksempel en rapporttjeneste) virker kun hvis det domæne giver tilladelse med en record som example.com._report._dmarc.rapportdienst.example. Tjenesten ordner det normalt selv (RFC 9990, kapitel 4).

Faldgruber

Mailinglister

En klassisk mailingliste sender din mail videre til alle medlemmer, fra sin egen server, og tilføjer ofte [liste] til emnet eller en fodtekst. Så fejler SPF (anden server) og DKIM (mailen er ændret). Med p=reject afviser modtagerne din besked til listen. Moderne listesoftware løser dette ved at omskrive Fra-adressen til listeadressen ("Jan via Medlemmer"), eller ved at videresende mailen uændret. Bruger du en liste der ikke gør det, vil du se det i dine rapporter.

Videresendelse

Se lektion 3.3: SPF brydes, DKIM overlever som regel. En modtager kan med ARC beslutte at stole på en kendt videresender. I rapporterne genkender du dette som mail fra en ukendt server med DKIM pass og SPF fail; det er ingen grund til at lempe din politik.

To records eller en tastefejl

To DMARC-records på _dmarc gør politikken ugyldig, og en tastefejl i p= gør det samme (p=rejected findes ikke). Kontrollér efter hver ændring.

I praksis: sådan ser det ud i et panel

Ved en hostingpakke fra WebOké står som standard v=DMARC1;p=reject, uden rapportadresse. Det er sikkert hvis al din mail går gennem de servere. Sender du også mail via andre tjenester, så sæt det på p=none med en rua-adresse og gennemfør faserne. I DirectAdmin gør du det i DNS-administration med blyanten bag _dmarc-recorden (felterne Domænepolitikkens type og Aggregeret e-mail (RUA)); i Mit WebOké med DMARC-hjælpen under fanen DNS. Hos andre udbydere opretter du en TXT-record med navnet _dmarc og skriver teksten selv; resultatet er det samme.

Opsummering

• DMARC bestod hvis SPF eller DKIM bestod for et domæne der er tilpasset med Fra-domænet; relaxed tilpasning accepterer subdomæner.
• Udrulning: oversigt, p=none med rua og rapporterne læses, p=quarantine (eventuelt med t=y), og derefter p=reject.
• Brug np=reject til subdomæner der ikke findes, så snart hovedpolitikken er streng. pct, rf og ri er udgåede.
• Mailinglister og videresendelse giver forventede fejl; DKIM og ARC opfanger en del af det.
• Præcis én record på _dmarc, uden tastefejl.

Quiz

Opgave

Opgave Z4.4: Kontrollér DMARC for dit domæne og vælg næste trin. Indtast dit eget domæne (eller internet.nl). Indtast DMARC-recorden som du fandt den, værdien af p= og om der står en rua-adresse. Vælg derefter hvilken fase af udrulningen du mener er næste skridt, og hvorfor. Programmet slår recorden op live, kontrollerer syntaksen ifølge RFC 9989 (én record, gyldig p, kendte tags, udgåede tags som advarsel), og sammenligner dine svar.

Læs mere

Trinene i disse artikler gælder for panelerne hos WebOké; hos andre udbydere fungerer det på lignende vis.

• Gratis DNS-kursus 4.5: DMARC: hvad modtagere skal gøre med falsk mail
• DirectAdmin vejledning 5.9: DMARC indstilling
• Hvad er DMARC? Forklaring i almindeligt sprog
• Opret DMARC-post i DirectAdmin
• RFC 9989 (DMARC), især 4.7 (tags) og bilag C (ændringer siden RFC 7489)