Forestil dig, at en af dine kunder ringer og fortæller, at han har modtaget en e-mail fra dig med en anmodning om bankoverførsel. Du har ikke sendt den. Afsenderen var dit domæne, dit navn, din signatur - men e-mailen kom fra en server i et andet land. Dine kunder tror det er ægte, og det er præcis det, angriberne regner med.
Dette scenarie er ikke teoretisk. Domæne-spoofing er en af de mest udbredte metoder i phishing-angreb, og det sker fordi e-mailprotokollen SMTP som udgangspunkt ikke verificerer, hvem der egentlig sender. DMARC er den mekanisme, der lukker det hul - men kun hvis du implementerer den korrekt og fuldfører processen frem til p=reject.
Hvad DMARC er, og hvad det faktisk gør
DMARC står for Domain-based Message Authentication, Reporting and Conformance. Det er en DNS-baseret politik, der bygger oven på de to eksisterende e-mailautentificeringsstandarder SPF og DKIM. Hvor SPF definerer hvilke servere der må sende på vegne af dit domæne, og DKIM kryptografisk signerer e-mailens indhold, fortæller DMARC den modtagende mailserver, hvad den skal gøre, hvis en e-mail fejler disse tjek.
DMARC tilføjer desuden et afgørende element: alignment. Det er ikke nok, at SPF eller DKIM passerer - domænet i afsenderadressen (From-headeren) skal stemme overens med det domæne, der er verificeret i SPF eller DKIM. Det er netop denne alignment-kontrol, der forhindrer spoofing af det synlige afsenderdomæne.
Endelig introducerer DMARC et rapporteringssystem. Modtagende mailservere sender aggregerede rapporter tilbage til dig, så du løbende kan se, hvem der sender e-mail på vegne af dit domæne - og om det passerer eller fejler autentificering.
De tre DMARC-policies og deres konsekvenser
En DMARC-record indeholder altid en p-parameter (policy), der angiver, hvad modtagende servere skal gøre med e-mails, der fejler DMARC-tjekket. Der er tre mulige værdier:
p=none - Overvågningstilstand. E-mails leveres normalt uanset om de fejler DMARC. Ingen e-mails bliver blokeret eller sorteret. Til gengæld modtager du rapporter om, hvad der sker. Dette er udgangspunktet for enhver DMARC-implementering.
p=quarantine - E-mails der fejler DMARC, ender i modtagerens spammappe i stedet for indbakken. Det er et mellemtrin, der giver dig mulighed for at opdage eventuelle fejlkonfigurationer, inden du skruer helt op.
p=reject - E-mails der fejler DMARC, afvises fuldstændigt af den modtagende server. De leveres aldrig. Dette er slutmålet - den eneste policy, der reelt stopper spoofing.
Hvorfor du ikke må springe direkte til reject
Det er fristende at sætte p=reject med det samme. Logikken er forståelig: du vil beskytte dit domæne nu. Men hvis du gør det uden forberedelse, risikerer du at blokere legitime e-mails fra tjenester, du selv bruger - dit nyhedsbrevssystem, din supportplatform, dit regnskabsprogram eller din CRM-løsning.
Mange virksomheder sender e-mail via tredjepartstjenester, som ikke er korrekt konfigureret i SPF eller DKIM. Hvis du sætter reject fra dag ét, vil disse e-mails aldrig nå frem til modtagerne - og du vil ikke engang vide, hvilke tjenester der er berørt. Processen fra none til reject handler om at kortlægge hele dit e-mail-landskab, inden du lukker porten.
Trin 1: Opret din første DMARC-record med p=none
En DMARC-record er en TXT-record i DNS, der tilhører subdomænet _dmarc.ditdomæne.dk. Den mindste funktionelle record ser sådan ud:
v=DMARC1; p=none; rua=mailto:dmarc@ditdomæne.dkv=DMARC1 angiver versionen. p=none sætter overvågningspolicyen. rua er adressen, hvor aggregerede rapporter sendes hen - typisk en dedikeret postkasse, du opretter til formålet.
Du kan bruge DNSinfos DMARC generator til at bygge din record uden at skulle huske syntaksen. Indsæt domænet, vælg p=none, angiv din rua-adresse og kopiér den færdige record direkte ind i dit DNS-panel. Propagering tager typisk 15-60 minutter.
Trin 2: Aflæs dine DMARC-rapporter
Efter et par dage begynder rapporterne at ankomme. De leveres i XML-format, og rå XML er ikke særlig læsevenligt. Brug et gratis værktøj som MXToolbox DMARC Analyzer, Google Postmaster Tools eller dmarcian til at visualisere rapporterne.
Det du leder efter, er to ting: hvilke IP-adresser og afsendersystemer der sender e-mail på vegne af dit domæne, og om disse e-mails passerer SPF og DKIM alignment. Typiske fund i denne fase inkluderer:
Din primære mailserver - bør passere begge tjek. Hvis den ikke gør det, er SPF eller DKIM fejlkonfigureret.
Tredjepartstjenester - nyhedsbrevplatforme, CRM-systemer, faktureringsværktøjer og lignende, der sender på dine vegne. Disse skal konfigureres korrekt, inden du skifter policy.
Ukendte afsendere - IP-adresser du ikke genkender. Det kan være spoofing-forsøg, og netop disse vil blive blokeret, når du når til reject.
Trin 3: Ryd op i SPF og DKIM
Med rapporterne som grundlag ved du nu præcis, hvilke afsendersystemer der er i brug. For hver legitim tjeneste du finder, skal du sikre, at den er korrekt inkluderet i din SPF-record og helst også konfigureret med DKIM-signering.
Tilføj tredjeparts-afsendere til SPF ved at inkludere deres include:-mekanisme. Husk at SPF har en grænse på 10 DNS-opslag - overstiger du denne grænse, fejler SPF-tjekket. Aktiver DKIM-signering direkte i de pågældende tjenester, typisk ved at tilføje en CNAME- eller TXT-record i DNS som tjenesten anviser.
Gentag rapportanalysen i mindst 1-2 uger, til du er sikker på, at alle kendte afsendere passerer autentificeringen konsistent.
Trin 4: Skift til p=quarantine
Når rapporterne viser, at alle dine legitime afsendere passerer DMARC, er du klar til at skrue op. Opdater din DMARC-record til:
v=DMARC1; p=quarantine; rua=mailto:dmarc@ditdomæne.dkFra nu af vil e-mails, der fejler DMARC, ende i modtagernes spammappe frem for indbakken. Observer i 2-4 uger. Tjek rapporterne nøje for tegn på, at legitime e-mails nu fejler - det kan skyldes en tjeneste, du glemte, eller en ny integration der er sat op i mellemtiden.
Modtager du klager fra samarbejdspartnere eller kunder om, at e-mails fra dig havner i spam, er det et signal om, at der stadig er et autentificeringsproblem, der skal løses, inden du går videre.
Trin 5: Skift til p=reject
Når quarantine-fasen er stabil, og rapporterne bekræfter, at alle legitime afsendere konsekvent passerer, foretager du det endelige skift:
v=DMARC1; p=reject; rua=mailto:dmarc@ditdomæne.dkFra dette tidspunkt afvises alle e-mails, der fejler DMARC, fuldstændigt. Ingen spoofet e-mail fra dit domæne vil nå frem til en modtager hos en mailserver, der respekterer DMARC - og det gør alle store udbydere som Gmail, Outlook og Yahoo.
Pct-tagget: En gradvis indfasning
Hvis du er usikker på om alt er korrekt konfigureret, men alligevel vil begynde at håndhæve politikken, kan du bruge pct-tagget. Det angiver, hvilken procentdel af e-mails der skal underkastes policyen:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@ditdomæne.dkMed pct=25 gælder quarantine-policyen kun for 25% af de e-mails, der fejler DMARC. De resterende 75% leveres som normalt. Du kan gradvist øge denne procent - 25, 50, 75, 100 - mens du overvåger effekten. Pct-tagget er særligt nyttigt for store organisationer med komplekse e-mail-infrastrukturer, hvor risikoen for at ramme legitime afsendere er højere.
Subdomain policy: sp-tagget
Som standard arver dine subdomæner den policy, du har sat på roddomænet. Sender nyhedsbrev.ditdomæne.dk e-mails, vil de blive vurderet efter din hoved-DMARC-record. Men i visse tilfælde ønsker du en separat politik for subdomæner - for eksempel hvis du vil køre roddomænet på reject, men have et specifikt subdomæne i quarantine under opsætning.
sp-tagget (subdomain policy) giver dig denne kontrol:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@ditdomæne.dkHer gælder reject for roddomænet, mens subdomæner kun får quarantine. Alternativt kan du oprette separate DMARC-records direkte på de pågældende subdomæner - en record på _dmarc.nyhedsbrev.ditdomæne.dk vil altid have forrang over roddomænets sp-tag.
Tjek din nuværende DMARC-status
Før du begynder - eller for at verificere, at din record er korrekt publiceret - kan du slå dit domænes aktuelle DMARC-konfiguration op med DNSinfos DNS-opslagsværktøj. Søg på _dmarc.ditdomæne.dk som TXT-record, og du ser præcis, hvad der er publiceret i DNS lige nu.
Processen fra p=none til p=reject er ikke kompleks - den kræver blot tålmodighed og systematik. Virksomheder der springer trin over, ender enten med blokerede legitime e-mails eller med en p=none-record der aldrig blev opdateret og derfor ikke beskytter noget som helst. Følg trinnene, læs rapporterne, og dit domæne vil være reelt beskyttet mod spoofing - ikke kun på papiret.
