SPF, DKIM og DMARC forklaret for virksomheder

Kort svar: SPF angiver i DNS, hvilke servere der må sende mail for jeres domæne. DKIM signerer hver mail kryptografisk, så modtageren kan se, at den kommer fra jer og ikke er ændret. DMARC binder de to sammen med den synlige afsenderadresse, fortæller modtageren, hvad der skal ske med mails, der fejler, og sender jer rapporter. I har brug for alle tre, og de skal dække alle systemer, der sender fra domænet.

Fagligt gennemgået: 2. oktober 2026

Når en virksomhed sender e-mails fra sit eget domæne, er det ikke nok, at beskeden ser rigtig ud i indbakken. Modtagerens mailserver vurderer også, om afsenderen faktisk har ret til at sende på vegne af domænet. Det er her, SPF, DKIM og DMARC kommer ind.

De tre mekanismer er blevet en fast del af moderne e-maildrift, fordi de hjælper med at stoppe spoofing og phishing, og fordi store mailudbydere kræver korrekt autentificering. For virksomheder handler det om sikkerhed, troværdighed og leveringsgrad.

Hvorfor SPF, DKIM og DMARC er vigtige for virksomheders e-mail

Mange tænker på e-mail som et simpelt værktøj til dialog med kunder, leverandører og kolleger. Men for mailudbyderne er e-mail et område med massivt misbrug. Kan en angriber sende beskeder, der ligner noget fra jeres domæne, kan det skade både brand og relationer på meget kort tid.

SPF, DKIM og DMARC gør det sværere at forfalske afsenderen. Samtidig giver de modtagersystemerne bedre mulighed for at skelne legitim forretningsmail fra svindel. Det er en praktisk fordel, ikke kun en teknisk detalje.

Siden februar 2024 har Google krævet, at alle afsendere til Gmail bruger SPF eller DKIM, og afsendere af store mængder mail skal have både SPF, DKIM og en DMARC-politik. Microsoft beskriver på samme måde SPF, DKIM og DMARC som byggesten, der bør bruges samlet for effektiv e-mail-autentificering.

Er jeres mails ikke autentificeret korrekt, kan de ende i spam, blive markeret som mistænkelige eller blive afvist helt. Se også Gmail afviser din mail.

Hvad SPF, DKIM og DMARC betyder i praksis

Selvom termerne ofte nævnes samlet, løser de ikke den samme opgave. De arbejder sammen, men hver mekanisme ser på forskellige dele af en mail og en afsenders opsætning.

Mekanisme	Hvad den kontrollerer	Hvor den sættes op	Hvad den hjælper med
SPF	Om en server må sende mail for et domæne	DNS som TXT-record	Reducerer misbrug fra uautoriserede afsenderservere
DKIM	Om mailen er signeret og ikke ændret undervejs	DNS med offentlig nøgle og signering på afsendersystemet	Giver modtageren en kryptografisk kontrol af beskeden
DMARC	Om SPF og/eller DKIM består med korrekt alignment, og hvad der skal ske ved fejl	DNS som TXT-record	Styrer politik, rapportering og beskyttelse mod spoofing

SPF står for Sender Policy Framework. Her angiver du i DNS, hvilke servere eller tjenester der må sende mail på vegne af domænet. Det er en liste over godkendte afsendere. Når en modtager får en mail, kan systemet kontrollere, om afsenderserveren passer til domænets SPF-record.

SPF har dog en begrænsning: den ser ikke på det synlige afsenderfelt, som brugeren læser i mailklienten. Den arbejder med det tekniske MAIL FROM-domæne (også kaldet envelope sender eller Return-Path). Derfor kan SPF godt bestå teknisk, uden at det giver den beskyttelse, virksomheden forventer i forhold til det synlige afsenderdomæne.

DKIM står for DomainKeys Identified Mail. Her bliver mailen signeret af afsendersystemet med en privat nøgle, mens den offentlige nøgle ligger i DNS. Når modtageren tjekker signaturen, kan systemet se, om beskeden kommer fra en godkendt kilde, og om indholdet er blevet ændret undervejs.

