Tre forkortelser, ét formål: at bevise over for modtagerens mailserver, at en e-mail sendt fra dit domæne faktisk er ægte. SPF, DKIM og DMARC er ikke tre separate sikkerhedsprojekter - de er tre lag i det samme forsvar, og de virker kun optimalt, når alle tre er på plads og konfigureret til at arbejde sammen.
Mange virksomheder har én af dem. Færre har to. Og dem, der har alle tre korrekt sat op, er dem, hvis mails konsekvent lander i indbakken frem for spammappen - og hvis domæner er markant sværere at misbruge til phishing.
Problemet: E-mail er designet til at blive forfalsket
SMTP - protokollen der sender e-mail - blev designet i en tid, hvor internet-tillid var en selvfølge. Der er ingen mekanisme i selve protokollen der verificerer, om afsenderen er den, de udgiver sig for at være. Det betyder, at hvem som helst teknisk set kan sende en e-mail med From: din-chef@ditdomæne.dk uden at eje domænet.
Det er præcis det, angribere gør ved e-mailspoofing og phishing. De udgiver sig for at være kendte domæner - din bank, din leverandør, din virksomhed - for at narre modtagere til at klikke på links eller overføre penge. Og selv uden ondsindede hensigter kan et forkert konfigureret domæne få legitime mails afvist af spamfiltre, fordi modtagerens server ikke kan verificere afsenderens identitet.
SPF, DKIM og DMARC løser dette problem - men på tre fundamentalt forskellige måder, der supplerer hinanden.
SPF: Hvem må sende på dine vegne?
SPF (Sender Policy Framework) er en DNS-record af typen TXT, der fortæller verden, hvilke mailservere der er autoriseret til at sende e-mail på vegne af dit domæne. Modtagerens mailserver slår din SPF-record op og kontrollerer, om den afsendende servers IP-adresse er på listen.
En typisk SPF-record ser sådan ud:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~allHer erklæres det, at Microsoft 365 og SendGrid må sende på vegne af domænet. Tilsvarende servere, der ikke er nævnt, vil fejle SPF-tjekket. Tagget ~all (softfail) betyder, at uautoriserede afsendere markeres som mistænkelige, mens -all (hardfail) aktivt afviser dem.
Hvad SPF ikke gør: SPF validerer kun den tekniske afsender-IP - den såkaldte "envelope from" eller Return-Path. Det er ikke den adresse, modtageren ser i sit mailprogram. En angriber kan sagtens sende fra et autoriseret domæne i Return-Path og stadig vise et falsk "From"-felt til modtageren. Det er her DKIM og DMARC træder til.
Du kan dykke dybere ned i SPF-recordens opbygning og faldgruber i artiklen Sådan fungerer SPF-records, og hvorfor de er vigtige for din e-mail-sikkerhed. Har du brug for at bygge eller rette din SPF-record, kan SPF-generatoren på DNSinfo guide dig igennem processen.
DKIM: Et digitalt fingeraftryk på hver mail
DKIM (DomainKeys Identified Mail) fungerer anderledes end SPF. I stedet for at kontrollere afsender-IP'en tilføjer DKIM en kryptografisk signatur til selve e-mailens header. Signaturen genereres med en privat nøgle på afsenderens mailserver og kan verificeres af modtageren ved hjælp af en tilhørende offentlig nøgle, der er publiceret som en TXT-record i dit domænes DNS.
DKIM-signaturen beskytter en del af mailens indhold - typisk headere og body - mod manipulation undervejs. Selv hvis mailen passerer gennem flere mailservere, kan modtagerens server kontrollere, at indholdet ikke er blevet ændret siden afsendelse.
Den offentlige nøgle publiceres typisk på en adresse som:
selector._domainkey.ditdomæne.dk IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."Hvad DKIM ikke gør: DKIM bekræfter, at mailen kom fra en server med adgang til den private nøgle - men det siger ikke i sig selv noget om, hvem der kontrollerer den server. En angriber, der har kompromitteret en mailserver med en gyldig DKIM-nøgle, kan stadig sende signerede mails. DKIM er heller ikke en erstatning for SPF - de to protokoller validerer forskellige aspekter af en mail.
En uddybende gennemgang af DKIM-mekanismen og dens rolle i leveringssikkerhed finder du i artiklen Hvad er DKIM, og hvorfor er det afgørende for din e-mailleveringssikkerhed?
DMARC: Bindeledet der giver SPF og DKIM autoritet
DMARC (Domain-based Message Authentication, Reporting and Conformance) er det tredje og afgørende lag. Alene løser SPF og DKIM hvert sit problem - men ingen af dem fortæller modtagerens mailserver, hvad den skal gøre, hvis tjekket fejler. Det gør DMARC.
DMARC tilføjer to ting: alignment og policy.
Alignment betyder, at DMARC kræver, at enten SPF eller DKIM - eller begge - er i overensstemmelse med det domæne, der vises i mailens "From"-felt. Det er det afgørende skridt, der lukker hullet fra SPF's begrænsning: nu skal den verificerede identitet matche det, modtageren faktisk ser.
Policy bestemmer, hvad der skal ske med mails, der fejler DMARC-tjekket. En DMARC-record ser typisk sådan ud:
v=DMARC1; p=quarantine; rua=mailto:dmarc-rapporter@ditdomæne.dk; pct=100Her angiver p=quarantine, at mails der fejler DMARC, skal sendes i karantæne (typisk spammappen). Alternativerne er p=none (overvågningstilstand - ingen handling, men rapporter sendes) og p=reject (mailen afvises fuldstændigt). rua-parameteren angiver en adresse, hvor aggregerede rapporter om dit domænes mailstrøm sendes hen.
Rapporterne er guld: de viser præcis, hvilke servere der sender mail på vegne af dit domæne, og om de består SPF og DKIM. Det er de data, du bruger til at justere din konfiguration, inden du skruer politikken op fra none til reject.
Den fulde trin-for-trin-proces fra nul til reject er beskrevet i detaljer i DMARC fra nul til reject: Den komplette trin-for-trin guide. Vil du oprette en DMARC-record hurtigt, kan du bruge DMARC-generatoren på DNSinfo.
Sådan virker de tre protokoller sammen: et mail-flow fra afsendelse til indbakke
For at forstå samspillet er det nyttigt at følge en e-mail fra den forlader din mailserver, til den lander hos modtageren.
Din mailserver sender en e-mail til modtager@eksempel.dk. Modtagerens mailserver modtager forbindelsen og starter autentificeringen:
SPF-tjek: Modtagerens server slår din SPF-record op i DNS og kontrollerer, om den IP-adresse forbindelsen kom fra, er autoriseret til at sende for dit domæne. Resultat: pass eller fail.
DKIM-tjek: Modtagerens server finder DKIM-signaturen i mailens header, slår den tilhørende offentlige nøgle op i DNS og verificerer signaturen mod mailens indhold. Resultat: pass eller fail.
DMARC-tjek: Modtagerens server slår din DMARC-record op. Den kontrollerer, om mindst ét af de to tjek - SPF eller DKIM - er bestået og i alignment med domænet i "From"-feltet. Baseret på din policy afgør den derefter, om mailen skal leveres, sættes i karantæne eller afvises.
Hele processen foregår på millisekunder og er fuldstændig usynlig for både afsender og modtager. Men resultatet er synligt: mails der består alle tre tjek, leveres med langt højere pålidelighed og undgår spamfiltre, der ellers afviser uverificerede afsendere.
Hvad der sker, hvis ét led mangler
Mangler SPF, kan modtagerens server ikke vide, om din mailserver er autoriseret. Mails vil ofte ende i spam eller afvises af strenge filtre - særligt hos store udbydere som Google og Microsoft, der har skærpet kravene til afsenderautentificering - Google fra februar 2024 og Microsoft fra maj 2025.
Mangler DKIM, mister du den kryptografiske binding mellem mailen og dit domæne. Mails kan manipuleres undervejs uden at nogen opdager det, og DMARC-alignment via DKIM er umulig. Du er afhængig af SPF alene - og SPF alene er ikke nok til DMARC-alignment i mange mail-setups, særligt ikke ved videresendelse.
Mangler DMARC - eller er den sat til p=none - er der ingen konsekvenser for angribere der forfalsker dit domæne. SPF og DKIM beskytter stadig noget, men der er ingen instruks til modtagende servere om at afvise forfalskede mails. Dit domæne kan frit bruges til phishingkampagner, og du får ingen rapporter om det.
Mangler alle tre, er dit domæne i praksis åbent for spoofing. Angribere kan sende mails der ser ud til at komme fra dig, og modtagerens server har ingen teknisk mekanisme til at skelne dem fra dine legitime mails.
Blacklisting er en anden konsekvens af manglende autentificering. Læs mere om, hvad du gør, hvis dit domæne eller din IP er havnet på en sortliste, i artiklen Sådan håndterer du mailblokering og blacklist-problemer.
Verificér din opsætning
Konfiguration er én ting - verifikation er en anden. En record kan se korrekt ud i dit DNS-panel og alligevel have syntaksfejl, overlappende mekanismer eller manglende includes. Brug disse trin til at bekræfte, at din opsætning er korrekt:
Kontrollér SPF-recorden: Brug SPF-analysen på DNSinfo til at validere din SPF-record. Værktøjet tjekker syntaks, tæller DNS-opslag (maks. 10 er tilladt) og markerer potentielle fejl.
Kontrollér DKIM-recorden: Brug DNS-opslag på DNSinfo til at slå din DKIM-records TXT-indhold op. Søg på
selector._domainkey.ditdomæne.dkmed record-typen TXT og bekræft, at nøglen er publiceret korrekt.Kontrollér DMARC-recorden: Slå
_dmarc.ditdomæne.dkop som TXT-record via DNS-opslag og verificér, at policy, alignment-indstillinger og rapportadresse er korrekte.Tjek for blacklisting: Selv korrekt konfigurerede domæner kan ende på sortlister. Blacklist check på DNSinfo giver et hurtigt overblik over, om dit domæne eller din afsender-IP er markeret.
E-mailsikkerhed er tre records i din DNS-zone
SPF fortæller verden, hvilke servere der må sende for dit domæne. DKIM beviser, at mailen ikke er blevet manipuleret undervejs. DMARC binder de to sammen, kræver alignment med det synlige afsenderdomæne og giver dig instruktionsbeføjelse over, hvad der sker med mails der fejler.
Tilsammen udgør de det fundament, som moderne e-mailleveringssikkerhed er bygget på. Og fundamentet er ikke mere kompliceret end tre TXT-records i din DNS-zone - sat op én gang, verificeret med de rette værktøjer og derefter i stand til at beskytte dit domænes omdømme og dine modtageres tillid år efter år.
