Når en pentestrapport nævner SPF, DKIM eller DMARC, handler fundet om, hvor let andre kan sende mail, der ser ud til at komme fra jeres domæne. De tre mekanismer er indstillinger knyttet til domænet, og de lader modtagende mailservere vurdere, om en besked faktisk kommer fra en afsender, I har godkendt. Fundet retter sig derfor ikke mod en server, men mod domænets opsætning og mod overblikket over, hvem der sender på jeres vegne. Rettelsen behøver ikke være teknisk svær, men den kræver et overblik, som ikke alle har.
Fundene kan få middel eller lav alvorlighed, fordi de ikke giver adgang til jeres systemer. Til gengæld rammer de jeres kunder, leverandører og omdømme, og de er derfor værd at tage alvorligt.
Hvad de tre mekanismer gør
Uden at gå i detaljer kan de beskrives sådan:
- SPF · domænet offentliggør, hvilke mailservere der må sende mail i dets navn. Standarden er beskrevet i RFC 7208.
- DKIM · afsenderen signerer beskederne, og modtageren kan kontrollere signaturen mod en nøgle, domænet har offentliggjort. Beskrevet i RFC 6376.
- DMARC · domænet offentliggør en politik for, hvad modtageren skal gøre med beskeder, der ikke passer med SPF eller DKIM, og hvor rapporter skal sendes hen. Den nyeste udgave er RFC 9989.
Hver for sig siger de lidt. Sammen giver de modtageren et grundlag for at afvise eller sortere falske beskeder fra, og de giver jer rapporter om, hvem der sender i jeres navn. Det er værd at bemærke, at mekanismerne virker hos modtageren. I offentliggør oplysningerne, men det er de modtagende mailservere, der beslutter, hvordan de bruges. Derfor er en korrekt opsætning et signal, som modtagerne kan vælge at bruge, ikke en garanti for, hvad hver enkelt modtager gør.
Hvad rapporten konstaterer
Fundene i denne gruppe er konstateringer af, hvordan domænet er sat op. De kan se sådan ud:
- Mekanismen mangler · domænet har ingen SPF-, DKIM- eller DMARC-opsætning.
- Politikken beder ikke om noget · DMARC findes, men beder kun om rapporter, og ingen læser dem.
- For bred tilladelse · SPF tillader så mange afsendere, at den reelt ikke begrænser noget.
- Underdomæner og andre domæner · hoveddomænet er beskyttet, men underdomæner eller ældre domæner er det ikke.
- Fejl i opsætningen · posterne findes, men er skrevet sådan, at modtagere ikke kan bruge dem.
Fundet om ældre domæner er let at overse. Et domæne, I ikke længere sender mail fra, kan stadig bruges som afsender af andre, hvis det ikke er markeret som et domæne uden mail. → Glemte subdomæner og gamle DNS-poster
Hvorfor rettelsen tager tid
Det svære er ikke at skrive posterne. Det svære er at vide, hvem der sender mail i jeres navn. Ud over jeres egen mailtjeneste kan det være nyhedsbrevssystemet, økonomisystemet, der sender fakturaer, kundeservicesystemet, bookingløsningen og et bureau, der sender kampagner. Hvis I strammer politikken, før alle legitime afsendere er med, ender deres beskeder i spam eller bliver afvist.
Derfor sker rettelsen i trin. Først skaffes overblik over afsendere, fx ved at læse de rapporter, DMARC kan levere. Dernæst bringes de legitime afsendere i orden, så de passer med SPF og DKIM. Først derefter strammes politikken, så modtagere bliver bedt om at afvise eller sortere det, der ikke passer. Det er en proces over en periode, ikke en enkelt ændring. → Permanente rettelser
Hvem retter fundet?
Ansvaret kan være spredt, og det er en af grundene til, at fundet bliver liggende. Afklar tre roller:
- Den, der administrerer DNS · kan ændre posterne, men ved ikke nødvendigvis, hvem der sender mail.
- Den, der driver mailtjenesten · kan opsætte signering for jeres egen mail, uanset om den er lokal eller i cloud.
- Ejerne af de øvrige afsendere · marketing, økonomi, kundeservice og deres leverandører skal opsætte deres systemer, så de passer.
IT-afdelingen er den naturlige koordinator, men kan ikke løse opgaven alene. Opret fundet som en opgave med flere deltagere og en plan, ikke som en enkelt ticket til den, der har adgang til DNS. → Fra fund til ticket
Bruger I en mailtjeneste i cloud, er det jeres opgave at opsætte domænet, ikke udbyderens. → Exchange Online
Hvor fundet hører hjemme i prioriteringen
Fund om domænets mailopsætning konkurrerer i rapporten med fund, der giver direkte adgang til systemer. De kommer ikke nødvendigvis øverst, og det kan være rimeligt. Men de bør heller ikke ende nederst af gammel vane.
Tre forhold kan løfte dem. Det første er, om jeres kunder handler på baggrund af mail fra jer, fx fakturaer med betalingsoplysninger eller ordrebekræftelser. Det andet er, om domænet allerede har været brugt i falske beskeder, som kunder eller leverandører har gjort jer opmærksomme på. Det tredje er, om en kunde eller samarbejdspartner har stillet krav om opsætningen.
Selv når fundet ikke kommer øverst, kan første trin begynde med det samme. At begynde at modtage og læse rapporter forstyrrer ikke den daglige mail og giver det overblik, resten af planen bygger på. → Hurtige rettelser
Det skal I lade være med
- At stramme politikken uden overblik over afsendere · legitime beskeder bliver afvist.
- At lade en politik, der kun beder om rapporter, stå i årevis · den beskytter ikke modtagerne.
- At bede om rapporter uden at læse dem · de er jeres bedste kilde til overblik.
- At glemme ældre domæner og underdomæner · de kan bruges i jeres navn.
- At give opgaven til den, der har adgang til DNS, alene · afsenderne ejes af mange.
- At blande fundet sammen med phishingtest · det handler om domænets opsætning, ikke om medarbejdernes reaktion.
Hvad kan og ikke kan konkluderes
Fundene viser, hvordan domænerne i testen var sat op på testtidspunktet, og om opsætningen giver modtagere et grundlag for at genkende falske afsendere. Det er et klart grundlag for en plan.
Fundene siger ikke, om nogen faktisk har sendt falske beskeder i jeres navn. De siger heller ikke, om modtagerne følger jeres politik. Det er op til de modtagende mailservere. Og selv med en stram politik kan en falsk besked komme fra et domæne, der blot ligner jeres. Opsætningen beskytter jeres eget domæne, ikke jeres navn i bredere forstand. Et domæne, der ikke var med i testen, er ikke vurderet. → Overblik over jeres internetvendte systemer
Tjekliste til opsætningen af domænerne
- ☐ Er alle domæner, også ældre og ubrugte, med i gennemgangen?
- ☐ Har hvert domæne SPF, DKIM og DMARC eller markering som domæne uden mail?
- ☐ Er alle systemer, der sender mail i jeres navn, kendt og ejet af nogen?
- ☐ Bliver DMARC-rapporterne læst?
- ☐ Er der en plan for at stramme politikken i trin?
- ☐ Er DNS-administrator, mailtjeneste og afsendernes ejere inddraget?
- ☐ Er nye afsendere en fast del af indkøb og projekter?
Kilder
- RFC 7208: Sender Policy Framework (SPF), domænets liste over tilladte afsendere.
- RFC 6376: DomainKeys Identified Mail (DKIM), signering af beskeder med en nøgle offentliggjort i domænet.
- RFC 9989: DMARC, domænets politik og rapportering; erstatter RFC 7489.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Lokal Exchange-server · Hurtige rettelser
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
