DMARC-opsætning for virksomheder: sådan stopper I, at fakturamails lander i spam

Hvorfor fakturamails pludselig lander i spam

I mange år var e-mail et tillidssystem uden kontrol. Enhver server kunne skrive hvad som helst i afsenderfeltet, og modtageren måtte selv gætte. Det er den svaghed, som faktura- og direktørsvindel bygger på: en mail, der ser ud, som om den kommer fra jer, med et nyt kontonummer.

Svaret fra branchen har været at vende bevisbyrden: en mail er ikke troværdig, før afsenderen kan bevise det. Beviset leveres med tre DNS-records – SPF, DKIM og DMARC – og i løbet af 2024 til 2026 er de tre gået fra anbefaling til adgangskrav.

Konsekvensen er ubehagelig for den almindelige danske virksomhed: det er ikke spam-mailen, der bliver stoppet først. Det er den legitime faktura fra en virksomhed, der sender fra tre forskellige systemer – økonomisystemet, Microsoft 365 og nyhedsbrevsplatformen – hvor kun det ene er skrevet ind i SPF-recorden.

PwC’s Cybercrime Survey 2025, offentliggjort 24. november 2025 på baggrund af svar fra 405 danske ledere, sikkerhedschefer og it-specialister, peger på phishing som den klart mest udbredte angrebsform: 62 pct. af de virksomheder, der havde oplevet en sikkerhedshændelse, nævnte phishing. Samme undersøgelse viser, at kun 13 pct. vurderer, at de har implementeret NIS2-kravene fuldt ud.

TDC Erhverv offentliggjorde 4. marts 2026 rapporten Er jeres virksomhed klar til i morgen?, som viser, at andelen af store danske virksomheder ramt af cyberangreb steg fra 6 til 14 pct. på et år, og for mellemstore virksomheder fra 5 til 13 pct.

»Vi har set mere end en fordobling i antallet af cyberangreb på ét år.«

John Henriksen, CEO, TDC Erhverv (4. marts 2026)

Det er baggrunden for, at mailudbyderne har mistet tålmodigheden. Og det er grunden til, at en mangelfuld DNS-opsætning i dag koster leverede fakturaer – ikke blot en dårlig score i et scanningsværktøj.

Staten skal afvise jeres mail, hvis DMARC ikke passer

Her er pointen, som næsten ingen danske vejledninger nævner. De fleste artikler om DMARC handler om at beskytte sig mod at blive misbrugt. Men i Danmark findes der et sæt bindende krav, som gør jeres egen DMARC-politik til modtagerens pligt – og dermed til en reel driftsrisiko for jeres fakturaflow.

Dokumentet heder De tekniske minimumskrav for statslige myndigheder 2024 og udgives af Styrelsen for Samfundssikkerhed. Den udgave, der gælder nu, er opdateret i september 2025. Fire af kravene handler direkte om mail, og de rammer jer som leverandør:

Kombinationen er det, der gør det skarpt. Krav 23 betyder, at enhver mail, I modtager fra en statslig myndighed, er beskyttet af reject. Krav 10 betyder, at enhver mail, I sender til en myndighed, bliver målt mod jeres egen politik. Sætter I p=reject, fordi en konsulent anbefalede det, og glemmer at få nyhedsbrevssystemet eller det nye bogføringssystem ind i SPF-recorden, har I selv givet staten instruks om at kassere jeres fakturaer. Uden varsel, uden bounce til bogholderen i mange tilfælde, og uden at nogen opdager det, før rykkeren kommer.

Styrelsen for Samfundssikkerhed er samtidig den myndighed, der anbefaler reject til alle. I vejledningen Reducer risikoen for falske mails, 2. udgave, februar 2022, står anbefalingen uden forbehold:

»Anvend DMARC med en REJECT-politik på alle domæner. Implementer SPF og DKIM på alle domæner.«

Center for Cybersikkerhed, Reducer risikoen for falske mails, 2. udgave, februar 2022 (nu Styrelsen for Samfundssikkerhed)

Samme vejledning beskriver vejen derhen: start med at monitorere med politikken none, gennemgå de aggregerede leveringsrapporter, og eskalér derefter til reject. For passive domæner – domæner, I ejer, men ikke sender fra – anbefales SPF med -all, DMARC med p=reject og en tom DKIM-record på *._domainkey. Og for at dække subdomæner skal recorden indeholde sp=reject.

DMARC blev en rigtig standard i maj 2026 – og det ændrer jeres record

DMARC har i ti år levet som en informational RFC – en beskrivelse af noget, branchen alligevel gjorde. Det ændrede sig i maj 2026. IETF udgav tre dokumenter på Standards Track, som tilsammen erstatter RFC 7489 og RFC 9091:

• RFC 9989 – Domain-Based Message Authentication, Reporting, and Conformance (DMARC), selve protokollen
• RFC 9990 – DMARC Aggregate Reporting, de XML-rapporter modtagerne sender tilbage
• RFC 9991 – DMARC Failure Reporting, de detaljerede fejlrapporter

Opdelingen i tre er praktisk: specifikationen kan nu vedligeholdes i dele. Men tre ændringer har direkte betydning for den DNS-record, I har stående i dag.

Vær opmærksom på, at udrulningen af RFC 9989 i mailudbydernes systemer tager tid, og at en record med pct= fortsat vil blive læst af de fleste modtagere i en overgangsperiode. Men hvis I alligevel skal igennem jeres DNS i efteråret 2026, er det nu, de fire linjer rettes – ikke om to år, når et scanningsværktøj flager dem.

NIS2, cyberforsikringen og bogføringsloven: tre grunde mere

NIS2: sikret kommunikation står i loven

Lov nr. 434 af 6. maj 2025 om foranstaltninger til sikring af et højt cybersikkerhedsniveau trådte i kraft 1. juli 2025. Lovens § 6, stk. 1 opregner ti områder, foranstaltningerne som minimum skal omfatte. Nr. 10 er »multifaktorautentificering og sikret kommunikation«, og nr. 4 er forsyningskædesikkerhed.

Loven gælder efter § 5 fra 50 ansatte eller 10 mio. euro i omsætning og balance, og kun for enheder i lovens bilag 1 og 2. De fleste danske små og mellemstore virksomheder er derfor ikke direkte omfattet. Men nr. 4 er den paragraf, der rammer alligevel: når en omfattet kunde skal dokumentere sin forsyningskæde, sender den et sikkerhedsspørgeskema videre til jer – og spørgsmålet om SPF, DKIM og DMARC står i stort set alle skemaer, vi har set.

Bemærk også § 7, stk. 1, der er usædvanlig direkte: foranstaltningerne »skal være godkendt af enhedens ledelsesorgan. Ledelsesorganet fører tilsyn med foranstaltningernes gennemførelse.« Det er ikke it-afdelingens beslutning, om DMARC står på reject.

Cyberforsikringen: dokumenterede kontroller eller nedsat dækning

Danske cyberforsikringer stiller egne sikkerhedsvilkår, og de gælder fra første police – uanset virksomhedens størrelse. Policerne kræver typisk stærke adgangskoder, relevante tekniske kontroller, rettidige sikkerhedsopdateringer og dokumentation for, at kravene er opfyldt. Som Beierholm formulerer det om konsekvensen: »Hvis disse krav ikke er opfyldt – eller ikke kan dokumenteres – har forsikringsselskabet i nogle tilfælde mulighed for helt eller delvist at afvise dækning.«

En DMARC-record på reject er en af de nemmeste tekniske kontroller at dokumentere: den står i offentlig DNS, og enhver kan slå den op. Vi har gennemgået de typiske sikkerhedsvilkår i danske cyberpolicer i en selvstændig artikel.

Bogføringsloven: et bilag, der aldrig kom frem

Bogføringslovens § 4 opregner syv typer regnskabsmateriale, og nr. 3 er bilag. § 13 lyder: »Virksomheder skal sikre, at regnskabsmaterialet ikke ødelægges, bortskaffes eller forvanskes, ligesom det skal sikres mod fejl og misbrug.«

Når en fakturamail afvises af modtagerens server, er det primært jeres likviditet, der lider. Men den anden vej er alvorligere: hvis leverandørfakturaer til jeres bogholderi havner i uønsket post og bliver slettet automatisk efter 30 dage, har I et bilag, der aldrig nåede ind i materialet. Det er ikke en teknisk detalje – det er et hul i transaktionssporet. En korrekt opsat DMARC-politik på jeres eget domæne hjælper ikke her; det kræver, at I også holder øje med, hvad jeres mailfilter gør med indgående post, og at I har en backup af postkassen, der rækker længere end Microsofts egne papirkurve.

Hvad JITS gør for jer

JITS ApS har ligget i Søndersø på Fyn siden 1999 og driver hosting, Microsoft 365, økonomisystemer og webshops for danske virksomheder. Mailsikkerhed ligger i krydsfeltet mellem alle fire – og det er netop derfor, den så ofte falder mellem stolene hos virksomheder med flere leverandører.

Ligger jeres hjemmeside og mail i forvejen hos os, er DNS-arbejdet inkluderet i den løbende drift. Se vores webhotel- og hostingløsninger, eller læs om, hvordan vi beskytter endepunkterne, når en phishingmail alligevel slipper igennem.