DNS‑baseret mailsikkerhed – komplet oversigt

🔐 DNS‑baseret mailsikkerhed – komplet oversigt (inkl. SPF/DKIM/DMARC/DANE)

Her er ALLE centrale teknologier, du kan implementere på DNS‑niveau for at sikre både indgående og udgående mail.


1. SPF (Sender Policy Framework) – DNS TXT‑record

Beskytter mod: spoofing (hvem må sende fra dit domæne)

SPF definerer hvilke servere/IP’er der har lov til at sende mail på vegne af domænet.

Eksempel:

v=spf1 include:spf.protection.outlook.com -all

2. DKIM (DomainKeys Identified Mail) – DNS TXT‑record

Beskytter mod: manipulation af mailindhold (integritet)

DKIM lægger en digital signatur i mailen, og den offentlige nøgle ligger i DNS.

Eksempel:

selector._domainkey.example.com  IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

3. DMARC – DNS TXT‑record

Beskytter mod: misbrug af domænet + rapportering

DMARC kræver SPF/DKIM alignment og styrer håndhævelse.

Eksempel (reject):

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

🔒 4. DANE (DNS‑Based Authentication of Named Entities) – DNS TLSA-record

Beskytter mod: MITM‑angreb på SMTP, certifikat‑spoofing
Kræver: DNSSEC

Bruges til at binde TLS‑certifikatet til SMTP‑serveren via DNS.

Eksempel:

_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash>

🛡️ 5. DNSSEC (DNS Security Extensions)

Beskytter mod: manipulation af DNS‑records (fundamentet for DANE)

DNSSEC tilføjer kryptografisk signering af dine DNS‑records.

Hvis du har DANE, bør DNSSEC være aktiv, men mange har det stadig ikke korrekt.


📦 6. MTA‑STS (SMTP Strict Transport Security)

Beskytter mod: TLS‑downgrade angreb, MITM når DANE ikke bruges

Består af:

  • TXT‑record: _mta-sts.domæne
  • HTTPS policy‑fil på:
    https://mta-sts.<domæne>/.well-known/mta-sts.txt

Eksempel TXT:

_mta-sts.example.com TXT "v=STSv1; id=20260208"

📊 7. TLS‑RPT (SMTP TLS Reporting)

Beskytter: indirekte – ved at overvåge fejl i krypteret SMTP
Rapporter: failures i TLS leveringer fra andre mailservere

Eksempel:

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

🏷️ 8. BIMI + VMC (Brand Indicators for Message Identification)

Beskytter mod: phishing via visuel brandforfalskning

Kræver:

  • DMARC enforcement (p=quarantine/reject)
  • Valid logo (SVG)
  • Ofte VMC‑certifikat (betalt)

Eksempel:

default._bimi.example.com TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

🪪 9. CAA (Certification Authority Authorization)

Beskytter mod: uautoriseret udstedelse af TLS‑certifikater

Eksempel:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"

🔁 10. ARC (Authenticated Received Chain)

Ikke DNS, men relateret – vigtigt for forwarding

Beskytter mod:

  • DMARC failures ved videresendelse
  • Mailing‑lists / helpdesk / autosvar‑systemer

11. DNSBL / RBL (indgående spam‑beskyttelse)

DNS‑baseret bag‑sceningsteknologi til:

  • spamfiltrering
  • IP reputation
  • beskyttelse af modtagende mailserver

Ikke en DNS‑record, men baseret på DNS‑lookups.


🔒 Oversigt: DNS‑baseret mailsikkerhed og hvad hvert tiltag beskytter

Sikkerhedstiltag Beskytter hvad?
SPF Hvem må sende mail på vegne af domænet (anti‑spoofing)
DKIM Integritet af mailens indhold og afsenderautentifikation
DMARC (reject/quarantine) Politikhåndhævelse + rapportering + kombinationsbeskyttelse af SPF/DKIM
DNSSEC Integritet af DNS‑opslag (forhindrer manipulation, fundament for DANE)
DANE for SMTP (TLSA) Kryptering + autentifikation af SMTP‑servere (beskytter mod MITM)
MTA‑STS Sikrer TLS‑levering og forhindrer TLS‑downgrade, hvor DANE ikke er understøttet
TLS‑RPT Rapportering af fejl i krypteret SMTP‑transport (TLS problemer)
CAA Kontrol over hvilke CA’er der må udstede TLS‑certifikater til dit domæne
BIMI / VMC Visuel identitet og brandbeskyttelse i modtagerens indbakke
ARC Sikrer mails ved videresendelse, så DMARC ikke fejler
DNSBL / RBL Beskytter indgående mail mod spam via DNS‑baserede blocklists (ikke en record, men DNS‑opslag)

 

Sådan Opsætter du SPF, DKIM og DMARC Korrekt

Den Ultimative Guide: Sådan Opsætter du SPF, DKIM og DMARC Korrekt

En teknisk step‑by‑step vejledning til moderne e‑mail‑sikkerhed


