Cookies og jeres privatliv

Furesø Data ApS bruger nødvendige cookies, så hjemmesiden virker. Siger I ja, bruger vi også cookies og lignende teknologier til statistik og markedsføring. Så behandler Google og WPMU DEV oplysninger om jeres besøg – fx hvilke sider I ser, jeres enhed og et tilfældigt id – og Google kan bruge dem til egne formål. I kan altid ændre eller trække jeres valg tilbage under "Cookieindstillinger" nederst på siden. Læs cookiepolitikken.
Telefon hverdage 8–1660 70 20 16support@furesoedata.dk
En del afCoworkITFjernsupport
Gratis IT-gennemgang
Mail og domæne

DMARC

En politik i DNS, der kobler SPF og DKIM til den synlige afsender og beder modtagere afvise eller frasortere forfalskede mails.

Også kaldt: Domain-based Message Authentication, Reporting and Conformance, DMARC-politik, DMARC-post

Kort svar

DMARC er en politik, I offentliggør i jeres domænes DNS. Den kræver, at domænet i mailens synlige Fra-adresse passer med et domæne, der har bestået SPF eller DKIM. Samtidig fortæller politikken modtagerne, hvad I ønsker gjort med mails, der fejler: intet (none), frasortere (quarantine) eller afvise (reject). DMARC sender også rapporter, så I kan se, hvem der sender mail i jeres navn.

Fra overvågning til afvisning
  1. p=none og rapporterPolitikken ændrer intet, men rapporterne viser, hvem der sender i jeres navn.
  2. Ret afsenderneSørg for, at alle legitime systemer består SPF eller DKIM med jeres domæne.
  3. p=quarantineMails, der fejler, frasorteres typisk til uønsket post. Hold øje med fejl.
  4. p=rejectMails, der fejler, afvises. Fortsæt med at læse rapporterne løbende.

Det afgørende er sammenfald med Fra-adressen

SPF tjekker konvolutadressen, og DKIM tjekker signaturens domæne. Ingen af dem ser på den Fra-adresse, modtageren faktisk ser. DMARC lukker det hul med kravet om sammenfald (på engelsk alignment): Mindst ét af de to tjek skal bestå med et domæne, der passer med domænet i Fra-adressen.

Som standard er kravet lempeligt: post@firma.dk passer med et SPF- eller DKIM-domæne som bounce.firma.dk, fordi de har samme hoveddomæne. Med streng indstilling skal domænerne være helt ens.

SPFDKIMDMARC
OpgaveGodkender afsenderservereSignerer indholdetKobler til Fra-adressen og giver politik
Ser påKonvolutadressenSignaturens domæne (d=)Den synlige Fra-adresse
Ligger i DNS somTXT på domænetNøgle pr. selectorTXT på _dmarc.domæne
Giver rapporterNejNejJa
Tre mekanismer – tre opgaver

DMARC-posten og politikkerne

Posten er en TXT-post på _dmarc.firma.dk og kan fx se sådan ud: v=DMARC1; p=none; rua=mailto:dmarc@firma.dk. Den vigtigste del er politikken (p):

  • p=none – ingen ønsket handling. Bruges til at overvåge via rapporterne.
  • p=quarantine – mails, der fejler, bør behandles som mistænkelige, typisk lagt i uønsket post eller karantæne.
  • p=reject – mails, der fejler, bør afvises.
  • sp= sætter en særskilt politik for subdomæner. Uden egen DMARC-post er subdomæner dækket af hoveddomænets post.

Godt at vide: Politikken er en anmodning til modtageren, ikke en kommando. Den modtagende mailtjeneste træffer selv den endelige beslutning og kan vælge at afvige. Microsoft 365 følger som udgangspunkt afsenderens quarantine- og reject-politik for indgående mail.

Rapporterne viser, hvem der sender i jeres navn

Med rua= beder I modtagerne om samlede rapporter, typisk én gang i døgnet. Rapporterne er XML-filer med afsenderservernes IP-adresser, antal mails og om SPF og DKIM bestod og passede med domænet. Det er her, I opdager det glemte nyhedsbrevssystem – og forsøg på at sende falske mails i jeres navn.

