Hvis dine forretningsmails ender i spam, mister du penge. Hvis de ender i spam, og du ikke ved det, mister du flere penge. Det er den ubehagelige sandhed bag de tre forkortelser, der står i overskriften: SPF, DKIM og DMARC. De er ikke spændende. De er ikke synlige i dagligdagen. Men de afgør, om dine ordrebekræftelser, fakturaer og kundesvar når frem til indbakken eller forsvinder i et filter.

Det er værd at forstå, hvad de tre standarder gør, hvorfor de hænger sammen, og hvordan en korrekt opsætning ser ud i praksis.

Problemet: e-mail er en åben protokol

SMTP, den protokol e-mail kører på, er fra 1982. Den blev designet i en tid, hvor netværket var lille og tilliden var høj. Der er ingen indbygget mekanisme til at verificere, at en mail rent faktisk kommer fra den server, den hævder at komme fra. En hvilken som helst mailserver på internettet kan teknisk set sende en mail, der ser ud til at komme fra `[email protected]`, og uden ekstra foranstaltninger har modtageren ingen mulighed for at afgøre, om det er ægte.

Det åbner for to typer misbrug. Spoofing, hvor en angriber sender en svindelmail i dit navn til dine kunder — typisk en falsk faktura eller et phishingforsøg. Og deliverability-problemer, hvor modtagende mailservere af samme grund er nødt til at være forsigtige med at stole på indkommende mail og derfor sender legitime mails i spam, hvis afsenderen ikke kan bevise sin identitet.

SPF, DKIM og DMARC løser dette ved at tilføje en autentificeringsmekanisme oven på SMTP. De ligger som DNS-records på dit domæne, og de fortæller modtagende mailservere, hvad der er gyldigt og hvad der ikke er.

SPF: Hvilke servere må sende mail i mit navn?

SPF (Sender Policy Framework) er den ældste af de tre. En SPF-record er en TXT-record på dit domæne, der lister, hvilke mailservere der har lov til at sende mail med dit domæne som afsender.

Et eksempel kunne være:

“` v=spf1 include:_spf.google.com include:sendgrid.net ~all “`

Det betyder: “Mail fra mit domæne må komme fra Google’s mailservere eller fra SendGrid. Alt andet er sandsynligvis falskt.”

Modtagende servere tjekker afsenderens IP-adresse mod SPF-recorden. Hvis IP’en er på listen, går mailen videre. Hvis ikke, kan den enten markeres som mistænkelig eller afvises helt — afhængigt af, hvor strikt afsendernes politik er sat.

Almindelige fejl med SPF:

– Glemte tjenester. Hver gang du tilføjer en ny mail-tjeneste — nyhedsbrev, CRM, fakturasystem — skal SPF opdateres. Hvis du glemmer det, ender dine mails fra den tjeneste i spam. – For mange include-statements. SPF har en grænse på 10 DNS-opslag. Hvis du inkluderer for mange tjenester, brydes opslaget, og hele SPF-checken fejler. – Manglende `~all` eller `-all`. Uden en eksplicit slutregel ved modtageren ikke, hvad den skal gøre med mail fra ukendte servere.

DKIM: En kryptografisk underskrift på hver mail

DKIM (DomainKeys Identified Mail) går et skridt videre end SPF. Den tilføjer en kryptografisk signatur til hver enkelt udgående mail, baseret på en privat nøgle hos afsenderens mailserver. Den tilhørende offentlige nøgle ligger i en DNS-record på afsenderens domæne.

Når en modtagende server modtager mailen, slår den den offentlige nøgle op via DNS, verificerer signaturen og bekræfter dermed to ting:

1. Mailen kommer faktisk fra dit domæne — ingen anden har kunnet underskrive den uden den private nøgle. 2. Mailen er ikke blevet ændret undervejs — hvis blot ét tegn i headeren eller body er ændret efter signering, fejler verifikationen.

Hvor SPF kun verificerer afsendende server, verificerer DKIM selve indholdet. De to standarder supplerer hinanden, og moderne mailsystemer forventer oftest at se begge.

DKIM aktiveres typisk hos din mailudbyder — Google Workspace, Microsoft 365, Mailgun og lignende har alle en proces, hvor du genererer nøglepar og indsætter den offentlige nøgle som en TXT-record på dit domæne.

DMARC: Hvad skal modtageren gøre, hvis noget fejler?

SPF og DKIM giver modtageren mulighed for at vurdere, om en mail er autentisk. Men de fortæller ikke, hvad der skal ske, hvis vurderingen fejler. Det er dér, DMARC (Domain-based Message Authentication, Reporting & Conformance) kommer ind.

En DMARC-record er en TXT-record, der ser sådan ud:

“` v=DMARC1; p=quarantine; rua=mailto:[email protected] “`

Den siger: “Hvis en mail i mit navn fejler både SPF og DKIM, så send den i karantæne (spam-mappen). Og send mig en daglig rapport over, hvor mange mails der er blevet vurderet, og hvilke der har fejlet.”

DMARC har tre primære politikker:

– `p=none` — vurder mailen, men gør ikke noget. Brug denne i begyndelsen til at samle data uden at risikere at blokere legitime mails. – `p=quarantine` — send mails der fejler i spam-mappen. – `p=reject` — afvis mails der fejler helt. Den strengeste indstilling.

Den vigtigste del af DMARC er rapporteringen. Når du sætter `rua=` til en mailadresse, modtager du daglige aggregerede rapporter fra alle store modtagere (Google, Microsoft, Yahoo m.fl.) med statistik over, hvilke mails der er blevet sendt i dit navn, og om de er blevet godkendt. Det er den mest effektive måde at finde ud af, om nogen forsøger at sende mail i dit navn — og om dine egne tjenester er korrekt konfigureret.

En typisk implementeringsrejse

Når en virksomhed for første gang sætter SPF, DKIM og DMARC op, ser processen oftest sådan ud:

1. Sæt SPF op med alle kendte mail-tjenester. Test med en SPF-checker, før du går videre. 2. Aktivér DKIM hos din primære mailudbyder. Verificer signaturen ved at sende en test-mail til en Gmail-konto og tjekke headers. 3. Sæt DMARC op med `p=none` og en rua-rapporteringsadresse. Modtag rapporter i 2-4 uger. 4. Analyser rapporterne for at finde mail-tjenester, du har glemt at inkludere i SPF. 5. Stram politikken til `p=quarantine` og senere til `p=reject`, når du er sikker på, at alle legitime mails passerer.

Det er ikke en proces, der bliver færdig på en time. Men den er lineær, den er målbar, og den giver et synligt resultat: dine mails ender i indbakken oftere, og dit domæne kan ikke længere bruges til phishing rettet mod dine kunder.

Det praktiske spørgsmål: hvor sætter jeg det op?

Selve DNS-records — SPF, DKIM, DMARC — sættes op i din domæne-administration, ikke hos din mailudbyder. Det betyder, at du har brug for en udbyder, der giver dig fuld adgang til at oprette og redigere TXT-records direkte. Hos Netsite kan alle tre records oprettes fra det samme kontrolpanel, og DNS-ændringer træder i kraft uden ventetid.

E-mail-autentificering er ikke valgfrit længere. Google og Yahoo har siden 2024 krævet både SPF, DKIM og DMARC af afsendere, der sender mere end 5.000 mails om dagen — og kravene strammes løbende. For en virksomhed, der lever af, at dens mails kommer frem, er den investering, det kræver at få de tre standarder rigtigt sat op, en af de mest værdifulde, du kan lave i dit DNS-setup.