Introduktion

I 2026 er SPF, DKIM og DMARC blevet kritiske for både sikkerhed og leveringssikkerhed. Stigende AI‑genererede phishingangreb og skærpede krav fra store mailudbydere betyder, at e‑mail uden korrekt autentifikation kan ende i spam eller helt blive afvist. 

De tre teknologier arbejder sammen:

  • SPF – angiver hvilke servere der må sende mail
  • DKIM – sikrer mailens integritet via signatur
  • DMARC – afgør hvad der skal ske, hvis SPF/DKIM fejler

SPF — Sender Policy Framework

Hvad SPF gør

SPF definerer hvilke mailservere der er autoriseret til at sende mails på vegne af dit domæne. Modtageren sammenligner afsenderens IP med domænets SPF‑record. 

SPF Best Practices (2026)

  • Kun én SPF‑record pr. domæne
  • Maksimalt 10 DNS lookups i SPF
    (ellers fejler SPF) 
  • Brug ~all under opsætning (softfail)
    — stopper ikke mailflow men markerer fejl til videre analyse 
  • Undgå brede CIDR ranges eller unødvendige afsendere
  • Sørg for alignment mellem MAIL FROM og From‑domæne

Eksempel‑records

  • Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all

  • Google Workspace: v=spf1 include:_spf.google.com ~all


DKIM — DomainKeys Identified Mail

Hvad DKIM gør

DKIM tilføjer en digital signatur til dine mails, så modtageren kan verificere, at indholdet ikke er ændret, og at mailen faktisk kommer fra dit domæne. 

DKIM Best Practices (2026)

  • Brug 2048‑bit nøgler for sikkerhed og kompatibilitet

  • Aktivér DKIM på alle tjenester, der sender på vegne af domænet
  • Roter DKIM‑nøgler med faste intervaller
  • Sørg for domain alignment (d=domæne.dk)

DMARC — Domain-based Message Authentication, Reporting & Conformance

Hvad DMARC gør

DMARC kontrollerer om SPF eller DKIM består — og afgør herefter, om mailen skal leveres, quarantines eller afvises. DMARC genererer desuden rapporter til overvågning af misbrug. 

DMARC Best Practices (2026)

  • Start med p=none (monitorering)

  • Skift herefter til quarantine
  • Afslut med reject, når alt er valideret
    → anbefalet i 2026 for maksimal beskyttelse 
  • Aktivér rapportering med rua= og ruf=
  • Overvåg DMARC‑rapporter løbende

Eksempel‑records

Monitorering:

v=DMARC1; p=none; rua=mailto:dmarc-reports@domain.dk; aspf=r;

Quarantine:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@domain.dk;

Reject (endelig):

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@domain.dk;

Komplet opsætningsworkflow (DNS)

1. Kortlæg eksisterende opsætning

  • Tjek om domænet allerede har SPF, DKIM eller DMARC
  • Identificér ALLE systemer der sender mail:
    M365, Google, CRM, marketing, faktura‑systemer osv.
    (Glemt afsender = SPF/DKIM fejl) 

2. Opret / opdater SPF

  • Tilføj alle afsendere via include:
  • Fjern gamle eller ubrugte afsendere
  • Tjek lookup‑antal (max 10)

3. Aktivér DKIM

  • Microsoft 365: Aktivér DKIM i admin panelet
  • Google Workspace: Generér nøgle & publicér i DNS
  • Tredjepartstjenester: DKIM selector + TXT‑nøgle
  • Bekræft 2048‑bit brug

4. Implementér DMARC

  • Start med p=none
  • Analyser de indkomne rapporter (RUA)
  • Identificér forkerte eller uautoriserede kilder
  • Skru gradvist op til quarantinereject

5. Validering og overvågning

  • Gennemgå fejl i SPF alignment
  • Overvåg DKIM signaturfejl
  • Brug DMARC‑rapporter til løbende forbedring

Typiske fejl – og hvordan du undgår dem

❌ Fejl: To SPF‑records

→ SPF må KUN eksistere én gang (ellers ugyldig).

❌ Fejl: SPF overskrider 10 DNS‑lookups

→ Konsolider includes og fjern gamle services.

❌ Fejl: DKIM kun aktiveret på primær mailtjeneste

→ Alle systemer, der sender mail, skal signere.

❌ Fejl: Start med p=reject

→ Giver leveringsfejl og tabte mails. Start altid med p=none.


Konklusion

I 2026 er SPF, DKIM og DMARC fundamentale krav for moderne mail‑sikkerhed.
En korrekt opsætning beskytter dit domæne, reducerer spoofing og sikrer, at dine mails faktisk når indbakken.

TODO‑IT kan hjælpe med:

  • Komplet DNS‑opsætning
  • Fejlfinding og DMARC‑rapportanalyse
  • Sikring på tværs af flere mailplatforme
  • Drift og optimering af e‑mail leveringssikkerhed