Rapporterne er tunge at læse i rå form. Lad dem gå til en fælles postkasse eller en rapporteringstjeneste frem for en medarbejders egen indbakke. Ikke alle modtagere sender rapporter, og Microsoft 365 sender kun samlede rapporter, ikke rapporter om enkelte fejl (ruf).

Eksempel: En svindler sender mails med jeres domæne som afsender. Med DMARC sat til reject bliver mailene som udgangspunkt afvist hos de modtagere, der følger politikken, og I kan se forsøgene i rapporterne.

Sådan strammer I op uden at miste legitim mail

Microsoft anbefaler en gradvis indførelse: start med p=none, gennemgå rapporterne, ret de legitime afsendere, gå til p=quarantine og til sidst p=reject. Start gerne med et subdomæne eller et domæne med få afsendere, og tag hoveddomænet til sidst.

Vær opmærksom på mailinglister og automatisk videresendelse: De kan få legitim mail til at fejle DMARC, fordi SPF går i stykker, og DKIM-signaturen kan brydes, hvis indholdet ændres. Derfor bør domæner, der bruger p=reject, altid have DKIM – ikke kun SPF.

Domæner, der slet ikke sender mail, kan med fordel få v=DMARC1; p=reject; med det samme. Det gælder også onmicrosoft.com-domænet, hvis I ikke sender fra det.

Ny standard i 2026

DMARC blev oprindeligt beskrevet i RFC 7489 fra 2015, der kun havde informativ status. I 2026 er den afløst af en egentlig IETF-standard (RFC 9989 med tilhørende rapportstandarder). Posten starter stadig med v=DMARC1, og eksisterende poster virker fortsat. Blandt ændringerne er, at tagget pct (procentvis indfasning) er fjernet, og at der er kommet et test-flag (t).

Krav fra de store mailudbydere

Google og Yahoo kræver, at afsendere med store mængder mail (hos Google over 5.000 mails om dagen til Gmail) har en DMARC-post – mindst p=none – og at Fra-domænet passer med SPF eller DKIM. For de fleste små virksomheder er grænsen langt væk, men en DMARC-post er god praksis uanset.

Spørgsmål I kan stille

  • Har vi en DMARC-post, og hvilken politik står den på?
  • Hvem modtager og læser vores DMARC-rapporter?
  • Består alle vores legitime afsendere SPF eller DKIM med vores eget domæne?
  • Har vi ekstra domæner, der ikke sender mail, men mangler p=reject?
  • Hvornår er vi klar til at gå fra none til quarantine – og hvem tager beslutningen?

Hvornår giver det mening at få hjælp?

Få hjælp, hvis rapporterne er svære at tolke, hvis legitime systemer fejler DMARC, eller når I vil stramme til quarantine eller reject uden at risikere jeres egen mail.

Spørgsmål og svar

Skal vi starte med reject?

Nej. Start med none, se rapporterne, og stram op, når al legitim mail består. Ellers risikerer I, at jeres egne fakturaer eller nyhedsbreve bliver afvist.

Kræver DMARC både SPF og DKIM?

DMARC bygger på dem: En mail består, hvis SPF eller DKIM består med et domæne, der passer med Fra-adressen. I bør have begge, fordi SPF ofte fejler ved videresendelse.

Hvor lang tid tager det at nå til reject?

Det afhænger af, hvor mange systemer der sender mail for jer. Med kun Microsoft 365 kan det gå hurtigt; med flere tjenester tager det typisk nogle uger med rapporter og rettelser.

Forbehold: DMARC gør det markant sværere at sende mails med jeres præcise domæne som afsender, men det er ingen garanti mod svindel: Modtagere kan afvige fra politikken, og falske mails fra domæner, der ligner jeres, er ikke dækket.

Kilder (tjekket 31. oktober 2026)

Relaterede ord

SPFDKIMSpoofingPhishingDNS
Tilbage til IT-ordbogen