DMARC står for Domain-based Message Authentication, Reporting and Conformance. Det bygger oven på SPF og DKIM. DMARC fortæller modtageren, hvordan beskeder skal behandles, hvis autentificeringen ikke består, og det tilføjer kravet om, at domænerne skal passe sammen.

Sådan ser de tre records ud

Det bliver lettere at forstå, når du ser selve DNS-posterne. Her er typiske eksempler for domænet firma.dk. Tilpas dem altid til jeres egne afsendere.

firma.dk.                        TXT  "v=spf1 mx include:_spf.eksempel-nyhedsbrev.dk -all"
selector1._domainkey.firma.dk.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.firma.dk.                 TXT  "v=DMARC1; p=none; rua=mailto:dmarc@firma.dk"

SPF: mx betyder, at domænets egne mailservere må sende, og include henter en anden tjenestes liste ind. Afslutningen -all (hard fail) siger, at alle andre afsendere skal afvises, mens ~all (soft fail) beder modtageren om at behandle dem som mistænkelige. Der må kun være én SPF-record pr. domæne, og den må højst udløse 10 DNS-opslag. Hver include tæller med, og mange tjenester bruger selv flere opslag. Overskrides grænsen, fejler SPF (se SPF-fejlen too many DNS lookups).

DKIM: nøglen ligger under et selector-navn, som afsendersystemet bestemmer, fx selector1 eller google. Hver tjeneste, der sender for jer, har typisk sin egen selector, så I kan have flere DKIM-records side om side. Brug nøgler på 2048 bit, hvor det er muligt.

DMARC: de vigtigste tags er:

• p: politikken for domænet: none, quarantine eller reject
• sp: politikken for underdomæner, hvis den skal være en anden
• rua: adressen, der skal modtage de samlede rapporter
• pct: hvor stor en procentdel af mailene politikken gælder for, nyttigt ved gradvis stramning
• adkim og aspf: om alignment skal være streng (s) eller afslappet (r, standard)

DMARC alignment, From-header og MAIL FROM forklaret

Her opstår den del, som mange virksomheder overser: alignment.

DMARC ser ikke kun på, om SPF eller DKIM isoleret set består. Den ser også på, om det domæne, brugeren kan se i From-feltet, matcher det domæne, der bruges i SPF eller DKIM. Det kaldes DMARC alignment.

From-domænet er det, jeres kunde opfatter som afsenderen. Ser en mail ud til at komme fra firma.dk, men SPF validerer et helt andet domæne, eller DKIM signerer med et andet domæne uden alignment, fejler DMARC. Det gælder også, selvom de enkelte checks isoleret set ser acceptable ud.

Det er netop derfor, DMARC giver mere reel beskyttelse mod spoofing end SPF alene.

En enkel tommelfingerregel: Sender jeres medarbejdere, webshop, kontaktformular og nyhedsbrev alle fra samme domæne udadtil, skal SPF og/eller DKIM være sat op, så det samme domæne kan valideres i DMARC. For tredjepartstjenester betyder det typisk, at I skal opsætte DKIM med jeres eget domæne i tjenesten, ikke nøjes med tjenestens standarddomæne.

Typiske fejl i SPF, DKIM og DMARC hos virksomheder

Mange problemer opstår ikke, fordi virksomheden mangler vilje, men fordi mailflowet er mere sammensat, end man tror. Det gælder især, når der både bruges almindelig e-mail, CRM, økonomisystem, nyhedsbrevstjeneste, supportplatform og formularer på hjemmesiden.

En anden klassiker er, at domænet er flyttet, men at gamle DNS-records stadig ligger og skaber konflikt.

De mest almindelige fejl ser sådan ud:

• SPF-records med glemte afsendertjenester
• Flere SPF-records på samme domæne
• SPF med for mange include og dermed over 10 DNS-opslag
• DKIM slået til i tjenesten, men uden korrekt DNS-nøgle
• DMARC oprettet uden reel overvågning af rapporterne
• From-domæne, MAIL FROM og DKIM-domæne matcher ikke godt nok

