SPF: hvem må sende
RFC 7208 tager udgangspunkt i en konstatering: intet i e-mailprotokollen forhindrer en server i at angive en hvilken som helst afsenderadresse. Med SPF kan ejeren af et domæne offentliggøre listen over de servere, der må sende på domænets vegne, i DNS, og den modtagende server kan kontrollere denne tilladelse.
To præciseringer ændrer alt:
- SPF kontrollerer konvolutadressen (den, serverne bruger indbyrdes, kaldet »MAIL FROM«) og det navn, serveren præsenterer sig med, ikke den adresse, modtageren ser i »Fra«-feltet.
- SPF vurderer den sidste server, der har afleveret e-mailen. Når en e-mail videresendes af en anden server, er det ikke længere en server, som det oprindelige domæne har godkendt, der afleverer den: kontrollen kan fejle, selv om e-mailen er legitim.
Et domæne offentliggør kun én SPF-post. Alle afsenderkilder skal stå i den: e-mailsystemet, faktureringsprogrammet, nyhedsbrevsværktøjet, CRM-systemet, kopimaskinen, der scanner til e-mail.
DKIM: e-mailen er signeret
Ifølge RFC 6376 giver DKIM ejeren af et signerende domæne mulighed for at påtage sig en del af ansvaret for en e-mail ved hjælp af en kryptografisk signatur. Den offentlige nøgle ligger i DNS. Kontrollen af signaturen fastslår, at de signerede dele ikke er ændret siden signeringen.
Signaturen følger med e-mailen. Den klarer sig derfor bedre end SPF gennem et relæ eller en videresendelse, så længe relæet ikke ændrer emnet eller brødteksten. En mailingliste, der tilføjer en tekst nederst i e-mailen, bryder den.
Hvad DKIM ikke gør, ifølge samme RFC: den krypterer ikke e-mailen, en fejl kræver ikke, at den afvises, og det signerende domæne behøver ikke at være det, der vises i »Fra«-feltet. Det er netop det hul, DMARC lukker.
DMARC: overensstemmelse og politik
RFC 7489 definerer DMARC som et middel, hvormed ejeren af et domæne kan udtrykke en politik på domæneniveau. Mekanismen bygger på overensstemmelse (alignment): domænet i adressen i »Fra«-feltet skal svare til det domæne, som SPF eller DKIM har godkendt. Stemmer ingen af dem overens, fejler DMARC.
Domænet offentliggør derefter, hvad det ønsker:
- none: ingen handling, man observerer;
- quarantine: behandl e-mailen som mistænkelig;
- reject: afvis e-mailen.
DMARC omfatter også rapporter: samlede rapporter, der opsummerer, hvilke servere der har sendt på domænets vegne og med hvilket resultat, og fejlrapporter for hver enkelt e-mail. Det er dem, der afslører et glemt værktøj, der sender for jer, eller en, der forfalsker jeres domæne.
| Mekanisme | Hvad den kontrollerer | Hvad den ikke ser på |
|---|
| SPF | Den server, der afleverer e-mailen, er godkendt for konvolutdomænet | Den viste adresse, indholdet |
| DKIM | Den signerede e-mail er ikke ændret; et domæne påtager sig ansvaret | Den viste adresse, indholdets ærlighed |
| DMARC | Det viste domæne stemmer overens med SPF eller DKIM; politik ved fejl | Lignende domæner, visningsnavnet, teksten |
Stopper DMARC phishing?
DMARC stopper en del af forfalskningen af domænet, ikke phishing generelt. RFC 7489 siger det udtrykkeligt: DMARC behandler hverken visuelt lignende domænenavne eller misbrug af visningsnavnet, og analyse af indholdet ligger uden for dens område. Den forsøger ikke at løse alle problemer med svigagtig post.
Konkret ser DMARC ikke:
- et forvekslingsdomæne: svindleren godkender sit eget domæne, der ligner jeres, helt korrekt;
- et forfalsket visningsnavn: »Bogholderiet« skriver fra en adresse uden nogen forbindelse;
- en kompromitteret konto, der signerer korrekt, da det er den rigtige server, der sender;
- en e-mail uden forbindelse til jeres domæne: en falsk advarsel fra et fragtfirma kommer fra et domæne, der intet har med jeres at gøre;
- et domæne uden politik: offentliggør det efterlignede domæne »none«, har modtageren ingen instruks om at afvise.
Disse tilfælde kræver andre analyser: domænelighed, omdømme, indhold, adfærd. Se spam, phishing, malware og kompromitterede konti.
Videresendelse og mailinglister: ARC
En videresendelse bryder ofte SPF, en liste, der ændrer e-mailen, bryder DKIM, og DMARC fejler så på en legitim e-mail. ARC, beskrevet i RFC 8617 (eksperimentel status), giver hvert mellemled mulighed for at bekræfte det godkendelsesresultat, det har konstateret. Den endelige server kan vælge at tage hensyn til det.
Beskyt jeres domæne, filtrér det, der kommer ind
De to emner forveksles ofte.
- Beskyt det domæne, der sender: offentliggør SPF, DKIM og DMARC for jeres domæne, så andre kan afvise e-mails, der forfalsker det. I offentliggør; modtagerne håndhæver.
- Filtrér det, der kommer ind: kontrollér andre domæners poster på den post, I modtager, og anvend derefter alle de øvrige analyser.
Gradvis indførelse
- Kortlæg alt, der sender på domænets vegne.
- Én SPF-post, der godkender dem alle; en DKIM-signatur for hver tjeneste, der kan signere.
- DMARC på »none« med en adresse til modtagelse af rapporterne.
- Læs rapporterne i flere uger; ret de glemte kilder.
- Skift til »quarantine« og derefter til »reject«, når alle legitime forsendelser stemmer overens.
Et eksempel til illustration. Et rådgivningsfirma offentliggør DMARC på »none« og læser sine første rapporter. Det opdager tre kilder: sit e-mailsystem, der stemmer overens; sit faktureringsprogram, der sender fakturaerne med firmaets domæne uden DKIM-signatur; og en ukendt server i udlandet, der sender hundredvis af e-mails i firmaets navn. Firmaet retter faktureringsprogrammet, venter på en rapportcyklus uden fejl og skifter derefter til »quarantine«: modtagere, der håndhæver DMARC, behandler nu e-mails fra den ukendte server som mistænkelige.
Den dag, man skifter e-mailsystem, forberedes disse poster før ændringen af MX. Vejledningen skift e-mailsystem uden afbrydelse beskriver dette øjeblik; det gentages ikke her.
Ofte stillede spørgsmål
Beskytter en DMARC-politik på »none«?
Nej. Den gør det muligt at observere via rapporterne. Beskyttelsen begynder med »quarantine« eller »reject«.
Hvorfor fejler en legitim e-mail i DMARC?
Oftest: en videresendelse, en mailingliste eller en tjeneste, der sender for jer uden at være angivet i SPF og uden at signere med DKIM.
Vores e-mailsystem signerer ikke med DKIM: hvad gør vi?
En gateway på vejen for den udgående post kan signere i stedet. Se Beskyt det e-mailsystem, I allerede har.
Hvor kan man se resultatet af disse kontroller på en modtaget e-mail?
I e-mailens headere. For Klytic MTA, se Læs og eksportér en filterbeslutning.
Hvor Klytic står
Klytic MTA håndterer begge emner foran ethvert e-mailsystem:
- Essential og Advanced: kontrol af SPF, DKIM og MX; DMARC-kontrol, også for videresendte e-mails takket være ARC; DKIM-signering af udgående post, selv om jeres e-mailsystem ikke gør det.
- Advanced: DMARC-konsol med rapporterne for jeres domæner, advarsler og forslag til rettelser, så I kan gennemføre den gradvise overgang til »reject«.
DMARC er kun ét lag: Klytic MTA tilføjer registrering af forvekslingsdomæner, visningsnavne og svindelscenarier, beskrevet i Identitetsforfalskning og direktørsvindel.
Bruger I Klytic Mail, er SPF, DKIM og DMARC konfigureret for jeres domæne: det er beskyttelsen af det domæne, der sender. Klytic MTA kan derimod tegnes med eller uden Klytic Mail.
Kilder
Gennemgået i oktober 2026.
- RFC 7208, SPF: ejeren af et domæne offentliggør de værter, der må bruge domænet i identiteten »MAIL FROM« eller »HELO«, og modtageren kontrollerer denne tilladelse. rfc-editor.org
- RFC 6376, DKIM: et domæne påtager sig ansvaret for en e-mail med en kryptografisk signatur; ingen kryptering, ingen påbudt afvisning, det signerende domæne kan være et andet end den viste afsender. rfc-editor.org
- RFC 7489, DMARC: overensstemmelse mellem domænet i »From« og SPF eller DKIM, politikkerne none, quarantine og reject, samlede rapporter og fejlrapporter; visuelt lignende domæner, visningsnavn og indholdsanalyse ligger uden for området. rfc-editor.org
- RFC 9989 (maj 2026), der erstatter RFC 7489: samme politikværdier og samme undtagelser (lignende domæner, visningsnavn). rfc-editor.org
- RFC 8617, ARC (eksperimentel): godkendt videresendelseskæde; en DMARC-modtager kan acceptere de vurderinger, en gyldig ARC-kæde bærer. rfc-editor.org
- Klytic, siden Klytic MTA: godkendelseskontroller, DKIM-signering af udgående post og DMARC-konsol i abonnementerne Essential og Advanced, tilvalg, driftsformer, idriftsættelse via MX. klytic.com
