Mail havner i spam? Få styr på SPF, DKIM og DMARC

Mail havner i spam, selvom I sender fra Microsoft 365 og “gør det rigtige” med pæne emnelinjer. Typisk skyldes det ikke marketingindholdet, men jeres DNS og afsenderautentificering. Når SPF, DKIM eller DMARC ikke passer sammen (eller når en tredjepartsplatform sender uden at være godkendt), taber I leveringsevne i Gmail/Yahoo og risikerer spoofing. Her får I en praktisk plan, der både IT og Marketing kan bruge til at få mails igennem uden at åbne for misbrug.

• Kortlæg alle afsendere: lav en liste over Microsoft 365 + alle systemer der sender på vegne af jeres domæne (CRM, ERP, e-signatur, nyhedsbrev) før I ændrer DNS.
• Fix SPF uden at ramme 10-lookup-grænsen: hold SPF kort, undgå “include-stabling”, og brug subdomæner til marketing, hvis I har mange services.
• Slå DKIM til i Microsoft 365: signer udgående mail for jeres custom domain, så modtagere kan validere at mailen ikke er ændret.
• Start DMARC med rapportering: kør p=none med RUA-rapporter, identificér ukendte afsendere, og stram derefter til quarantine/reject.
• Lav governance for “shadow IT”: kræv at Marketing altid bestiller DKIM/CNAME-setup hos IT før nye mailværktøjer tages i brug.

Hvorfor mail havner i spam, selvom I bruger Microsoft 365

Microsoft 365 er kun en del af historien. Modtageren vurderer jeres domæne, jeres afsender-IP’er og om mailen kan autentificeres korrekt. Tre mønstre går igen hos danske SMB’er:

1. Tredjepartsafsendere (fx HubSpot/Mailchimp/fakturasystem) sender som @jeresdomæne.dk, men er ikke dækket af SPF eller signer ikke med DKIM.
2. SPF fejler teknisk pga. for mange DNS-opslag (RFC 7208’s 10-lookup limit). Resultat: PermError og i praksis dårligere levering.
3. DMARC er sat, men ikke håndhævet: p=none giver rapporter, men stopper ikke misbrug. Og en for hård policy uden oprydning kan blokere legitime systemmails.

Google’s sender guidelines og stramninger fra 2024/2025 har skubbet markedet i retning af “autentificér eller bliv frasorteret”. Hvis I sender mange kampagner, er forventningen typisk SPF og DKIM samt DMARC-policy. (Kilde: Google Email Sender Guidelines, 2025-2026 praksis.)

Sådan virker SPF, DKIM og DMARC sammen (uden nørdesnak)

SPF: Hvem må sende for domænet?

SPF er en DNS-tekstrecord, der siger hvilke mailservere/tjenester der må sende som jeres domæne. Den fejler ofte, når man bare tilføjer flere og flere include: til samme record.

DKIM: Kan modtageren stole på indholdet?

DKIM signerer mailen kryptografisk. I Microsoft 365 skal DKIM aktiveres for jeres custom domain, så mailen får en gyldig signatur. (Kilde: Microsoft Learn: Use DMARC to validate email / DKIM for custom domains.)

DMARC: Hvad gør modtageren, når SPF/DKIM ikke matcher?

DMARC er jeres “politik”. Den afgør om mails der fejler autentificering skal overvåges (p=none), sendes i karantæne (p=quarantine) eller afvises (p=reject). DMARC kan også sende rapporter (RUA), så I kan se hvem der sender i jeres navn.

Før → Efter #1
Før: Marketing tager et nyt nyhedsbrevsværktøj i brug og sender fra info@jeresdomæne.dk uden DKIM/CNAME. Mails lander i spam, og salgsafdelingen mister svar.
Efter: Værktøjet får sit eget afsender-subdomæne (fx news.jeresdomæne.dk), DKIM er verificeret, og DMARC-rapportering viser “grønt” for den strøm. Levering bliver stabil, og IT kan håndhæve DMARC for hoveddomænet uden at knække marketing.

Tjekliste: Auditér jeres domæne, før I ændrer noget

Brug tjeklisten som fælles sprog mellem IT og Marketing. Målet er at kende alle legitime afsendere, før I strammer DMARC.

Kontrol	Hvad I kigger efter	Beslutningsregel
1) Afsender-inventar	Alle systemer der sender som jeres domæne (M365, CRM, ERP, booking, e-signatur, marketing)	Hvis et system kan sende “From: @jeresdomæne.dk”, skal det være dækket af SPF og/eller DKIM.
2) SPF-status	Én SPF-record pr. domæne, ingen duplikater, ingen “overlap”	Hvis I har mere end én SPF-record: ret det først (ellers får I SPF-fail).
3) SPF 10-lookup	For mange include: giver PermError (RFC 7208)	Hvis I nærmer jer grænsen: flyt nogle afsendere til subdomæner eller konsolider services.
4) DKIM i Microsoft 365	DKIM er aktiv for jeres custom domain, og CNAME records er sat	Hvis DKIM ikke er aktiv: slå det til før DMARC strammes.
5) DMARC-policy + rapportering	DMARC TXT-record med rua= til en mailbox/tjeneste I læser	Start med p=none i 2–4 uger, og stram kun når alle legitime strømme er identificeret.
6) Subdomæner til segmentering	Separér transaktionsmail og marketingmail	Hvis Marketing ofte skifter værktøj: brug et fast marketing-subdomæne for at beskytte hoveddomænets omdømme.

Fejl der koster leveringsevne (og hvordan I undgår dem)

Fejl 1: “Vi tilføjede bare én include mere”

