DMARC i praksis: fra “monitor” til “reject” uden at skyde sig selv i foden

Hvis du strammer din e-mail-sikkerhed for hurtigt, ender du ofte med at blokere dine egne systemer før du stopper de falske afsendere.

I denne artikel får du en praktisk, trin-for-trin tilgang til progression: hvorfor du starter med monitorering, hvordan du identificerer og håndterer legitime sendere, og hvordan du gradvist strammer din policy uden at skabe driftsstop. Du får også konkrete faldgruber, eksempler fra virkeligheden og en enkel plan du kan bruge i morgen.

Tidligt en vigtig definition: DMARC (Domain-based Message Authentication, Reporting & Conformance) er en standard, der fortæller modtageres mailservere, hvordan de skal håndtere mails, der udgiver sig for at komme fra dit domæne, og den giver dig rapporter om, hvem der sender i dit navn. Det betyder noget, fordi DMARC (sammen med SPF og DKIM) både kan reducere phishing med dit domæne og forbedre leveringssikkerheden, hvis du indfører det kontrolleret.

Hvorfor “progression” er den sikre måde at indføre DMARC på

Progression handler om at gå fra synlighed til kontrol: først ser du trafikken (monitorering), derefter rydder du op (legitime sendere), og til sidst håndhæver du (policy). Det lyder banalt, men i praksis er det forskellen på et vellykket DMARC-projekt og en uge med “hvorfor kommer fakturaerne ikke frem?”.

En moden implementering accepterer en grundregel: Du kender sjældent alle afsendere på forhånd. Marketingplatforme, CRM, ticketing, lønsystemer, e-handelskvitteringer, HR-værktøjer, og gamle servere i kælderen kan alle sende på dine vegne.

Mini-konklusion: Start med at få data, før du ændrer adfærd i modtagerenden. Det er den billigste måde at undgå selvmål.

Første tjek og næste step: få overblik uden at blokere noget

Før du skruer på policies, skal du sikre, at de tre byggesten hænger sammen: SPF, DKIM og DMARC. Du kan hurtigt få en status på dit domænes opsætning og se typiske fejl ved at tjek DMARC som en del af dit første tjek.

Det konkrete minimum du skal have på plads

Du behøver ikke perfektion dag 1, men du skal kunne indsamle data og undgå oplagte fejl:

• En DMARC-record i DNS med policy sat til monitorering (p=none).
• SPF der dækker de vigtigste afsendere, uden at overskride DNS-lookup-grænsen (10 lookups).
• DKIM på de platforme, der kan signere (typisk Microsoft 365/Google Workspace og større ESP’er).
• En rapportadresse (rua), der faktisk bliver læst og behandlet.

Hvad koster det at komme i gang?

Selve DNS-ændringer koster typisk ikke noget. Omkostningen ligger i timerne til analyse og oprydning. For et mindre domæne med få afsendere kan du ofte få første overblik på 2–6 timer, mens en organisation med mange systemer og flere domæner ofte skal regne med 1–3 uger i et roligt tempo, fordi afsendere skal spores, testes og koordineres på tværs.

Mini-konklusion: Første step er at etablere “måleinstrumentet” (DMARC-rapportering) og sikre, at du kan reagere, før du overhovedet overvejer at afvise mails.

Trin 1: Start med monitorering (p=none) og lær din e-mail-økologi

Med p=none beder du ikke modtageren om at blokere noget. Du får i stedet rapporter, der viser hvilke IP-adresser og systemer der sender, hvilke der passerer SPF/DKIM, og om domænerne er “aligned” (altså om afsenderdomæne og autentificeringsdomæne matcher på den rigtige måde).

Sådan læser du DMARC-rapporter uden at drukne

DMARC-rapporter kan være støjende, især de første uger. Mit praktiske råd er at arbejde i tre niveauer:

1. Sortér på volumen: Hvem står for 80–90% af trafikken?
2. Markér fejltyper: SPF fail, DKIM fail, alignment fail (ofte den “skjulte” årsag).
3. Identificér ukendte top-sendere og match dem til forretningsejere internt.

