DMARC

DMARC står for Domain-Based Message Authentication, Reporting, and Conformance. Det er en standard, der hjælper domæneejere og modtagende mailservere med at vurdere mails, som bruger domænet i det synlige Fra-felt. Den gældende kernestandard er siden 2026 beskrevet i RFC 9989.

DMARC bygger på resultater fra SPF og DKIM, men kræver også alignment. Det betyder, at det domæne, som består autentificeringen, skal have den krævede relation til domænet i Fra-feltet. En mail kan derfor have SPF pass og stadig fejle DMARC, hvis domænerne ikke hænger sammen.

Domæneejeren publicerer en politik i DNS under _dmarc.domæne.dk. Politikken kan anmode om overvågning eller en vurdering som none, quarantine eller reject for mails, der fejler. Den kan også angive adresser til rapporter om, hvordan domænet bruges.

DMARC stopper ikke alle phishingforsøg. Det beskytter især mod uautoriseret brug af selve Fra-domænet. Angreb med et forvirrende lookalike-domæne eller virksomhedens navn i display name kan stadig forekomme og kræver andre kontroller.

Start med at sikre, at alle legitime afsendere bruger korrekt SPF eller DKIM med alignment. Kortlæg medarbejdermail, nyhedsbreve, CRM, fakturaer, bookingsystem, kontaktformularer og webshop. Mange virksomheder opdager først ved DMARC, hvor mange eksterne tjenester der sender på deres vegne.

Opret derefter en TXT-record på _dmarc med en overvågningspolitik. En typisk start har v=DMARC1; p=none og en rua-adresse til aggregate rapporter. Rapporterne viser, hvilke kilder der sender, og om SPF, DKIM og alignment består.

Gennemgå rapporterne over en repræsentativ periode. Godkend legitime systemer korrekt i stedet for blot at whiteliste alt. Når de forventede afsendere består, kan politikken strammes til quarantine og senere reject. Ændringen bør være planlagt og dokumenteret.

Kontrollér også subdomæner og tredjepartsdelegationer. En tjeneste kan signere med sit eget domæne eller bruge et tilpasset returdomæne. Målet er ikke, at alle systemer skal se ens ud, men at mindst én autentificeringsmekanisme består med den nødvendige alignment.

En virksomhed bruger Microsoft 365 til almindelig mail, Mailchimp til nyhedsbreve og et økonomisystem til fakturaer. Microsoft-mail består DKIM-alignment, Mailchimp er korrekt konfigureret med et tilpasset signeringsdomæne, men økonomisystemet sender med leverandørens returdomæne uden aligned DKIM. DMARC-rapporterne afslører forskellen.

Hvis virksomheden går direkte til p=reject, kan fakturaerne blive afvist hos modtagere. I stedet rettes økonomisystemets domæneopsætning først. Når rapporterne viser stabilt pass, kan reject aktiveres med langt mindre risiko.

En angriber sender mail med Fra: direktør@example.dk fra en tilfældig server. Serveren er ikke godkendt i SPF, og beskeden har ingen aligned DKIM-signatur. DMARC fejler, og modtageren kan bruge domænets reject-politik som et stærkt signal om at afvise mailen.

En anden angriber registrerer examp1e.dk med tallet 1 og sender gyldigt fra det domæne. DMARC på example.dk kan ikke beskytte mod alle sådanne lookalikes, fordi Fra-domænet teknisk er et andet. Overvågning, medarbejdertræning og brandbeskyttelse er fortsat nødvendige.

Den største fejl er at kopiere en streng record fra en generator og aktivere reject samme dag. DMARC er ikke kun en tekstlinje; det er en proces, hvor alle legitime mailflows skal forstås. Ellers bliver sikkerhedsforbedringen til et leveringsproblem.

En anden faldgrube er at læse SPF pass som DMARC pass. SPF kan bestå for et returdomæne, som ikke er aligned med Fra-domænet. Se den fulde Authentication-Results-header og DMARC-resultatet i stedet for ét grønt flueben.

Pas også på rapportadressen. Aggregate rapporter kan være mange XML-filer og bør behandles i et værktøj eller en proces, der giver overblik. Adressen skal kunne modtage mængden, og eksterne rapportmodtagere kan kræve ekstra DNS-godkendelse.

Til sidst skal DMARC-recorden følge den aktuelle standard og den valgte leverandørs understøttelse. I 2026 afløste RFC 9989 den oprindelige RFC 7489, og separate standarder beskriver aggregate og failure reporting. Gamle guides kan derfor indeholde historiske tags eller råd.

DMARC pass kræver mindst én aligned mekanisme, ikke nødvendigvis både SPF og DKIM. Mange organisationer forsøger alligevel at få begge til at fungere, fordi videresendelse og ændringer i mailflow kan påvirke mekanismerne forskelligt.

