Når en kunde skriver "jeg har ikke fået jeres tilbud", er det sjældent fordi mailen aldrig blev sendt. Den er landet i spam, eller den er blevet afvist undervejs. Meget ofte er årsagen tre små tekstposter i domænets DNS, som enten mangler eller er sat forkert op: SPF, DKIM og DMARC.
De tre poster lyder tekniske, men ideen bag dem er enkel. De lader den modtagende mailserver tjekke, om en mail fra firma.dk faktisk kommer fra firma.dk. Her forklarer jeg, hvad hver af dem gør, hvad de store mailudbydere kræver i dag, og hvordan I får dem sat op uden at stoppe jeres egne mails. Alle krav er linket til kilden, og kilderne er samlet nederst.
Kort fortalt
- SPF er en liste over de servere, der må sende mail fra jeres domæne (RFC 7208).
- DKIM er en digital signatur på hver mail, som modtageren tjekker mod en nøgle i jeres DNS (RFC 6376).
- DMARC fortæller modtageren, hvad den skal gøre med mails, der ikke består, og sender rapporter til jer (RFC 9989).
- Gmail og Yahoo kræver SPF eller DKIM af alle afsendere og alle tre af dem, der sender mange mails (Gmail Hjælp, Yahoo Sender Hub).
- Outlook.com afviser siden 5. maj 2025 mails fra domæner, der sender over 5.000 mails om dagen uden at leve op til kravene (Microsoft).
- Styrelsen for Samfundssikkerhed anbefaler DMARC med en reject-politik på alle domæner, også dem, I ikke sender mail fra (Styrelsen for Samfundssikkerhed).
Hvorfor det overhovedet er et problem
Afsenderen i en mail er bare tekst, og alle kan skrive firma.dk i feltet. Derfor kan en svindler sende en falsk faktura, der ser ud til at komme fra jer, og derfor er de store mailudbydere blevet mistænksomme over for mails, de ikke kan bekræfte. SPF, DKIM og DMARC er de tre måder, en modtager kan bekræfte afsenderen på. De ligger som TXT-poster i jeres DNS, og derfor bliver de ofte glemt.
SPF: hvem må sende
SPF står for Sender Policy Framework. Posten er en liste over de servere, der har lov til at sende mail fra jeres domæne. Når en mail kommer frem, slår modtageren posten op og ser, om den afsendende server står på listen (RFC 7208).
En SPF-post for firma.dk, der sender via Microsoft 365 og et nyhedsbrevsværktøj, kan se sådan ud:
firma.dk TXT "v=spf1 include:spf.protection.outlook.com include:nyhedsbrev.example -all"Hver include peger på en tjenestes egen liste. Microsoft 365 bruger include:spf.protection.outlook.com (Microsoft Learn), mens nyhedsbrev.example kun er et eksempel; den rigtige værdi står i værktøjets vejledning. Det sidste led bestemmer, hvad der sker med alle andre. Med -all siger I, at alle andre servere ikke har lov (fail). Med ~all siger I det mere forsigtigt: de har sandsynligvis ikke lov (softfail) (RFC 7208).
To regler fra standarden giver flest fejl i praksis:
- Kun én SPF-post pr. domæne. Har domænet flere, giver tjekket en permanent fejl (RFC 7208, afsnit 3.2). Det sker typisk, når en ny tjeneste beder jer "tilføje en SPF-post", og nogen opretter en ekstra i stedet for at rette den eksisterende.
- Højst 10 opslag. Hver
include,aogmxkoster et DNS-opslag, og de tjenester, I inkluderer, kan selv have flere. Bliver det mere end 10 i alt, giver tjekket også en permanent fejl (RFC 7208, afsnit 4.6.4).
SPF har en svaghed. Den tjekker den server, der afleverer mailen, og ikke nødvendigvis det navn, modtageren ser i afsenderfeltet. Det er det hul, DMARC lukker.
DKIM: en signatur på hver mail
DKIM står for DomainKeys Identified Mail. Her signerer den afsendende server hver mail med en hemmelig nøgle. Den offentlige del af nøglen ligger i jeres DNS, så modtageren kan tjekke, at signaturen passer, og at mailen ikke er ændret undervejs (RFC 6376).
Nøglen ligger under et navn, der hedder en selector, efterfulgt af _domainkey (RFC 6376). For firma.dk kan det se sådan ud, her forkortet:
selector1._domainkey.firma.dk TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"I skriver ikke nøglen selv. Den kommer fra den tjeneste, der sender mailen. Microsoft 365, Google Workspace og de fleste nyhedsbrevsværktøjer har en side, hvor I slår DKIM til og får de poster, der skal i DNS. Det vigtige er, at det skal gøres for hver tjeneste, der sender i jeres navn, og ikke kun for den almindelige mail.
DMARC: hvad modtageren skal gøre
DMARC står for Domain-based Message Authentication, Reporting and Conformance. Posten ligger på _dmarc foran jeres domæne og gør to ting: Den fortæller modtageren, hvad den skal gøre med mails, der fejler, og den beder om rapporter (RFC 9989). Standarden blev opdateret i maj 2026, hvor RFC 9989 afløste RFC 7489. Det er den nye, jeg henviser til her.
_dmarc.firma.dk TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.dk"Politikken p har tre trin (RFC 9989):
- none: I beder modtageren om ikke at gøre noget særligt. I får bare rapporter.
- quarantine: Mails, der fejler, skal behandles som mistænkelige. I praksis havner de typisk i spam.
- reject: Mails, der fejler, skal afvises.
rua er den adresse, de samlede rapporter sendes til. De fortæller, hvilke servere der har sendt mail i jeres navn, og om de bestod. Rapporterne kommer som XML-filer, som ikke er til at læse med det blotte øje, og Styrelsen for Samfundssikkerhed nævner selv, at der findes værktøjer, der behandler dem automatisk (Styrelsen for Samfundssikkerhed).
Alignment: navnet skal passe
Det vigtigste ved DMARC er et ord, der ikke har en god dansk oversættelse: alignment. En mail består kun DMARC, hvis SPF eller DKIM består, og hvis det domæne, de har bekræftet, passer med det domæne, modtageren ser i afsenderfeltet (RFC 9989).
Et eksempel: Jeres nyhedsbrev sendes fra en server hos nyhedsbrevsværktøjet. SPF kan godt bestå, men for værktøjets eget domæne og ikke for firma.dk. Så passer navnene ikke, og mailen fejler DMARC. Løsningen er som regel at slå DKIM til med jeres eget domæne i værktøjet. Det er grunden til, at et setup kan se fint ud i hvert enkelt system og stadig fejle samlet.
Hvad Gmail, Yahoo og Outlook kræver
Gmail. Alle, der sender til private Gmail-adresser, skal have SPF eller DKIM, bruge en krypteret forbindelse (TLS) og holde spamraten i Googles Postmaster Tools under 0,3 procent. Sender I mere end 5.000 mails om dagen til Gmail-adresser, skal I have både SPF, DKIM og DMARC. DMARC-politikken må gerne være none, men domænet i afsenderfeltet skal passe med enten SPF- eller DKIM-domænet, og markedsføringsmails skal have afmelding med ét klik (Gmail Hjælp).
Yahoo. Kravene er næsten de samme og gælder fra februar 2024. Alle afsendere skal have mindst SPF eller DKIM. Store afsendere skal have begge dele og en gyldig DMARC-politik med mindst p=none, og afmeldinger skal respekteres inden for to dage (Yahoo Sender Hub).
Outlook.com. Microsoft stiller kravet til domæner, der sender over 5.000 mails om dagen: SPF og DKIM skal bestå, og DMARC skal være mindst p=none og passe med enten SPF eller DKIM. Microsoft skrev først, at mails, der ikke levede op til det, ville havne i spam. Siden besluttede de at afvise dem fra 5. maj 2025 med fejlen "550; 5.7.515 Access denied" (Microsoft).
De færreste mindre virksomheder sender 5.000 mails om dagen, men et nyhedsbrev til en stor kundeliste kan nå det på én dag. Microsoft skriver selv, at alle afsendere har gavn af at følge kravene (Microsoft).
Hvad danske myndigheder anbefaler
Styrelsen for Samfundssikkerhed, som Center for Cybersikkerhed nu hører under, har en vejledning om DMARC, DKIM og SPF. Den anbefaler fire ting (Styrelsen for Samfundssikkerhed):
- DMARC med en reject-politik på alle domæner.
- SPF og DKIM på alle domæner.
- At indgående mails behandles efter afsenderdomænets DMARC-politik.
- At de DMARC-rapporter, man modtager, gennemgås løbende.
For statslige myndigheder er DMARC med reject et krav ifølge samme vejledning. For private virksomheder er det en anbefaling. Vejledningen beskriver også rækkefølgen: start med none, gennemgå rapporterne, ret fejlene, og gå så videre til reject.
Sådan gør I, trin for trin
Her er den rækkefølge, jeg selv bruger. Den følger vejledningen fra Styrelsen for Samfundssikkerhed.
1. Find alt, der sender mail i jeres navn
Det er det trin, der tager længst tid, og det vigtigste. Vejledningen nævner netop, at man skal have overblik over alle tjenester, der sender på organisationens vegne, så fx nyhedsbreve fra eksterne partnere ikke bliver blokeret (Styrelsen for Samfundssikkerhed). Typisk er det:
- Den almindelige mail, fx Microsoft 365 eller Google Workspace.
- Nyhedsbrevsværktøjet.
- Webshoppen, der sender ordrebekræftelser.
- CRM, booking- eller faktureringssystemet.
- Hjemmesidens kontaktformular.
Kontaktformularen er den, der oftest bliver glemt. Den sender tit fra jeres domæne via webhotellets server, som hverken står i SPF eller signerer med DKIM. Det er en af grundene til, at mails fra formularer forsvinder, og det er et af de punkter, jeg gennemgår i indlægget om, hvad du kan tjekke, når kontaktformularen ikke virker.
2. Saml SPF i én post
Skriv én SPF-post med en include for hver tjeneste. Tjek, at I ikke har en gammel post liggende ved siden af, og tæl opslagene. Er I i tvivl om, hvorvidt I har fundet alle afsendere, foreslår Styrelsen for Samfundssikkerhed at starte med ~all og skifte til -all, når listen er komplet (Styrelsen for Samfundssikkerhed).
3. Slå DKIM til i hver tjeneste
Gå tjenesterne igennem en ad gangen, og slå DKIM til med jeres eget domæne. Tjenesten giver jer de poster, der skal i DNS.
4. Start DMARC på none
Opret DMARC-posten med p=none og en adresse til rapporterne. Nu ændrer I ikke på, hvordan jeres mails bliver behandlet. I får bare at vide, hvad der sker.
5. Læs rapporterne, og ret det, der fejler
Giv det et par uger, så alle jeres systemer har nået at sende noget. Dukker der servere op, I ikke kender, er det enten en tjeneste, I har glemt, eller nogen, der udgiver sig for at være jer.
6. Stram op
Når jeres egne mails består, går I videre til p=quarantine og senere p=reject. Vil I gå forsigtigt frem, kan I sætte tagget t=y. Så beder I modtagerne om at behandle mails, der fejler, et trin mildere end politikken, mens I tester. Rapporterne bliver ikke påvirket, og med p=none har det ingen virkning (RFC 9989). Det ældre tag pct, der lod jer anvende politikken på en del af mailene, er fjernet i den nye standard, så brug det ikke i en ny post.
Glem ikke de domæner, I ikke sender fra
Mange virksomheder har flere domæner, fx en .com eller et gammelt firmanavn, der kun sender videre til hjemmesiden. De kan også misbruges til falske mails. Styrelsen for Samfundssikkerhed anbefaler at give dem en SPF-post, der siger, at ingen må sende, og en DMARC-post med reject (Styrelsen for Samfundssikkerhed):
gammeltnavn.dk TXT "v=spf1 -all"_dmarc.gammeltnavn.dk TXT "v=DMARC1; p=reject;"Sådan tjekker I, om det virker
Det nemmeste tjek er at sende en mail fra jeres domæne til en Gmail-adresse, åbne den og vælge Mere og Vis original (Gmail Hjælp). På den side, der åbner, viser Gmail øverst, om SPF, DKIM og DMARC bestod.
Vil I slå posterne op direkte, kan I bruge mit gratis DMARC check. Det slår MX, SPF, DKIM og DMARC op og forklarer svaret på dansk. DKIM kan det kun finde, hvis nøglen ligger på en almindelig selector, eller hvis I selv skriver den. Intet værktøj kan dog fortælle jer, om I har glemt en tjeneste. Det kan kun DMARC-rapporterne.
Typiske fejl
- -all eller reject for tidligt. Sætter I hårde regler, før I har fundet alle afsendere, er det jeres egne fakturaer eller nyhedsbreve, der bliver afvist.
- DMARC sat op og glemt. Rapporterne kommer, men ingen læser dem, og politikken bliver stående på none i årevis.
- DNS flyttes uden posterne. Skifter I webhotel eller navneservere, skal alle TXT-poster med. Det er en af de ting, jeg nævner i guiden til at flytte en WordPress-side uden nedetid.
Hvem skal eje det her
SPF, DKIM og DMARC ligger mellem hjemmesiden, mailen og de systemer, I sender nyhedsbreve og fakturaer fra, så det falder ofte mellem to stole. Det samme mønster gennemgår jeg i indlægget om managed WordPress-hosting, og derfor står mailen også i min sikkerheds-baseline for SMV'er.
Har I kun én mailtjeneste og et nyhedsbrev, kan I sagtens klare det selv med planen ovenfor. Har I mange systemer, der sender mail, eller er der ingen, der har ansvaret for DNS, så er det værd at få én til at holde styr på det. Som teknisk partner tager jeg mig af web, server, mail og sikkerhed i én aftale til 15.000 kr. om måneden ekskl. moms. Er det en enkelt opsætning, I har brug for, så skriv til mig, så finder vi ud af, hvad der skal til.
Ofte stillede spørgsmål
Hvad er forskellen på SPF, DKIM og DMARC?
SPF er en liste i jeres DNS over de servere, der må sende mail fra jeres domæne. DKIM er en digital signatur på hver mail, som modtageren kan tjekke mod en nøgle i jeres DNS. DMARC binder de to sammen og fortæller modtageren, hvad den skal gøre med en mail, der ikke består, og hvor den skal sende rapporter hen.
Skal en lille virksomhed have DMARC?
Gmail og Yahoo kræver kun DMARC af afsendere, der sender mange mails, og Microsoft stiller kravet til domæner, der sender over 5.000 mails om dagen til Outlook.com. Styrelsen for Samfundssikkerhed anbefaler dog DMARC med en reject-politik på alle domæner, fordi den beskytter jeres navn mod falske mails. Det er en DNS-post, så det koster ikke meget at sætte op.
Må man have to SPF-poster på samme domæne?
Nej. Standarden siger, at et domæne ikke må have flere SPF-poster. Har det det, giver tjekket en permanent fejl. Skal flere tjenester sende mail for jer, samler I dem i én post med en include for hver.
Hvorfor kommer mails fra kontaktformularen ikke frem, når alt andet virker?
Ofte fordi hjemmesiden sender mailen fra jeres domæne via webhotellets server, som ikke står i SPF-posten og ikke signerer med DKIM. Løsningen er enten at tilføje serveren eller at lade hjemmesiden sende gennem en mailtjeneste, der allerede er godkendt i jeres DNS.
Hvordan tjekker jeg, om mit domæne har SPF, DKIM og DMARC?
Send en mail fra jeres domæne til en Gmail-adresse, åbn den, og vælg Vis original. Her står resultatet for SPF, DKIM og DMARC. Mit gratis DMARC check på mahoje.dk kan også slå posterne op, så I kan se, om de findes og er skrevet rigtigt.
Kilder
Alle kilder er læst 2. oktober 2026, bortset fra RFC 9989, som er læst 18. oktober 2026.
- Gmail Hjælp: Email sender guidelines: support.google.com
- Gmail Hjælp: Trace an email with its full headers: support.google.com
- Yahoo Sender Hub: Sender Best Practices: senders.yahooinc.com
- Microsoft Defender for Office 365 Blog: Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders: techcommunity.microsoft.com
- Styrelsen for Samfundssikkerhed: Reducer risikoen for falske mails: samsik.dk
- Styrelsen for Samfundssikkerhed: Vejledning om DMARC, DKIM og SPF (pdf): samsik.dk
- RFC 7208: Sender Policy Framework (SPF): rfc-editor.org
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures: rfc-editor.org
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), maj 2026, afløser RFC 7489: rfc-editor.org
- Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain: learn.microsoft.com
