SPF og DKIM er de to DNS-records der lader modtagende mailservere tjekke om en besked reelt kom fra dit domæne. Begge er gratis at sætte op — og lette at få en lille smule forkert.

Sammen udgør de fundamentet som DMARC bygger på: SPF siger hvilke servere der må sende for dit domæne, DKIM beviser at en besked er signeret af dit domæne og ikke ændret undervejs. Denne guide dækker hvad hver record gør, hvordan en korrekt record ser ud, de grænser du skal kende — og hvordan du verificerer resultatet.

Hvad SPF gør

SPF (Sender Policy Framework) er en TXT-record på dit domæne, som lister de servere der må sende e-mail på dets vegne. Når en mailserver modtager en besked der hævder at komme fra dit domæne, slår den recorden op og tjekker om den afsendende servers IP-adresse står på listen. En typisk record ser sådan ud:

example.com.  TXT  "v=spf1 include:_spf.mailprovider.example ip4:203.0.113.10 -all"

Læst fra venstre mod højre:

  • v=spf1 — identificerer recorden som SPF.
  • include:_spf.mailprovider.example — trækker afsenderlisten ind fra en tredjepartsudbyder, fx din hostede e-mail eller nyhedsbrevsplatform. Én include pr. udbyder der sender for dig.
  • ip4:203.0.113.10 — autoriserer en bestemt server du selv driver, fx en applikationsserver der sender transaktionsmail.
  • -all — siger at enhver afsender der ikke står på listen, skal fejle tjekket. Alternativet ~all (softfail) markerer ulistede afsendere som mistænkelige i stedet for at fejle dem direkte.

Hvad DKIM gør

DKIM (DomainKeys Identified Mail) sætter en kryptografisk signatur på hver udgående besked. Dit afsendersystem signerer beskeden med en privat nøgle; den tilhørende offentlige nøgle offentliggøres i DNS, hvor enhver modtagende server kan hente den og verificere både at beskeden kom fra et system med din nøgle, og at den ikke er blevet ændret undervejs.

Den offentlige nøgle ligger i en TXT-record under en selector — et navn der lader ét domæne have flere nøgler, én pr. afsendertjeneste:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…"

I praksis genererer du sjældent den her i hånden. Din e-mail-udbyder genererer nøgleparret, opbevarer den private nøgle og fortæller dig præcis hvilken record du skal offentliggøre — ofte som en CNAME der peger på en record udbyderen selv vedligeholder, så de kan rotere nøgler uden at involvere dig. Hver tjeneste der sender for dig (mailbox-udbyder, nyhedsbrevsværktøj, CRM), får sin egen selector, så én lækket eller udfaset nøgle aldrig rammer de andre.

SPF-grænsen på 10 DNS-opslag

SPF har en hård grænse der fanger mange organisationer: evaluering af en record må højst udløse 10 DNS-opslag. Mekanismer der kræver et opslag — include, a, mx, ptr, exists og redirect — tæller alle med, og afgørende nok tæller indlejrede includes også. Én include for en stor udbyder kan selv indeholde flere.

Overskrider du grænsen, returnerer tjekket en permanent fejl (permerror), som mange modtagere behandler som en fejlet autentificering — og så begynder din legitime mail at fejle, netop fordi du autoriserede for mange tjenester. Er din record tæt på grænsen: fjern includes for tjenester I ikke længere bruger, foretræk ip4:-/ip6:-poster hvor adresserne er stabile (de koster ingen opslag), og drop ptr, som alligevel er udfaset.

