E-mail blev designet uden en måde at bevise hvem der har sendt en besked. DMARC er dit domænes vej til det bevis — og din vej til at finde ud af hvem der allerede sender mail i dit navn.
Problemet: hvem som helst kan sende e-mail som dit domæne
SMTP — protokollen der flytter e-mail rundt på internettet — verificerer ikke afsenderens adresse. En besked bærer faktisk to "fra"-adresser: envelope-afsenderen, som mailservere bruger til at route bounces, og header-From — adressen dine modtagere ser i deres mailklient. Intet i selve SMTP forhindrer en fremmed i at sætte invoicing@example.com i det synlige From-felt og sende beskeden fra en server på den anden side af kloden.
Det kaldes exact-domain spoofing, og det er dét der gør fakturasvindel og falske direktørmails så overbevisende: beskeden viser reelt dit domæne. Modtagerne kan ikke bebrejdes at de stoler på den — adressen ser fuldstændig ægte ud, for det er din rigtige adresse, brugt uden tilladelse.
SPF og DKIM kort fortalt
Der findes to DNS-baserede mekanismer der lader modtagende servere tjekke hvor mail reelt kom fra:
- SPF (Sender Policy Framework) er en offentliggjort liste over de servere der må sende mail for dit domæne. En modtagende server slår listen op og tjekker om den server der ringer på, står på den.
- DKIM (DomainKeys Identified Mail) er en kryptografisk signatur på hver besked. Den modtagende server henter din offentlige nøgle i DNS og verificerer at beskeden er signeret af nogen med din private nøgle — og ikke er blevet ændret undervejs.
Begge er nødvendige, og vores praktiske SPF- og DKIM-opsætningsguide gennemgår konfigurationen. Men alene har de en blind vinkel: ingen af dem er forpligtet til at matche den From-adresse dine modtagere faktisk ser. SPF tjekker envelope-afsenderens domæne; DKIM validerer det domæne der har signeret beskeden — uanset hvilket. En spoofet e-mail kan bestå begge tjek — med angriberens eget domæne — og stadig vise dit i From-feltet.
Løsningen på den blinde vinkel hedder alignment: et krav om at det domæne der bestod SPF eller DKIM, matcher domænet i den synlige From-header. Alignment er præcis det, DMARC tilføjer.
Hvad DMARC gør
DMARC (Domain-based Message Authentication, Reporting and Conformance) er en DNS TXT-record offentliggjort på _dmarc.example.com. En minimal record ser sådan ud:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comDen gør tre ting:
- Binder autentificeringen til den synlige From. En besked består kun DMARC hvis den består SPF eller DKIM med alignment — det beståede domæne skal matche det From-domæne modtagerne ser.
- Fortæller modtagerne hvad de skal gøre ved fejl.
p=-politikken instruerer modtagende servere i at gøre ingenting (none), sende fejlende mail i spam (quarantine) eller afvise den helt (reject). - Sender dig rapporter.
rua=-adressen modtager aggregerede rapporter fra mailudbydere, som beskriver hver eneste kilde der har sendt mail i dit domænes navn.
Udrulningsrejsen: none, quarantine, reject
Ingen bør offentliggøre p=reject fra dag ét. Den sikre rejse har tre etaper:
- p=none — observér. Intet ændres for mail-leveringen. Du indsamler aggregerede rapporter og danner dig et billede af hvert system der sender som dit domæne: din mailudbyder, men også nyhedsbrevsplatformen, CRM'et, faktureringsværktøjet og den ene server ingen kunne huske.
- p=quarantine — håndhæv blidt. Når hver legitim afsender består SPF eller DKIM med alignment, begynder fejlende mail at ryge i spam-mappen.
pct=-tagget lader dig anvende politikken på en procentdel af trafikken først, så du kan skrue gradvist op. - p=reject — håndhæv fuldt. Fejlende mail afvises før den overhovedet når en indbakke. Det er destinationen: spoofet mail med dit præcise domæne bliver ganske enkelt ikke længere leveret af de deltagende udbydere.
Rejsen gennem etaperne tager typisk uger, ikke timer — tiden går med at finde legitime afsendere du ikke kendte til, og få deres autentificering på plads inden du strammer politikken.
Hvad aggregerede rapporter (RUA) afslører
Aggregerede rapporter er den undervurderede halvdel af DMARC. Deltagende mailudbydere sender dagligt en XML-fil til din rua=-adresse, som opsummerer den mail de har modtaget med dit domæne i From-feltet: hvilke IP-adresser der sendte den, hvor meget, og om den bestod eller fejlede SPF, DKIM og alignment.
Læst over nogle uger besvarer rapporterne et spørgsmål de fleste organisationer ikke kan besvare i dag: hvem sender e-mail som vores domæne? De typiske opdagelser er en marketingplatform nogen oprettede for år tilbage, et supportværktøj der sender fra sine egne servere, et fejlkonfigureret internt system — og ret ofte ukendte tredjeparter der forsøger at spoofe domænet. Intet af det er synligt på nogen anden måde.
Hagen er at de rå rapporter er maskinlæsbar XML, der ankommer dagligt fra hver udbyder og er tunge at tolke i hånden. Det er en opgave for tooling — ikke for en fredag eftermiddag.
Typiske faldgruber
- At springe direkte til reject. Hvis en legitim afsender endnu ikke er autentificeret, forsvinder dens mail. Start på
p=noneog lad rapporterne bevise at du er klar. - At glemme tredjepartsafsendere. Nyhedsbrevsværktøjer, helpdesks og faktureringssystemer sender alle som dit domæne. Hver af dem skal have SPF eller DKIM konfigureret med dit domæne — ellers fejler de den dag du håndhæver.
- Ingen rua-adresse. En DMARC-record uden rapportering giver dig håndhævelse men ingen synlighed — du ser aldrig hvad politikken blokerer.
- At ignorere subdomæner. Som udgangspunkt gælder din politik også subdomæner, men
sp=-tagget kan tilsidesætte det — og en lempelig subdomæne-politik lader en dør stå åben. - At behandle DMARC som et engangsprojekt. Records bliver redigeret, afsendere kommer til, og en politik der ved et uheld nedgraderes fra reject til none, fjerner i det stille din beskyttelse. DMARC kræver monitoring — ikke bare deployment.
Hvor MailControl passer ind
MailControl overvåger SPF, DKIM, DMARC, MX, BIMI, MTA-STS og TLS-RPT for hvert af dine domæner og indlæser dine aggregerede DMARC-rapporter, så du i stedet for rå XML ser præcis hvem der sender mail som dit domæne — med uautoriserede afsendere markeret. Bliver din beskyttelse på noget tidspunkt svækket, fx en DMARC-politik der nedgraderes, advarer MailControl dig. Der er også en DNS-setup-guide med records klar til at kopiere, så den moderne trio — DMARC, MTA-STS og TLS-RPT — kommer på plads. Vil du se det større billede, så læs use casen e-mail-tillid og leveringsevne.
Stopper DMARC phishing?
DMARC stopper exact-domain spoofing: med en reject-politik bliver mail der sætter dit rigtige domæne i From-feltet men fejler autentificering, afvist af deltagende udbydere. Det stopper ikke lookalike-domæner — en phisher der registrerer et domæne ét tegn fra dit, sender mail der autentificerer korrekt for netop dét lookalike-domæne. Det er et brand-beskyttelsesproblem snarere end et e-mail-autentificeringsproblem.
Hvad gør p=none egentlig?
Ingenting ved mail-leveringen. En p=none-politik er ren monitoring: modtagende servere leverer mail præcis som før, men sender aggregerede rapporter der beskriver hvilke kilder der har sendt mail som dit domæne, og om den bestod autentificeringen. Det er det rigtige udgangspunkt, fordi det giver fuld synlighed uden nogen risiko for at miste legitim mail.
Hvor længe bør et domæne blive på p=none?
Indtil de aggregerede rapporter viser at hver legitim afsender består SPF eller DKIM med alignment — typisk et par uger til et par måneder, afhængigt af hvor mange tredjepartstjenester der sender som domænet. Skifter du til quarantine eller reject før da, lander legitim mail i spam eller forsvinder.
Har jeg brug for DMARC hvis jeg bruger Microsoft 365 eller Google Workspace?
Ja. En hostet e-mail-udbyder autentificerer den mail den sender for dig, men DMARC er en egenskab ved dit domæne, ikke ved din mailbox-udbyder. Uden en DMARC-record får modtagende servere ingen instruks om at afvise spoofet mail med dit domæne, og du modtager ingen rapporter om hvem der sender som dig. De store mailbox-udbydere kræver desuden i stigende grad DMARC af afsendere, så en manglende record kan skade din egen leveringsevne.