SPF, DKIM og DMARC er tre DNS-records, der afgør to ting: om den e-mail, du sender, når frem til indbakken, og om andre kan sende e-mail, der ser ud til at komme fra dig. Gmail, Yahoo og Outlook.com kræver nu alle tre af alle, der sender i store mængder, og for alle andre er der større risiko for, at beskeder uden dem havner i spam.
Recordsene er korte, men det er let at få dem en smule forkert, og de går i stykker uden varsel, når et nyt værktøj begynder at sende for dig. Denne guide forklarer, hvad hver af dem gør, hvordan du sætter dem op i den rigtige rækkefølge, og hvordan du holder dem fungerende.
Sådan hænger de sammen
Hver e-mail har to afsenderadresser: envelope-afsenderen, som mailservere bruger til at returnere bounces, og From-adressen, som modtageren ser. Svindel udnytter forskellen mellem dem: Alle kan skrive en hvilken som helst From-adresse. De tre records lukker det hul.
SPF (Sender Policy Framework) angiver de servere, der må sende mail for dit domæne.
DKIM (DomainKeys Identified Mail) tilføjer en kryptografisk signatur til hver besked, som modtagerne verificerer mod en offentlig nøgle i din DNS.
DMARC (Domain-based Message Authentication, Reporting and Conformance) knytter dem til den synlige From-adresse og fortæller modtagerne, hvad de skal gøre med mail, der fejler.
SPF: hvem må sende
En SPF-record er en TXT-record på dit domæne. Den angiver de tjenester og servere, der sender mail for dig, og slutter med, hvad der skal ske med alt andet:
example.com. TXT “v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 ~all”
include: tilføjer et andet domænes SPF-record. Det er den almindelige måde at tillade en mailtjeneste på.
ip4: og ip6: tillader bestemte adresser, f.eks. din egen mailserver.
~all (soft fail) eller -all (fail) angiver, hvad der sker med alle, der ikke står på listen. Brug aldrig +all, som tillader hele internettet.
To regler er dem, de fleste domæner falder over:
Kun én record. Et domæne skal have præcis én SPF-record. Med to returnerer modtagerne en permanent fejl, og SPF fejler for hver eneste besked. Når en ny tjeneste beder dig “tilføje denne SPF-record”, skal du i stedet tilføje dens include til den record, du allerede har.
Højst 10 DNS-opslag. Hver include, a, mx og redirect koster et opslag, og includes inde i includes tæller også. Over 10 fejler SPF. En record med Google Workspace, et nyhedsbrevsværktøj, et CRM og et helpdesksystem kan krydse grænsen, uden at nogen opdager det.
SPF har en svaghed: Den tjekker envelope-afsenderen, ikke den From-adresse, modtageren ser, og den går i stykker, når mail videresendes. Derfor er den ikke nok alene.
DKIM: en signatur på hver besked
Med DKIM signerer din mailtjeneste hver besked med en privat nøgle. Den offentlige nøgle ligger i DNS under et navn, der kaldes en selector:
google._domainkey.example.com. TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…”
Modtageren læser selectoren fra beskedens DKIM-Signature-header, slår nøglen op og tjekker, at beskeden ikke er blevet ændret undervejs. En DKIM-signatur overlever videresendelse, og det gør den til den mest pålidelige af de to.
Hver tjeneste, der sender for dig, skal have sin egen DKIM-opsætning, som regel i dens administrationsindstillinger under “authentication” eller “verified domain”. Brug 2048-bit-nøgler, hvor tjenesten tilbyder dem. 1024-bit-nøgler virker stadig, men er minimum, og kortere nøgler afvises. Når en tjeneste roterer sine nøgler, skal den nye selector ligge i din DNS, før den tages i brug, ellers fejler signaturerne.
DMARC: knyt det til From-adressen
DMARC er en TXT-record på _dmarc på dit domæne:
_dmarc.example.com. TXT “v=DMARC1; p=none; rua=mailto:dmarc@example.com”
Den gør to ting, som SPF og DKIM ikke kan alene.
For det første kræver den alignment. En besked består kun DMARC, når SPF eller DKIM består for det samme domæne som den synlige From-adresse. Et nyhedsbrev, der sendes via en tjeneste, som signerer med sit eget domæne, består DKIM, men ikke for dit domæne, og fejler derfor DMARC. Det er derfor, hver tjeneste skal signere med dit domæne.
For det andet fastsætter den en politik for mail, der fejler:
p=none: Lever den som normalt. Intet ændrer sig, men modtagerne kan sende dig rapporter.
p=quarantine: Læg den i spam.
p=reject: Afvis den.
Tagget rua beder modtagerne sende daglige samlede rapporter til en adresse, du vælger. De viser, hvilke servere der har sendt mail som dit domæne, og om den bestod. Sådan finder du afsendere, du havde glemt.
Sæt dem op i den rigtige rækkefølge
At gå direkte til p=reject er den klassiske måde at forhindre dine egne fakturaer eller nulstillinger af adgangskoder i at nå frem på. Gør det i trin:
Lav en liste over alt, der sender som dit domæne. Din mailudbyder, dit nyhedsbrevsværktøj, CRM, helpdesk, bookingsystem, din e-handelsplatform, kontaktformularen på dit website og alle servere, der sender notifikationer.
Sæt DKIM op for hver af dem med dit eget domæne, efter hver tjenestes vejledning.
Byg én SPF-record med de tjenester, der har brug for den, under 10 opslag og med ~all til sidst.
Udgiv DMARC med p=none og en rua-adresse, og lad den stå i to til fire uger.
Ret alle legitime afsendere, der fejler, som regel en tjeneste, der stadig signerer med sit eget domæne.
Gå over til p=quarantine, eventuelt med pct=25 for at starte med en fjerdedel af den mail, der fejler, og derefter til p=reject, når intet legitimt fejler længere.
Domæner, der aldrig sender e-mail, fortjener også beskyttelse, for de er lette at forfalske. Giv dem en record, der siger netop det:
example.org. TXT “v=spf1 -all”
_dmarc.example.org. TXT “v=DMARC1; p=reject”
Fejl, der i al stilhed ødelægger e-mail
En ekstra SPF-record tilføjet for en ny tjeneste i stedet for en include i den første.
En SPF-record, der voksede ud over 10 opslag, da endnu et værktøj kom til.
Et nyhedsbrev eller CRM, der sender med sit eget DKIM-domæne, så DMARC fejler trods en gyldig signatur.
En DKIM-nøgle, der er roteret hos udbyderen, men aldrig udgivet i DNS.
En DMARC-record med en tastefejl, f.eks. p=rejected, som modtagerne ignorerer.
At gå over til p=reject, før du har tjekket, at alle afsendere består.
En ændret MX-record eller en mailserver, der havner på en blokeringsliste, hvilket skader leveringen uanset recordsene.
Ingen af dem giver en fejl, du ville lægge mærke til. Mailen begynder bare at havne i spam, og du hører om det uger senere, når en kunde siger, at de aldrig fik fakturaen.
Tjek dine records
Du kan tjekke dit domæne lige nu med vores gratis SPF-, DKIM- og DMARC-checker. Den læser recordsene fra DNS, tæller SPF’s opslag, leder efter DKIM-nøgler ved almindelige selectors og forklarer, hvad du skal rette, med den record, du skal indsætte.
Records, der er rigtige i dag, går i stykker, når nogen tilføjer en tjeneste næste måned. Uptimechecks overvågning af e-mailgodkendelse tjekker SPF, DKIM og DMARC på dine domænemonitorer to gange om dagen, forklarer hvert problem i et klart sprog, giver dig den DNS-record, der løser det, og alarmerer dig kun, når et nyt problem dukker op. Den slår også de mailservere, du selv driver, op på blokeringslister, så en listning ikke går ubemærket hen. Føj det til den domæneovervågning, der allerede giver dig besked, før selve domænet udløber.
Tjekliste
Lav en liste over alle tjenester, der sender e-mail som dit domæne.
Sæt DKIM op med dit eget domæne i hver af dem, med 2048 bit, hvor det er muligt.
Hold dig til én SPF-record under 10 opslag, der slutter med ~all eller -all.
Udgiv DMARC med p=none og en rapportadresse.
Ret alle legitime afsendere, der fejler alignment.
Gå over til p=quarantine og derefter p=reject.
Beskyt domæner, der ikke sender, med v=spf1 -all og p=reject.
Tjek recordsene jævnligt og hver gang et nyt værktøj begynder at sende for dig.