Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
[email protected]
E-mail 7 min. læsning Opdateret 3. oktober 2026

Nogen sender mails fra dit domæne: spoofing og DMARC-stramning

Spoofing af jeres domæne – falske mails og bounces for ukendte beskeder? Sådan strammer du DMARC fra none til reject uden at ramme egne mails.

Nogen sender mails fra dit domæne: spoofing og DMARC-stramning

Kort svar: Når andre sender mails, der udgiver sig for at komme fra dit domæne, er svaret ikke panik, men politik: DMARC. Med SPF og DKIM på plads strammer du gradvist – fra p=none (overvåg) over p=quarantine (i spam) til p=reject (afvis) – mens du læser rapporterne mellem hvert trin, så legitime afsendere ikke rammes. Ved reject bliver dit domæne langt mindre værd at forfalske, og strømmen af bounces for mails, I ikke har sendt, ebber ud.

Fagligt gennemgået: 2. oktober 2026

Symptomerne kommer typisk udefra: kunder spørger til en mærkelig faktura „fra jer“, kolleger modtager phishing med direktørens navn, eller indbakken fyldes med bounces for mails, ingen har sendt. Fra-feltet i en mail er et frit tekstfelt – enhver kan skrive dit domæne i det. Det, der afgør, om forfalskningen virker, er din DMARC-politik hos modtagerne.

Grundopsætningen af SPF, DKIM og DMARC er forklaret i guiden om SPF, DKIM og DMARC. Denne artikel handler om stramningen – og er opdateret til den nye DMARC-standard fra maj 2026.

Før du ændrer noget: Gem den nuværende SPF-, DKIM- og DMARC-record som tekst, før du retter. Spring aldrig direkte til p=reject uden at have læst rapporter i nogle uger – en glemt afsender, fx bogholderiet eller nyhedsbrevet, får så sine mails afvist uden varsel.

Hvad spoofing er – og ikke er

Spoofing betyder ikke, at nogen er „inde i“ jeres mail. Afsenderen har blot skrevet jeres domæne i Fra-feltet fra en helt fremmed server. Derfor er første skridt altid at afklare, hvad der reelt sker:

  • I får bounces for ukendte mails: klassisk backscatter fra spoofing. Modtagerservere sender afvisningen tilbage til den adresse, der stod som afsender – jeres.
  • Falske mails står i en kollegas Sendt-mappe: så er det ikke spoofing, men en kompromitteret konto. Skift kodeord, slå totrinslogin til, tjek videresendelsesregler, og gå efter sporet for sikkerhedshændelser – DNS løser ikke det problem.
  • Mails sendt fra jeres hjemmeside: en kontaktformular, der misbruges, sender ægte mails fra jeres server. Det er en formularopgave (captcha, rate limiting), ikke spoofing.

1. Byg fundamentet, før du strammer

En reject-politik rammer alt, der fejler autentifikation – også jeres egne mails, hvis fundamentet vakler. Tjek først:

  • at SPF-recorden dækker alle systemer, der sender som domænet (mailserver, webshop, nyhedsbrev, CRM, bogholderi) og holder sig under grænsen på 10 DNS-opslag;
  • at DKIM-signering er slået til for hvert sendende system, med jeres eget domæne i signaturen;
  • at en DMARC-record med p=none og en rua=-rapportadresse har samlet rapporter i mindst et par uger.
_dmarc.ditdomæne.dk  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ditdomæne.dk"

Rapporterne er kortet over virkeligheden: de viser både forfalskerne – og de legitime afsendere, I havde glemt.

2. Læs rapporterne rigtigt

Aggregerede rapporter (rua) kommer som XML-filer, typisk én pr. modtager pr. døgn. De er svære at læse rå, så brug et rapportværktøj, der samler dem i en oversigt. Det, du kigger efter, er:

  • Kilde-IP og afsender: hvilke servere sender som jeres domæne? Genkend jeres egne systemer, og markér resten som ukendte.
  • Alignment: DMARC kræver, at SPF eller DKIM ikke bare består, men består for jeres domæne. Et nyhedsbrevssystem, der signerer med sit eget domæne, består DKIM, men fejler DMARC.
  • Videresendelse: mails, der videresendes (fx fra en alumnekonto), fejler ofte SPF, men kan stadig bestå på DKIM. Derfor er DKIM på alle legitime kilder det vigtigste sikkerhedsnet.

Ret hver legitim kilde, der fejler: tilføj den til SPF, eller – bedre – slå DKIM til med jeres domæne hos udbyderen. Når rapporterne kun viser fejl fra ukendte kilder, er I klar til næste trin. Viser rapporterne fejl på mails, I faktisk har sendt, så brug guiden om DMARC-fail.

3. Stram trin for trin

Terminaleksempel: DMARC-recorden strammes fra none over quarantine til reject
Genskabt terminaleksempel, 30. august 2026: trappen fra overvågning til afvisning – med pct-gradvis indfasning som mellemtrin. Eksemplet er ikke data fra hostious.io.
  1. p=none (2-4 uger): ingen håndhævelse – kun rapporter. Ryd op, til alle legitime kilder består SPF eller DKIM med korrekt alignment.
  2. p=quarantine (2-4 uger): fejlende mails lægges i spam hos modtagerne. Fortsæt med at læse rapporter, og hold øje med henvendelser om mails, der ikke kom frem.
  3. p=reject: forfalskede mails afvises helt. Det er målet.