Et særligt punkt er SPF-politikken. En for blød opsætning gør det sværere at håndhæve, hvem der må sende. En for hård opsætning, før alt er kortlagt, kan stoppe legitim mail. Derfor bør ændringer ske kontrolleret.

Sådan arbejder virksomheder sikkert med DNS-records for SPF, DKIM og DMARC

SPF, DKIM og DMARC sættes op som DNS-records, typisk som TXT-records. Det lyder enkelt, men fejl i DNS kan påvirke leveringen af forretningskritiske mails. Derfor bør ændringer planlægges, dokumenteres og testes.

Bruges domænet bredt i organisationen, er det en god idé, at én teknisk ansvarlig står for ændringerne. Har virksomheden ikke den kompetence internt, bør opgaven lægges hos en driftspartner med erfaring i e-mail og DNS.

En praktisk proces ser ofte sådan ud:

1. Kortlæg alle legitime afsendere fra domænet.
2. Saml eksisterende SPF-, DKIM- og DMARC-records, og gennemgå dem for overlap.
3. Aktivér DKIM hos hver relevant mailtjeneste, og læg de tilhørende DNS-records ind korrekt.
4. Start DMARC med p=none, så rapporterne kan læses, før politikken strammes.
5. Overvåg levering, fejlmeldinger og rapportdata, før der skiftes til en skarpere politik.

Der er især tre forhold, som bør være på plads, før du strammer DMARC-politikken:

• Kortlægning: alle systemer, der sender som jeres domæne, skal være kendt.
• Validering: SPF og DKIM skal testes mod rigtige mails, ikke kun mod DNS-opslag.
• Ansvar: én person eller partner bør eje opsætningen og ændringshistorikken.

Er I i tvivl, så undgå at ændre records direkte i produktion midt i travle perioder. Selv små tastefejl kan få stor effekt. Sænk gerne TTL før en større ændring, så en fejl kan rettes hurtigt.

SPF, DKIM og DMARC i WordPress, WooCommerce og e-mail-hosting

Virksomheder med WordPress-hosting eller WooCommerce-hosting møder ofte et ekstra lag af kompleksitet. Hjemmesiden eller webshoppen kan sende transaktionsmails, kontaktformularer, ordrebekræftelser og systemnotifikationer, mens medarbejdernes almindelige mail kører via en anden tjeneste. Autentificeringen skal derfor tænkes samlet.

Skeln mellem ydelserne. WordPress-hosting og WooCommerce-hosting er ikke det samme som email hosting. En webshop kan godt være hostet ét sted, mens virksomhedens maildrift ligger et andet sted. SPF, DKIM og DMARC skal afspejle den faktiske afsenderstruktur, ikke bare placeringen af hjemmesiden.

Sender en WooCommerce-shop ordremails via en ekstern SMTP-tjeneste, skal den tjeneste være godkendt korrekt. Sender kontaktformularer som virksomhedens hoveddomæne, skal det domæne kunne bestå SPF eller DKIM med alignment. Ellers ser kunden en afsender, der virker rigtig, men som modtagersystemet ikke stoler på. Fejlfindingen står i mails fra WordPress ryger i spam.

Det giver mening at tænke i disse spor:

• Medarbejdermail: almindelig korrespondance fra email hosting
• Systemmail: formularer, notifikationer og WordPress-baserede beskeder
• Transaktionsmail: ordrebekræftelser, kvitteringer og kundebeskeder fra webshop
• Kampagnemail: nyhedsbreve og automatiserede flows fra en ekstern platform

Samler du drift og sparring ét sted, bliver det som regel lettere at holde styr på ændringerne. Hostious tilbyder email hosting, WordPress-hosting og WooCommerce-hosting med dansk support døgnet rundt og gratis migrering af WordPress-sites, så det er lettere at få overblik over, hvilke systemer der faktisk sender på vegne af domænet.

Hvad DMARC-politikker betyder for levering og beskyttelse

