E-mailgodkendelse: SPF, DKIM og DMARC

SPF har to væsentlige begrænsninger. For det første ødelægger videresendelse SPF: Når en e-mail videresendes, står den videresendende servers IP-adresse ikke i det oprindelige domænes SPF-post, hvilket får SPF til at mislykkes for legitimt videresendt e-mail. For det andet godkender SPF kun konvolutten Fra (usynlig for brugerne), ikke Fra-headeren, som er synlig i e-mailklienter. Angribere kan stadig forfalske den synlige Fra-header, mens de bruger en SPF-godkendt konvolutten Fra — derfor er SPF alene utilstrækkelig. DKIM og DMARC løser disse mangler.

DKIM føjer en kryptografisk signatur til udgående e-mails. Den sendende mailserver bruger en privat nøgle til at signere bestemte e-mailheadere og meddelelsens brødtekst og tilføjer en DKIM-Signature-header. Den offentlige nøgle offentliggøres som en DNS TXT-post under et selectorsubdomæne. Modtagende servere henter den offentlige nøgle og verificerer signaturen, hvilket bekræfter, at e-mailen ikke er blevet ændret under transporten, og at den stammer fra en server med adgang til den private nøgle. I modsætning til SPF overlever DKIM-signaturer videresendelse, fordi de følger med i e-mailens headere.

DKIM bruger selectorer, så et domæne kan have flere offentlige nøgler aktive samtidig — nyttigt ved brug af flere mailtjenester (Google Workspace + en marketingplatform) eller ved nøgleudskiftning uden afbrydelser. Selectornavnet er inkluderet i DKIM-Signature-headeren, så modtagende servere ved, hvilken DNS-post de skal forespørge. Organisationer bør udskifte DKIM-nøgler årligt eller når der er mistanke om, at en nøgle er kompromitteret. Nøglelængde: RSA-nøgler på mindst 2048 bit anbefales; nøgler på 1024 bit er forældede og kan brydes med moderne computerkraft.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) bygger videre på SPF og DKIM ved at tilføje: et justeringstjek (domænet i den synlige Fra-header skal stemme overens med det SPF- eller DKIM-godkendte domæne) og en politik, der fortæller modtagende servere, hvad de skal gøre, når meddelelser ikke består kontrollen. DMARC-politikkerne er none (kun overvågning), quarantine (lever til spam-mappen) eller reject (lever ikke). DMARC muliggør også samlede rapporter (RUA) og forensiske rapporter (RUF), der sendes tilbage til domæneejeren, så denne kan se, hvem der sender på dennes vegne.

Justering er det, der gør DMARC effektiv mod forfalskning af headere. Ved SPF-justering skal domænet i SMTP-konvoluttens From-felt matche domænet i den synlige From-header. Ved DKIM-justering skal signeringsdomænet (d= i DKIM-Signature) matche domænet i From-headeren. I streng tilstand skal domænerne matche nøjagtigt. I afslappet tilstand accepteres underdomæner. En e-mail består DMARC, hvis den består SPF ELLER DKIM med korrekt justering — den behøver ikke bestå begge. Kombinationen lukker det smuthul, som SPF alene efterlader ved forfalskning af synlige headere.

Organisationer bør implementere DMARC trinvist for at undgå at forstyrre legitim e-mail. Fase 1: Implementér SPF og DKIM for alle mailstrømme. Fase 2: Udgiv en DMARC-post med p=none og RUA-rapportering. Analysér rapporterne (værktøjer: DMARC Analyzer, dmarcian) for at finde alle legitime afsendere over 2-4 uger. Fase 3: Skift til p=quarantine; pct=10, og øg gradvist pct til 100 %. Fase 4: Skift til p=reject, når alle legitime mailstrømme består kontrollen. Hvis du skifter til reject, før du har fundet alle mailstrømme, bliver legitim e-mail afvist.

BIMI er en ny standard, der bygger videre på DMARC. Når et domæne har en DMARC-politik på quarantine eller reject, kan e-mailklienter (Gmail, Apple Mail) vise brandets verificerede logo ved siden af afsenderens navn i indbakken. BIMI kræver et Verified Mark Certificate (VMC) fra en godkendt udsteder, som bekræfter ejerskab af varemærket. BIMI er endnu ikke med på Security+-eksamen, men viser retningen for e-mailgodkendelse — verificerede afsendere bliver visuelt lette at skelne fra forfalskede afsendere.

De tre standarder udgør et komplet system til e-mailgodkendelse. SPF verificerer, at den afsendende server er godkendt af domæneejeren. DKIM verificerer meddelelsens integritet og, at den afsendende organisation har den private nøgle. DMARC knytter begge dele til den synlige From-header, håndhæver en politik ved fejl og leverer rapportering. Ingen enkelt standard er tilstrækkelig: SPF alene kan ikke forhindre forfalskning af den synlige header, DKIM alene kræver ikke afvisning ved fejl, og DMARC alene uden SPF eller DKIM har intet at kontrollere. Alle tre skal implementeres sammen for at give fuld beskyttelse mod forfalskning af domæner.

Et praktisk forsvar i dybden mod phishing og BEC er at tilføje et advarselsbanner for eksterne e-mails til alle meddelelser, der kommer udefra organisationen. Dette banner — som typisk indsættes af SEG'en — gør medarbejderne opmærksomme på, at en e-mail kommer fra en ekstern afsender, selv når det viste navn ser ud til at tilhøre en kollega eller leder. Bannere er særligt effektive til at markere BEC-forsøg, hvor angriberen bruger et domæne, der ligner det rigtige, eller forfalsker det viste navn. Banneret bør være visuelt tydeligt (en farvet top- eller bundtekst) og indeholde instruktioner til rapportering af mistænkelige meddelelser.

I denne lektion lærte du, at SPF bruger DNS TXT-poster til at godkende afsendende IP-adresser, men kun kontrollerer konvoluttens From-felt og ikke den synlige header, at DKIM tilføjer kryptografiske signaturer, som verificerer meddelelsens integritet og overlever videresendelse, og at DMARC knytter SPF og DKIM til den synlige From-header med justeringskontroller og en håndhævelig politik (none/quarantine/reject) samt rapportering. Næste emne er sikre e-mail-gateways og antispamkontroller.