Om pct og den nye testtilstand: billedet viser pct som gradvis indfasning. I den nye DMARC-standard (RFC 9989, maj 2026) er pct fjernet. I stedet findes t=y, som sætter politikken i testtilstand og nedgraderer den ét trin: p=reject; t=y behandles som quarantine, og p=quarantine; t=y som none. Ældre modtagere kan stadig læse pct, men regn ikke med, at en delvis procentsats bliver respekteret.

; Trin 2: karantæne
_dmarc.ditdomæne.dk  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ditdomæne.dk"

; Overgang: reject i testtilstand (behandles som quarantine)
_dmarc.ditdomæne.dk  TXT  "v=DMARC1; p=reject; t=y; rua=mailto:dmarc@ditdomæne.dk"

; Mål: fuld håndhævelse
_dmarc.ditdomæne.dk  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ditdomæne.dk"

Gmail, Yahoo og Microsoft kræver i dag, at domæner, der sender store mængder mail til deres brugere, har en DMARC-record – mindst p=none. Reject er ikke et krav, men det er den politik, der faktisk stopper forfalskning. Kravene er gennemgået i guiden om Gmail-kravene.

4. Husk subdomæner og domæner uden mail

Politikken gælder som udgangspunkt også subdomæner. Vil du styre dem særskilt, kan du bruge disse tags:

TagBetydningEksempel
p=Politik for domænetp=reject
sp=Politik for eksisterende subdomænersp=reject
np=Politik for subdomæner, der ikke findes i DNS (ny i RFC 9989)np=reject
t=Testtilstand; t=y nedgraderer politikken ét trint=y
rua=Adresse til aggregerede rapporterrua=mailto:dmarc@ditdomæne.dk

Domæner, der aldrig sender mail – fx beskyttelsesdomæner og stavevarianter – bør have deres egen reject-politik og en SPF-record, der ikke tillader nogen afsendere. Så kan de heller ikke misbruges:

ditdomaene-variant.dk         TXT  "v=spf1 -all"
_dmarc.ditdomaene-variant.dk  TXT  "v=DMARC1; p=reject"

5. Mens spoofingen står på

Stramningen tager uger, og i mellemtiden kan der komme falske mails og bounces. Det kan du gøre imens:

  • Advar kunder og samarbejdspartnere kort, hvis de falske mails er målrettet dem – fx med en besked om, at I aldrig ændrer kontonumre pr. mail.
  • Lav en regel i mailprogrammet, der samler bounces for ukendte mails i en mappe, så de ikke drukner de rigtige.
  • Gem et par eksempler med fulde headere. De viser, hvilke servere der sender, og om mailen faktisk fejlede DMARC hos modtageren.

Når navnet forfalskes uden dit domæne

DMARC beskytter domænet – ikke visningsnavnet. Svindlere skifter derfor ofte taktik til „display name spoofing“: mailen kommer fra en tilfældig gratisadresse, men viser „Marc fra Firmaet“ som navn – eller fra et forvekslingsdomæne som ditdomaene-dk.com. Det kan DNS ikke stoppe. Forsvaret er årvågenhed og procedurer – beløbsændringer bekræftes altid på en anden kanal – og eventuelt registrering af de mest oplagte tvillingedomæner. Pointen er, at reject lukker den tekniske forfalskning; den menneskelige håndteres med vaner.

Verificér stramningen

Stramningen er i mål, når:

  • politikken står på p=reject uden testtilstand;
  • rapporterne viser, at jeres legitime kilder består, og at forfalskningerne afvises;
  • egne testmails til Gmail og Outlook viser dmarc=pass i headeren;
  • bounces for ukendte mails ebber ud over de følgende uger.

Behold rapportlæsningen som månedlig rutine: nye systemer, der sender som domænet, dukker altid først op dér.

Læs også

Ofte stillede spørgsmål om spoofing

Er vi blevet hacket, når andre sender fra vores domæne?

Næsten aldrig – Fra-feltet kan forfalskes af enhver uden adgang til noget hos jer. Tjek Sendt-mapperne: er de rene, er det spoofing og en opgave for jeres DNS-politik. Ligger de falske mails dér, er en konto kompromitteret – så er det kodeord og oprydning.

Hvor lang tid tager vejen til p=reject?

Typisk 1-2 måneder i ro og orden: et par uger på none med oprydning, et par uger på quarantine med rapportlæsning – og så reject, eventuelt med en kort periode med t=y som mellemtrin. Hastværk koster tabte legitime mails.

Stopper p=reject al phishing mod vores kunder?

Den stopper mails, der påstår at komme fra jeres præcise domæne – en stor og vigtig del. Visningsnavnetricks og tvillingedomæner kan den ikke røre; dér er procedurer og opmærksomhed forsvaret.

Skal domæner, vi ikke sender mail fra, også have DMARC?

Ja. Et domæne uden mail kan stadig forfalskes. Giv det en SPF-record med v=spf1 -all og en DMARC-record med p=reject, så modtagerne afviser alt, der påstår at komme derfra.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 31. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026