DMARC bruges ikke kun til kontrol. Det bruges også til at fortælle modtagerne, hvordan de bør reagere, hvis en mail fejler autentificeringen. Derfor omtales DMARC ofte som det lag, der giver styring.

I praksis arbejdes der med tre niveauer:

• p=none: kun overvågning og rapportering
• p=quarantine: mails, der fejler, behandles mere restriktivt, typisk lagt i spam
• p=reject: mails, der fejler, afvises

Det kan være fristende at gå direkte til en stram politik, men det er sjældent det rigtige første skridt. Har virksomheden endnu ikke fuldt overblik over alle afsendere, kan legitim mail blive ramt. En gradvis indfasning er som regel den mest robuste vej, fx med pct=25 på quarantine, før den hæves til 100 og til sidst reject. Se også spoofing og DMARC-stramning.

Google har gjort det tydeligt, at uautentificerede mails kan blive markeret som spam eller afvist, og i nogle tilfælde ses fejlkoden 5.7.26. Det er et konkret tegn på, at autentificering ikke længere kan udsættes.

Hvad virksomheder bør overvåge efter opsætning af SPF, DKIM og DMARC

Når records er på plads, starter den løbende drift. E-mailmiljøer står sjældent stille. Nye systemer kommer til, gamle tjenester bliver ikke altid udfaset pænt, og medarbejdere tager nye værktøjer i brug.

Derfor bør virksomheden løbende følge med i, om legitime mails består SPF, DKIM og DMARC, og om der dukker ukendte afsendere op i rapporteringen. DMARC-rapporterne kommer som XML-filer, som er tunge at læse direkte, så brug et værktøj, der samler dem i et overblik.

Hold især øje med:

• Nye afsendere: marketingværktøjer, CRM eller supportplatforme
• Fejlmønstre: mange DMARC-fejl fra samme kilde kan pege på forkert opsætning (se DMARC-rapporten siger fail)
• Domænekonsistens: From-domænet skal fortsat passe med SPF eller DKIM
• Ændringer i drift: flytning af mail, hjemmeside eller webshop kræver ofte justeringer

For mange virksomheder er målet ikke at blive eksperter i mailstandarder. Målet er at sende troværdige mails, beskytte domænet og undgå unødige leveringsproblemer. SPF, DKIM og DMARC er vejen dertil, når de bliver sat op som et samlet system frem for tre enkeltstående punkter på en teknisk tjekliste.

Læs også

• Hub: Mail: fejl og fejlfinding – alle guides om emnet samlet ét sted
• SPF-fejlen „too many DNS lookups“ – tæl og slank din record
• Nogen sender mails fra dit domæne: spoofing og DMARC-stramning
• Mailserver til virksomheder med høj sikkerhed
• Email hosting hos Hostious – erhvervsmail uden begrænsning på antal postkasser

Ofte stillede spørgsmål om SPF, DKIM og DMARC

Behøver vi alle tre – SPF, DKIM og DMARC?

Ja. SPF siger, hvem der må sende, DKIM beviser, at indholdet er ægte, og DMARC fortæller modtagerne, hvad de skal gøre ved fejl, og rapporterer misbrug. Sammen beskytter de både levering og domæne.

Hvilken DMARC-politik skal vi starte med?

Start med p=none, og læs rapporterne, til alle legitime afsendere er på plads i SPF og DKIM. Skærp derefter til quarantine og til sidst reject. I den rækkefølge undgår I at blokere jeres egne mails.

Hvordan tester vi, om vores opsætning virker?

Send en mail til et testværktøj som mail-tester eller learndmarc, og læs SPF-, DKIM- og alignment-resultaterne. Test igen efter hver ændring, og når I tilføjer nye afsendersystemer.

Hvorfor fejler SPF, når mails bliver videresendt?

Ved videresendelse sendes mailen videre fra en anden server, som ikke står i jeres SPF-record. DKIM-signaturen overlever derimod normalt videresendelse, så længe indholdet ikke ændres. Derfor er DKIM vigtig for, at DMARC kan bestå.