Politikken p=none betyder overvågning og er ikke en instruktion om at afvise. Quarantine anmoder om mere mistænkelig behandling, mens reject er den strengeste vurdering. Modtagende systemer træffer stadig deres endelige håndteringsbeslutning.

Rapporter giver også indsigt i uventede legitime systemer og muligt misbrug. De bør derfor fortsat overvåges efter reject. En ny marketingplatform eller formular kan ellers begynde at fejle, uden at nogen forbinder problemet med DNS-politikken.

Alignment findes i relaxed og strict form. Relaxed accepterer normalt samme organisatoriske domæne, mens strict kræver et mere præcist match. De fleste starter med relaxed, fordi legitime leverandører ofte bruger subdomæner. Strammere alignment bør kun vælges efter en konkret vurdering.

DMARC-aggregate rapporter samler statistiske resultater fra modtagere. De indeholder typisk afsender-IP, antal beskeder og SPF-, DKIM- og alignmentresultater, men ikke selve mailteksten. De er velegnede til at se mønstre, ikke til at læse enkeltstående kundemails.

Rapportdækningen er ikke komplet. Ikke alle modtagere sender rapporter, og enkelte flows kan være vanskelige at identificere ud fra IP-adressen alene. Kombinér derfor rapporter med leverandørlister, mailheaders og testbeskeder, når en ukendt kilde undersøges.

Subdomænepolitikken kan styres særskilt. Det er relevant, hvis marketingmail sendes fra news.example.dk, mens medarbejdermail bruger example.dk. En tydelig opdeling kan begrænse konsekvensen af leverandørændringer og gøre rapporterne lettere at forstå.

Når reject er aktiv, bør ændringer i mailplatforme behandles som en produktionsændring. Den nye leverandør skal have SPF eller DKIM alignment på plads før udsendelsen. Ellers kan en markedsføringskampagne fejle netop hos de modtagere, der håndhæver politikken mest konsekvent.

DMARC beskytter brandets domæne, men det erstatter ikke sikker mailadfærd. Medarbejdere kan stadig modtage phishing fra andre domæner, og kompromitterede legitime konti kan sende autentificeret misbrug. Kontobeskyttelse, multifaktor og træning er fortsat nødvendige.

Politikken kan også hjælpe modtagere med at behandle ikke-eksisterende subdomæner, afhængigt af den aktuelle standard og tags. Sådanne muligheder bør sættes med støtte fra opdateret dokumentation, fordi ældre DMARC-guides kan beskrive historiske eller ændrede mekanismer.

RUA-adressen kan ligge på et andet domæne, men modtagerne kan kræve en særlig DNS-record, der godkender ekstern rapportering. Uden den kan rapporterne udeblive, selv om mailadressen virker. Følg rapporttjenestens præcise vejledning.

Når politikken ændres, bør dato, ansvarlig og begrundelse registreres. Hvis levering senere falder, kan teamet se, om ændringen faldt sammen med skiftet fra none til quarantine eller reject. DNS-historik er sjældent synlig i de almindelige administrationspaneler.

En DMARC-rapport kan vise store mængder legitim mail fra cloududbydere, fordi mange kunder deler IP-rum. Identifikationen bør bygge på DKIM-domæner, SPF-domæner, kendte leverandører og test, ikke alene på reverse DNS eller et IP-navn.

Start med at identificere alle legitime afsendere og få SPF eller DKIM til at alignere med From-domænet. Først derefter giver det mening at stramme politikken. En hurtig overgang til reject kan stoppe svindel, men også blokere ordrebekræftelser, fakturaer eller nyhedsbreve fra systemer, der aldrig blev registreret.

DMARC bør betragtes som en løbende driftsopgave. Nye systemer, skift af mailleverandør og organisatoriske ændringer kan skabe nye afsendere. En kvartalsvis gennemgang af rapporter og leverandørliste er ofte mere værdifuld end at opsætte en streng politik én gang og derefter glemme den.

For subdomæner kan en særskilt sp-politik bruges, men det kræver overblik over, hvilke tjenester der sender fra hvert niveau. En streng hovedpolitik bør ikke kopieres ukritisk til alle subdomæner. Omvendt kan et glemt subdomæne blive et smuthul, hvis det kan misbruges uden samme kontrol som hoveddomænet.

Vi hjælper med de tekniske afhængigheder omkring hjemmesider og webshops, så formularer og systemmails ikke glemmes. Vores artikel om HTTP og HTTPS, giver en jordnær introduktion til, hvordan flere sikkerhedsstandarder arbejder på forskellige dele af løsningen.