SPF er ikke uendeligt. Når I lægger flere cloud-tjenester ovenpå hinanden, stiger DNS-opslag hurtigt, og så kan SPF fejle for alle modtagere der håndhæver standarden stramt. (Kilde: RFC 7208.)

Fix: Prioritér hvilke tjenester der skal sende fra hoveddomænet. Resten flyttes til subdomæner. Alternativt kan nogle tjenester sende fra deres eget domæne med korrekt reply-to, hvis det passer jer.

Fejl 2: DMARC sættes til reject for tidligt

DMARC p=reject stopper spoofing effektivt, men den stopper også legitime mails, hvis de ikke er korrekt sat op. MXToolbox og andre fejlsøgningsguides peger på den samme fælde: man mangler at læse og handle på DMARC-rapporter først.

Fix: Kør rapportering, ryd op i ukendte afsendere, og stram i trin (none → quarantine → reject).

Før → Efter #2
Før: IT “låser” domænet med DMARC p=reject, og fakturaer fra et ældre økonomisystem når ikke frem til kunder.
Efter: Systemet får enten DKIM sat korrekt op eller flyttes til et subdomæne med egen SPF/DKIM/DMARC. Hoveddomænet kan fortsat køre stramt, og forretningen mister ikke kritiske mails.

Sådan går I fra DMARC p=none til p=reject uden at knække noget

1. Uge 0: Sæt ejerskab — én person i IT ejer DNS og ændringer; Marketing har én kontaktperson der godkender nye mailværktøjer.
2. Uge 1: Aktivér DKIM for alle relevante domæner i Microsoft 365 — verificér at CNAME-records er korrekte, og at der signeres på udgående mail.
3. Uge 1: Publicér DMARC med rapportering — start med v=DMARC1; p=none; rua=mailto:dmarc@jeresdomæne.dk (brug en mailbox/tjeneste I faktisk overvåger).
4. Uge 2–4: Læs rapporter og ryd op — find ukendte kilder, beslut om de skal godkendes (SPF/DKIM) eller stoppes.
5. Trinvis håndhævelse — skift til p=quarantine og derefter p=reject, når legitime kilder består. Hold øje med supporthenvendelser og bounce-mønstre i samme periode.

Hvis I har compliance-krav eller arbejder efter NIS2-inspirerede kontroller, er DMARC en dokumenterbar domænebeskyttelse mod impersonation og BEC-angreb. (Kilder: CISA anbefalinger/best practice; Proofpoint-rapport om BEC som typisk misbrug.)

FAQ: SPF, DKIM og DMARC i praksis

Hvorfor ryger mine mails i uønsket, når jeg sender fra Microsoft 365?

Fordi modtageren ikke kun kigger på jeres mailplatform, men på om afsenderen kan autentificeres. Hvis en tredjepart sender uden korrekt SPF/DKIM, eller jeres DMARC fejler alignment, falder jeres troværdighed, og mails filtreres hårdere.

Hvad er SPF og DKIM – og hvilken skal vi starte med?

SPF bestemmer hvem der må sende; DKIM beviser at mailen er signeret og ikke ændret. Start med at få DKIM slået til i Microsoft 365 for jeres domæner, og ret derefter SPF så den kun dækker de services, der reelt må sende fra domænet.

Hvordan tester vi vores SPF record uden at gætte?

Tjek at der kun findes én SPF TXT-record, og mål antallet af DNS lookups (10-lookup grænsen fra RFC 7208). Brug et kendt DNS/SPF-testværktøj til at se “Pass/Fail/PermError”, og ret strukturen før I tilføjer flere tjenester.

Hvad betyder DMARC p=none vs reject?

p=none overvåger og sender rapporter, men stopper ikke spoofing. p=reject beder modtagere afvise mails, der fejler DMARC. Praktisk tommelfingerregel: kør p=none indtil I har identificeret og fikset alle legitime afsendere; gå derefter til quarantine og til sidst reject.

Vi bruger HubSpot/Mailchimp – skal det med i SPF?

Ikke nødvendigvis. Mange marketingplatforme fungerer bedst med DKIM via CNAME-verificering på et dedikeret subdomæne (fx news). Hvis I propper alt ind i SPF på hoveddomænet, rammer I lettere 10-lookup-grænsen og skaber ustabil levering.

Hvordan passer det her ind i NIS2 og leverandørkrav?

DMARC er en konkret kontrol, der reducerer risikoen for domæne-impersonation og BEC. I kan dokumentere politik, rapportering og håndhævelse som en del af jeres sikkerhedsforanstaltninger for kommunikation og tredjepartsrisiko.

Kan vi få BIMI (logo i indbakken), og hvad kræver det?

Ja, men forvent at I skal have DMARC på p=quarantine eller p=reject og stabil autentificering først. (Kilde: BIMI Group / AuthIndicators.) Start med levering og sikkerhed; tag logoet som næste step.

Sådan kommer I i mål de næste 10 arbejdsdage

1. Dag 1: Kortlæg alle systemer der sender som @jeresdomæne.dk (inkl. “glemte” systemmails).
2. Dag 2: Tjek DNS for dobbelte SPF-records og mål SPF-lookups mod 10-lookup-grænsen.
3. Dag 3–4: Slå Microsoft 365 DKIM setup til for alle relevante domæner og verificér signatur på testmails.
4. Dag 5: Udrul DMARC med p=none + RUA til en overvåget mailbox.
5. Dag 6–10: Ryd op i afsendere (fix DKIM/CNAME, flyt til subdomæner, eller stop ukendte). Skift til p=quarantine, når rapporterne viser stabilitet.
6. Næste sprint: Planlæg p=reject på hoveddomænet og lav en fast proces for nye marketingværktøjer (DNS-change, DKIM-verificering, dokumentation).