Falske mails i jeres eget navn

Problemet, altså hvad der går galt uden denne service

E-mail blev bygget uden afsenderkontrol. Protokollen bag afsendelse, SMTP (Simple Mail Transfer Protocol), kontrollerer ikke, om afsenderen har ret til det navn, der står i feltet Fra. En svindler kan derfor sende post, som for modtageren ser ud til at komme fra jeres bogholderi.

Det udnyttes på tre måder. Falske fakturaer og betalingsanmodninger sendes til jeres kunder i jeres navn. Direktørsvindel bruger et velkendt navn internt til at få en medarbejder til at handle hurtigt uden kontrol. Phishing mod borgere eller samarbejdspartnere låner jeres troværdighed til at få adgangskoder udleveret.

Styrelsen for Samfundssikkerhed vurderer i Cybertruslen mod Danmark 2025, at truslen fra cyberkriminalitet mod Danmark er MEGET HØJ, og at det er meget sandsynligt, at hackere fortsat vil anvende phishing mod danske organisationer i de kommende år.

Der er også en omkostning, som ingen opdager med det samme. Når jeres domæne bruges til svindel, begynder modtagende mailsystemer at behandle al post fra domænet med mistro. Jeres egne tilbud og fakturaer havner i spamfilteret hos kunden. Uden overvågning opdager I typisk først problemet, når en kunde ringer og spørger til en faktura, I aldrig har sendt.

Baggrund forklaret i klartekst

Tre standarder arbejder sammen. De forklares her i den rækkefølge, de blev til.

SPF (Sender Policy Framework) er en liste i jeres DNS over de mailservere, der må sende post for jeres domæne. DNS (Domain Name System) er internettets telefonbog, hvor et domæne slås op. SPF er beskrevet i RFC 7208 og har en teknisk grænse på ti DNS-opslag, som mange organisationer overskrider uden at vide det.

DKIM (DomainKeys Identified Mail) sætter en digital signatur på hver udgående mail. Modtageren henter den offentlige nøgle i jeres DNS og kontrollerer, at beskeden er ægte og uændret. DKIM er beskrevet i RFC 6376.

DMARC (Domain-based Message Authentication, Reporting and Conformance) binder de to første sammen med den adresse, læseren rent faktisk ser. Det kaldes alignment, altså at det domæne, SPF eller DKIM godkendte, skal svare til domænet i feltet Fra. DMARC er beskrevet i RFC 9989, udgivet i maj 2026, som afløser den tidligere RFC 7489.

En DMARC-politik har tre trin. Værdien p=none betyder kun overvågning, og posten leveres som hidtil. Værdien p=quarantine beder modtageren lægge post, der ikke består kontrollen, i spammappen. Værdien p=reject beder modtageren afvise den helt. Kun quarantine og reject beskytter.

Sådan virker løsningen teknisk, trin for trin

1. Kortlægning. Vi finder alle systemer, der sender mail i jeres navn, herunder mailplatform, økonomisystem, nyhedsbrev, booking og supportværktøj.
2. Grundopsætning. SPF og DKIM bringes i orden for hver kilde, og antallet af SPF-opslag holdes under grænsen på ti.
3. DMARC i overvågning. Der offentliggøres en DMARC-post med p=none og en rapportadresse, så modtagende systemer begynder at sende data tilbage.
4. Indsamling. Modtagere som Google, Microsoft og danske udbydere sender dagligt aggregerede rapporter i XML-format, beskrevet i RFC 9990.
5. Fortolkning. Rapporterne samles i én oversigt, der viser hver afsenderkilde, mængden af post og om SPF, DKIM og alignment består.
6. Oprydning. Legitime kilder, der fejler, bliver rettet, og ukendte kilder bliver afklaret eller afvist.
7. Stramning. Politikken hæves til p=quarantine og derefter til p=reject, når data viser, at jeres egen post er dækket.
8. Drift. Overvågningen fortsætter, fordi nye systemer og leverandører løbende kommer til.

Trinnene skal tages i rækkefølge. Springes trin fire til seks over, blokerer I jeres egen post i stedet for svindlerens.

Hvad Auroa konkret leverer

Auroa E-mail Skjold er vores egen platform til indsamling og fortolkning af DMARC-rapporter.

Omfattet af ydelsen:

• Kortlægning af alle afsenderkilder på de aftalte domæner
• Færdige DNS-poster til SPF, DKIM og DMARC, klar til indsætning
• Modtagelse og opbevaring af aggregerede DMARC-rapporter
• Løbende oversigt over afsenderkilder, godkendelsesgrad og politikstatus
• Besked når en ny, ukendt kilde begynder at sende i jeres navn
• Rådgivning ved hvert politikskift fra none til quarantine til reject
• Kontrol af SPF-opslagsgrænsen og af udløbne eller svage DKIM-nøgler
• Periodisk rapport i Auroas rapportformat, som kan lægges direkte i jeres ledelsesrapportering

Ikke omfattet:

• Ændringer i jeres DNS foretages ikke af os uden skriftlig aftale om adgang
• Beskyttelse mod indgående phishing, som håndteres af jeres mailfilter
• Beskyttelse mod lookalike-domæner, altså domæner der ligner jeres, men er registreret af andre
• Indholdsscanning, arkivering eller backup af e-mail
• Garantier for leveringsrate hos den enkelte modtager

Compliance-kobling

Ingen af nedenstående regelsæt nævner DMARC ved navn. De stiller krav om passende og risikobaserede foranstaltninger, og DMARC er en konkret, dokumenterbar foranstaltning inden for et af de mest udnyttede angrebsområder.

Styrelsen for Samfundssikkerhed anbefaler i vejledningen Reducer risikoen for falske mails, at organisationer implementerer DMARC, og at afsenderens DMARC-politik respekteres. Den amerikanske standardiseringsinstitution NIST anbefaler tilsvarende SPF, DKIM og DMARC i publikationen SP 800-177 Rev. 1, Trustworthy Email.

Onboarding og drift

Forløbet nedenfor er et typisk tidsforløb. Den faktiske varighed afhænger af, hvor mange systemer der sender mail i jeres navn.

1. Uge 1. Opstartsmøde, kortlægning af afsenderkilder og gennemgang af nuværende DNS-opsætning.
2. Uge 1 til 2. SPF og DKIM bringes i orden, og DMARC offentliggøres med p=none. Ingen post påvirkes.
3. Uge 2 til 6. Rapporter indsamles og fortolkes. Legitime kilder, der fejler, rettes én for én.
4. Uge 6 til 10. Politikken hæves til p=quarantine, når de kendte kilder består kontrollen.
5. Uge 10 til 16. Politikken hæves til p=reject. Domænet er nu beskyttet mod direkte misbrug.
6. Løbende. Overvågning, alarmer ved nye kilder og periodisk rapportering fortsætter.

Målbare resultater og KPI’er

Der måles en udgangsværdi ved opstart, og udviklingen følges derefter. Vi opfinder ikke måltal på forhånd, fordi de afhænger af jeres udgangspunkt.