Sådan virker DMARC
Når en mail lander hos modtageren, sker tre ting: Serveren tjekker, om afsender-IP’en er godkendt i jeres SPF-record, og om mailens DKIM-signatur er gyldig. Derefter vurderes alignment — altså om det domæne, der bestod tjekket, faktisk matcher det domæne, modtageren ser i “Fra”-feltet. Det er alignment-kravet, der gør DMARC stærkere end SPF og DKIM alene: en angriber kan sagtens bestå SPF for sit eget domæne, men ikke for jeres.
1. SPF og DKIM tjekkes
Modtagerserveren validerer, om mailen kommer fra en godkendt server (SPF), og om den er signeret med jeres kryptografiske nøgle (DKIM).
2. Alignment vurderes
DMARC kræver, at det validerede domæne matcher domænet i Fra-feltet. Det forhindrer, at angribere “låner” et andet domænes godkendelse til at udgive sig for jer.
3. Jeres politik afgør
Fejler begge tjek, følger modtageren den politik, I har publiceret i DNS: gør ingenting, sæt mailen i karantæne — eller afvis den helt.
Sådan ser en DMARC-record ud
En DMARC-record er én TXT-record i DNS på subdomænet _dmarc. Her er et eksempel på en færdig, håndhævet opsætning:
_dmarc.jeresdomæne.dk. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@jeresdomæne.dk; adkim=s; aspf=s; pct=100"| Felt | Betydning |
|---|---|
v=DMARC1 | Versionen — skal altid stå først. |
p=reject | Politikken: afvis mails, der fejler (se næste afsnit). |
rua= | Hvor de aggregerede rapporter sendes hen — jeres øjne på misbrug af domænet. |
adkim=s / aspf=s | Strict alignment — subdomæner kan ikke “låne” hoveddomænets godkendelse. |
pct=100 | Politikken gælder 100 % af mailstrømmen. |
p=none, quarantine eller reject — hvad betyder politikkerne?
Politikken er DMARC’s kerne: Det er jeres instruks til alverdens mailservere om, hvad de skal gøre, når en mail fejler godkendelsen.
| Politik | Hvad sker der | Hvornår er den rigtig |
|---|---|---|
p=none | Ingenting. Mails leveres som normalt, men I modtager rapporter. | Kun som midlertidig overvågningsfase, typisk 2–6 uger. Mange virksomheder bliver desværre stående her i årevis — og er reelt ubeskyttede. |
p=quarantine | Mistænkelige mails sendes i spam/karantæne. | Overgangsfase, når rapporterne viser, at alle legitime afsendere er korrekt sat op. |
p=reject | Mails, der fejler, afvises helt. | Målet. Først her er domænet reelt beskyttet mod spoofing. |
De 4 mest almindelige DMARC-fejl
1. p=none for evigt
Recorden findes, men beskytter ingenting. Det er den hyppigste fejl, vi ser i danske SMV’er: DMARC blev “sat op” engang, politikken blev aldrig strammet, og domænet kan stadig spoofes frit.
2. Glemte tredjepartsafsendere
Nyhedsbrevssystem, bogføring, CRM og support-platform sender alle mails på jeres vegne. Mangler bare én af dem i SPF/DKIM-opsætningen, ryger legitime mails i spam, den dag politikken strammes — og så ruller nogen den tilbage til p=none i panik.
3. Ingen læser rapporterne
rua-rapporterne er XML-filer og ulæselige med det blotte øje. Uden et værktøj til at samle og fortolke dem flyver både misbrug og fejlkonfigurationer under radaren.
4. SPF-recorden sprænger 10-opslags-grænsen
SPF tillader maksimalt 10 DNS-opslag. For mange include:-statements gør hele SPF-tjekket ugyldigt — og så vakler DMARC-fundamentet, uden at nogen opdager det.
Hvad kræver det i praksis?
Selve DNS-ændringerne tager minutter. Arbejdet ligger i rejsen mod p=reject: Først publiceres recorden med p=none, så rapporterne begynder at strømme ind. Derefter analyseres de — hvilke systemer sender legitimt på jeres vegne, og hvilke af dem fejler i dag? Når alle legitime afsendere er bragt på plads i SPF og DKIM, strammes politikken trinvist til quarantine og til sidst reject. For en typisk SMV med en håndfuld afsendersystemer tager forløbet 4–8 uger.
Det er præcis det forløb, vi har produktiseret i E-mail Skjold — og DMARC indgår også i vores bredere ydelse Mail- & Domænesikkerhed.