Typiske fejl

  • To SPF-records. Et domæne skal have præcis én SPF-record. Offentliggør du en nummer to — typisk når et nyt værktøj kommer til — returnerer evalueringen en fejl, og begge records holder op med at virke. Flet i stedet alle mekanismer sammen i én record.
  • At forveksle ~all og -all. ~all beder modtagerne behandle ulistede afsendere med mistanke; -all beder dem fejle dem. Under udrulningen er ~all det tilgivende valg; når afsenderlisten er komplet og DMARC leverer håndhævelseslaget, betyder forskellen mindre end de fleste forventer — alignment og politik trækker det tunge læs.
  • At slutte med +all. Det autoriserer hele internettet til at sende som dit domæne og gør recorden værre end ubrugelig.
  • At glemme en afsender. Helpdesk-, fakturerings-, CRM- og marketingplatforme sender alle som dit domæne. Enhver tjeneste der mangler i SPF og ikke har sin egen DKIM-selector, fejler autentificeringen — som regel opdaget når en kunde fortæller at jeres fakturaer lander i spam.
  • Ødelagt copy-paste. DKIM-nøgler er lange, og DNS-værktøjer deler TXT-værdier over 255 tegn på hver sin måde. Løse anførselstegn, mellemrum eller en afkortet nøgle giver en record der ser rigtig ud og aldrig validerer.
  • Sæt-og-glem. Udbydere ændrer deres afsender-infrastruktur, nøgler bør roteres, og værktøjer kommer til og udfases. Records der var korrekte sidste år, glider stille ud af trit.

Sådan verificerer du dit setup

Tre tjek, med stigende grad af sikkerhed:

  1. Slå dine records op. dig TXT example.com skal returnere præcis én SPF-record; dig TXT selector1._domainkey.example.com skal returnere den DKIM-nøgle din udbyder gav dig.
  2. Send en rigtig besked. Send en e-mail til en postkasse du kontrollerer hos en stor udbyder, og se de rå headers. Authentication-Results-headeren viser dommen: du vil se spf=pass og dkim=pass, begge for dit eget domæne.
  3. Følg de aggregerede rapporter. Én testbesked beviser at én sti virker. Aggregerede DMARC-rapporter viser om hver kilde der sender som dit domæne, består — hver dag, inklusive de tjenester du havde glemt. Se hvad er DMARC for hvordan rapporterne fungerer.

Hvor MailControl passer ind

MailControl overvåger SPF, DKIM, DMARC, MX, BIMI, MTA-STS og TLS-RPT for hvert af dine domæner i ét samlet mail-sundhedsbillede, så en record der går i stykker eller glider ud af trit, bliver opdaget før din leveringsevne gør. DNS-setup-guiden giver dig records klar til at kopiere for den moderne trio — DMARC, MTA-STS og TLS-RPT — og indlæsningen af aggregerede DMARC-rapporter viser om din SPF og DKIM faktisk består ude i virkeligheden, afsender for afsender. En DNSBL-listning (blacklist) mailer dig omgående.

Kan et domæne have to SPF-records?

Nej. Et domæne skal offentliggøre præcis én SPF-record; finder en modtagende server mere end én, returnerer evalueringen en permanent fejl, og autentificeringen fejler. Når du tilføjer en ny afsendertjeneste, så flet dens mekanisme ind i din eksisterende record i stedet for at oprette en record nummer to.

Skal SPF slutte med ~all eller -all?

Brug ~all (softfail) mens du stadig kortlægger hvilke tjenester der sender som dit domæne, og overvej -all når afsenderlisten er komplet. Offentliggør domænet også en håndhævende DMARC-politik, er den praktiske forskel lille, for DMARC-alignment og -politik afgør hvad der sker med fejlende mail.

Hvordan tjekker jeg om DKIM virker?

Send en e-mail til en postkasse du kontrollerer hos en stor udbyder, og undersøg de rå besked-headers. Authentication-Results-headeren skal vise dkim=pass med dit domæne. Du kan også bekræfte at den offentlige nøgle er offentliggjort, ved at slå selector-recorden op, fx selector1._domainkey.example.com, som et TXT-opslag.

Går SPF i stykker når e-mail videresendes?

Ofte, ja. Når en besked videresendes, ankommer den til den endelige destination fra videresenderens server, som ikke står i det oprindelige domænes SPF-record, så SPF-tjekket fejler. DKIM overlever som regel videresendelse, fordi signaturen rejser med beskeden — en af hovedgrundene til at sætte begge mekanismer op frem for at forlade sig på SPF alene.

Start gratis Udforsk MailControl