En typisk aha-oplevelse: Du tror, at “alt går via Microsoft 365”, men rapporterne afslører, at marketing sender 30% via en ESP, support sender via et ticket-system, og webshoppen sender via en hostingudbyder.

Hvad er “alignment”, og hvorfor fejler det ofte?

Alignment betyder i praksis, at det domæne modtageren ser i From: skal passe sammen med det domæne, der valideres via SPF og/eller DKIM. Mange systemer kan godt sende “fra” dit domæne, men autentificerer med et andet domæne (fx vendor.example), og så kan DMARC fejle selvom SPF eller DKIM teknisk set “passer”.

Mini-konklusion: Monitorering er din kortlægning. Den afslører både de legitime sendere, du har glemt, og de falske, du vil stoppe senere.

Trin 2: Håndtér legitime sendere systematisk (uden at åbne for alt)

Når du ved, hvem der sender, handler næste fase om at gøre de legitime afsendere DMARC-kompatible. Det er her de fleste projekter vinder eller taber: ikke på teorien, men på disciplinen i oprydningen.

Praktisk metode: lav et afsender-katalog

Opret en enkel liste (et “sender inventory”) med disse felter: systemnavn, ejer, From-domæne, teknisk afsender (platform), SPF-kilde, DKIM-selector, volumen, og kritikalitet. På den måde kan du prioritere.

• Kritisk (transaktionelt): faktura, password reset, ordrebekræftelser.
• Vigtigt: interne notifikationer, HR, onboarding.
• Mindre kritisk: nyhedsbreve, kampagner, surveys.
• Ukendt: alt der ikke kan forklares inden for 48 timer.

Typiske legitime scenarier og løsninger

Her er nogle af de mønstre, jeg ofte ser, og hvad der normalt virker:

• Marketingplatform sender på dit domæne: Aktivér DKIM i platformen og brug dedikeret afsenderdomæne (fx mail.firma.dk) for bedre kontrol.
• Webshop/ERP via hosting: Flyt afsendelse til en kendt SMTP (fx Microsoft 365) eller få leverandøren til at signere DKIM for dit domæne.
• Multifunktionsprintere og scannere: Stop direkte afsendelse. Brug autentificeret relay og fast From-adresse, så de ikke “spoof’er” interne brugere.
• Support/ticket-system: Sørg for at systemet bruger dit domæne til DKIM-signering, eller brug “Send on behalf” korrekt med alignment.

Mini-konklusion: “Legitim” er ikke det samme som “klar”. Du skal gøre legitime sendere kompatible, ellers bliver de ofre, når du strammer policy.

Trin 3: Stram gradvist policy (quarantine → reject) med små, kontrollerede hop

Når de vigtigste sendere passerer DMARC stabilt, kan du begynde at håndhæve. Progressionen er typisk: p=none → p=quarantine → p=reject. Jeg anbefaler at tænke i procent og observationer, ikke i datoer i kalenderen.

Brug pct (pct=) til at teste uden at tage alt på én gang

DMARC understøtter en procentvis udrulning. Det betyder, at du kan starte med at sætte p=quarantine og pct=10, så kun ca. 10% af de mails, der fejler DMARC, bliver sendt i spam/junk (afhænger af modtagerens implementering). Når du ser stabile resultater, øger du til 25%, 50% og 100%.

Det samme princip kan bruges, når du går fra quarantine til reject. Det er ikke altid perfekt deterministisk, men det reducerer risikoen markant sammenlignet med et “big bang”.

Hvornår er du klar til reject?

Som tommelfingerregel: når de legitime top-sendere konsekvent passerer (over flere dage/uger), og de resterende fail’s primært er ukendte eller åbenlyse spoof-forsøg. I praksis vil der næsten altid være “støj”, men du skal kunne forklare den.

Mini-konklusion: En stram policy er målet, men den rigtige rækkefølge er vigtigere end hastigheden.

Undgå at blokere egne systemer: de mest almindelige faldgruber

De fleste driftsstop skyldes få klassiske fejl. Her er dem, jeg oftest ser, og hvordan du undgår dem:

• Man strammer policy før oprydning: Løsning: hold p=none indtil dine top-sendere er dokumenteret og rettet.
• SPF bliver “for bred” eller bryder 10-lookup-reglen: Løsning: konsolidér leverandører, brug subdomæner til afsendelse, og undgå at stable include på include.
• DKIM er slået til, men roterer ikke eller er forkert sat op: Løsning: test selectors, tjek længder (1024/2048), og planlæg rotation.
• Alignment overses: Løsning: sørg for at From-domæne matcher det domæne, der autentificeres (SPF og/eller DKIM).
• Forwarding og mail-lister giver SPF-fejl: Løsning: læn dig mod DKIM og overvej ARC i miljøer, hvor det er relevant.
• Glemte subdomæner: Løsning: beslut en politik for subdomæner (sp=) og kortlæg hvem der ejer hvad.

Mini-konklusion: De fleste fejl kan forebygges med en simpel regel: ændr kun én variabel ad gangen, og mål effekten i rapporterne.

Bedste praksis for DNS, drift og samarbejde på tværs

DMARC er ikke kun en DNS-opgave. Det er et samarbejde mellem IT, marketing, support, økonomi og ofte eksterne leverandører. Derfor virker “best practices” bedst, når de er organisatoriske såvel som tekniske.

En enkel governance-model der virker i praksis

• Udpeg en teknisk ejer (typisk IT) og en forretningskontakt pr. afsender.
• Fastlæg godkendelsesflow for nye systemer, der vil sende e-mail.
• Dokumentér standarder: altid DKIM hvor muligt, og undgå direkte afsendelse fra udstyr.
• Planlæg kvartalsvis review af DMARC-rapporter (eller oftere ved ændringer).

Subdomæner som “sikkerhedsventil”

Et konkret greb er at adskille afsendelse på subdomæner: fx nyhedsbrev.firma.dk til marketing og mail.firma.dk til transaktionelle systemer. Det gør det lettere at have forskellige policies, isolere fejl og undgå at én leverandør kompromitterer hele domænets omdømme.

Mini-konklusion: Når du gør governance let, bliver sikkerhed også lettere at vedligeholde.

Sådan ved du, at det virker: målepunkter der giver mening

Det er fristende kun at måle “DMARC pass-rate”, men du bør kombinere flere signaler, så du ikke fejltolker forbedringer.

• Andel af legitim trafik der passerer DMARC (gerne opdelt pr. system).
• Antal unikke ukendte afsendere pr. uge (burde falde).
• Support-henvendelser om manglende mails (før/efter ændringer).
• Leveringsrater på kritiske flows (fx password reset og ordrebekræftelser).
• Phishing-tilfælde med dit domæne (rapporter fra brugere eller SOC).

Hvis du vil have en grov sammenligning: I miljøer med mange spoof-forsøg ser man ofte et tydeligt fald i “uautoriserede kilder” i rapporterne kort efter quarantine/reject. Men den vigtigste gevinst er ofte ro i driften: færre overraskelser, fordi nye sendere bliver fanget tidligt.

Mini-konklusion: Succeskriteriet er ikke bare at afvise mail, men at du kan gøre det uden at ramme dine egne forretningskritiske flows.

En realistisk 30-dages plan du kan følge

Her er en praktisk plan, der passer til de fleste organisationer, uden at kræve en fuldtidsressource:

1. Uge 1: Sæt DMARC til p=none, start rapportering, og lav afsender-katalog for top-sendere.
2. Uge 2: Ret de største legitime afsendere: DKIM først, derefter SPF-oprydning og alignment.
3. Uge 3: Udvid til resterende sendere, håndtér “ukendte” ved at finde ejere eller lukke kilder.
4. Uge 4: Skift til p=quarantine med lav pct, overvåg tæt, og planlæg ramp-up til 100%.
5. Når stabilt: Gå mod p=reject med pct-stigning, og fasthold løbende review.

Hvis du undervejs opdager et system, du ikke kan få til at signere korrekt, er det ofte bedre at flytte afsendelsen (via en kendt gateway) end at “slække” hele domænets politik. Én svag afsender bør ikke definere dit sikkerhedsniveau.

Mini-konklusion: Progression er en proces, ikke et projekt med en enkelt slutdato. Når du har rytmen, bliver DMARC en del af normal drift i stedet for en brandøvelse.