Vad är DKIM? E-postautentiseringsstandarden förklarad

DKIM (DomainKeys Identified Mail) är ett kryptografiskt autentiseringsprotokoll för e-post. Vad är DKIM i praktiken: det kopplar en RSA-signatur till varje utgående meddelande som din e-postserver skickar. Den mottagande MTA:n hämtar din offentliga nyckel från DNS, verifierar den signaturen och rapporterar resultatet som dkim=pass eller dkim=fail. Det resultatet matar din domäns ryktesmodell och avgör om DMARC-anpassning håller. Utan en giltig signatur har den mottagande MTA:n ingen kryptografisk bekräftelse att meddelandet kom från din infrastruktur. DKIM, SPF och DMARC bildar tillsammans ett robust autentiseringsskikt. Att implementera alla tre är standardkravet för seriös e-postinfrastruktur under 2026, oavsett sändvolym.

DKIM är ett signeringsprotokoll, inte ett filter

Namnet ger upphov till ett vanligt missförstånd. DKIM blockerar inte e-post. Det karantänlägger inte meddelanden och tillämpar inte heller någon policy på egen hand. Vad det gör är att stämpla varje utgående meddelande med ett verifierbart anspråk: det här meddelandet signerades av domänen i fältet d=, med den privata nyckeln som motsvarar selektorn s=.

Den mottagande MTA:n tar det anspråket, konstruerar en DNS-förfrågan till <selektor>._domainkey.<domän>, hämtar TXT-posten som innehåller den offentliga nyckeln och kör den kryptografiska verifieringen. Om verifieringen lyckas visar autentiseringsresultathuvudet dkim=pass. Om den misslyckas ser du dkim=fail eller dkim=temperror.

Inget av dessa utfall orsakar avvisning i sig. Signalen matar mottagarserverns ryktesmodell och, avgörande, DMARC-utvärderingen. DKIM:s uppgift är att producera ett verifierbart resultat, inte agera på det.

Vad som signeras och vad signaturen täcker

DKIM signerar två saker: valda meddelandehuvuden och meddelandetexten. Signeringsalgoritmen hashar båda och lagrar resultatet i huvud-fältet DKIM-Signature.

Huvudlistan styrs av taggen h= i signaturen. En typisk produktionskonfiguration inkluderar from:subject:date:message-id:content-type. Huvudet from är det relevanta för DMARC-anpassning. Texthash täcker hela meddelandetexten, kanoniserad via antingen simple eller relaxed.

Relaxed-kanonisering är det de flesta produktionsstackar använder. Den normaliserar blanksteg innan hashning, vilket gör att signaturen kan överleva mindre omformatering av relay-MTA:er. Simple är striktare: en enda förändring av avslutande blanksteg bryter signaturen. Du ser c=relaxed/relaxed i DKIM-Signature-fältet hos praktiskt taget varje välkonfigurerad ESP.

Vad DKIM inte signerar: SMTP-kuvertsändaren, routinghuvuden som Received och vilka huvuden som helst utanför h=-listan. Detta är avsiktligt. Att signera kuvertet skulle bryta vidarebefordransscenarier, vilket är precis där DKIM:s fördel över SPF kommer ifrån.

Selektorn: en åtkomstkontrollmekanism som de flesta behandlar som en etikett

Selektorn är den del av DKIM som de flesta team underskattar tills de behöver rotera nycklar under press.

Fältet s= i din DKIM-Signature pekar på en specifik offentlig nyckel i DNS. Uppslagsformatet är <selektor>._domainkey.<dindomän.com>. Om din selektor är mail2026 och din domän är example.com letar resolvern efter en TXT-post på mail2026._domainkey.example.com.

En enda domän kan ha flera aktiva selektorer samtidigt. Varje sändningstjänst, varje ESP, varje intern MTA bör använda sin egen selektor. Detta ger tre konkreta operativa möjligheter:

• Oberoende nyckelrotation per tjänst utan att påverka andra avsändare.

• Spårbar attribution i autentiseringsloggar: selektorn talar om vilken signeringsnyckel som användes för ett givet meddelande.

• Ren avveckling: ta bort selektor-DNS-posten och den ESP:n kan inte längre signera som din domän oavsett vad de gör på sin sida.

Det vi observerar i spårloggarna: team som konfigurerar en delad selektor för alla sändningstjänster kan inte återkalla åtkomst för en enda avsändare utan att störa dem alla. Selektorn är inte dekorativ. Det är en åtkomstkontrollmekanism.

DKIM och DMARC-anpassning: hur tillämningsskiktet faktiskt fungerar

Att DKIM godkänns är en förutsättning för en specifik typ av DMARC-godkännande kallat DKIM-anpassning.

DMARC kräver minst ett av två anpassningsvillkor: SPF-anpassning eller DKIM-anpassning. DKIM-anpassning innebär att domänen i From:-huvudet matchar d=-värdet i DKIM-signaturen och signaturen verifieras. När båda villkoren gäller anser DMARC att meddelandet är autentiserat.

Det är därför DKIM är den mer hållbara autentiseringssignalen. SPF-anpassning bryter vid vidarebefordran: när ett meddelande vidarebefordras ändras SMTP-kuvertsändaren och SPF-utvärdering misslyckas mot den nya sändar-IP:n. DKIM-anpassning överlever vidarebefordran eftersom signaturen och From:-huvudet följer med meddelandetexten och inte skrivs om av relay-MTA:er, förutsatt att meddelandetexten inte modifieras i transit.

För domäner med en DMARC-policy p=reject avvisas ett meddelande som misslyckas med både SPF- och DKIM-anpassning av den mottagande MTA:n. Det är mekanismen som stoppar förfalskad e-post från din domän från att nå inkorgar i stor skala. DKIM är inte sista försvarslinjen här. Men det är den linjen som håller när vidarebefordran finns i vägen.

Sedan 2024 kräver Google, Yahoo och Microsoft DKIM för massakörsändare som skickar 5 000 eller fler meddelanden per dag till deras MX. Meddelanden från osignerade domäner dirigeras till skräppost eller avvisas som standard.

Det här är inte en marknadsföringsfunktion. Det är en infrastrukturbegränsning.

Nyckellängd och rotation: praktiska beslut för 2026

De flesta DKIM-implementationer använder RSA-SHA256. Nyckelfrågan är nyckellängden.

RSA-nycklar på 1024 bitar förekommer fortfarande i äldre konfigurationer. NIST avvecklade 1024-bitars RSA för de flesta användningsfall 2015. En 2048-bitarsnyckel ger avsevärt starkare marginal och stöds av alla större MTA:er och mottagande leverantörer. Om du genererar en ny nyckel idag, använd 2048 bitar.

Vissa team har migrerat sin aktiva signeringsnyckel till 2048 bitar men lämnat kvar gamla 1024-bitarsselektorer publicerade i DNS eftersom ingen granskade lagret. Tre signaler som ändrar systemets beteende: om du ser k=rsa med en 1024-bitarsnyckel i en gammal selektor är den selektorn en sårbarhet även om din nuvarande signeringsinfrastruktur redan har gjort övergången. En giltig men avvecklad selektor är exploaterbar.

Nyckelrotationsschema: de flesta infrastrukturteam roterar årligen, vissa kvartalsvis för känsligare domäner. Ordningsföljden spelar roll:

• Generera ett nytt nyckelpar.

• Publicera den nya offentliga nyckeln under ett nytt selektornamn i DNS.

• Vänta på TTL-spridning, vanligtvis 24 till 48 timmar för poster med lågt TTL.

• Byt signeringsnyckeln i din MTA-konfiguration till den nya selektorn.

• Verifiera DKIM-godkännande på utgående meddelanden via ett testverktyg för e-post eller genom att inspektera autentiseringsresultathuvudena på ett testmeddelande.

• Ta bort den gamla DNS-posten efter att ha bekräftat att den nya nyckeln är aktiv och signerar korrekt.

Rotationen är icke-störande om du följer ordningen: DNS först, signeringsbyte sedan, borttagning av gammal post sist. Att byta steg 4 och 6 orsakar ett dkim=fail-fönster.

Operativa signaler att spåra efter DKIM-konfiguration

DKIM är inte en engångskonfigurationsuppgift. Följande signaler indikerar att något har ändrats eller gått sönder.

dkim=temperror i mottagna huvuden. Tillfälliga fel indikerar vanligtvis DNS-slagproblem på mottagarsidan, eller en TTL-mismatch under nyckelrotation. Om du ser detta på utgående meddelanden strax efter en nyckelrotation, vänta på full spridning innan du drar slutsatsen att nyckeln i sig är felkonfigurerad.

dkim=fail på meddelanden du skickade. Textkroppsmodifiering av ett mellanlägssrelä är den vanligaste orsaken. Kontrollera om ett vidarebefordranshopp, en e-postlisteprocessor eller ett sidfot-injicerande relä finns i leveransvägen. Om felet är konsekvent på ett enda flöde, kartlägg reläkedjan hopp för hopp.

Saknad DKIM-Signature-huvud helt. Signeringsdaemonen på din MTA körs inte, signeringsnyckelns sökväg är fel, eller domänselektor-mappningen är felkonfigurerad i din MTA-konfiguration. Det här är ett fullständigt DKIM-avbrott för berörda meddelandeflöden.

Selektor-TXT-post saknas från DNS. DNS-zonen redigerades eller migrerades utan att DKIM-selektor-posten bevarades. Verifiera med dig TXT <selektor>._domainkey.<domän> från en extern resolver.

I en sändningskonfiguration för flera regioner orsakas inkonsekventa DKIM-resultat över noder ofta av att olika noder använder olika selektorkonfigurationer. Bekräfta att signeringsnyckelkonfigurationen är synkroniserad över alla sändnoder innan du distribuerar en rotation.

Det är viktigt att förstå att DKIM-konfiguration inte är en engångsåtgärd. Infrastruktur förändras: nya ESP:er läggs till, gamla fasas ut, och nycklar åldras. Varje förändring i sändningsinfrastrukturen bör utlösa en granskning av DKIM-selektorkonfigurationen. Automatiserade tester som verifierar dkim=pass på utgående testmeddelanden kan integreras i CI/CD-pipelines för att fånga regressioner innan de påverkar produktionstrafik. Verktygen MXToolbox och mail-tester.com erbjuder snabb diagnostik utan att du behöver analysera råa e-posthuvuden manuellt.

Ytterligare en praktisk aspekt: om din organisation använder flera e-postleverantörer för olika ändamål, till exempel transaktionell e-post via en API-tjänst och marknadsföring via en annan plattform, behöver varje leverantör sin egen DKIM-selektor publicerad i DNS. Utan detta kan du inte spåra vilken leverantör som orsakar autentiseringsfel, och du kan inte avveckla en leverantörs åtkomst utan att påverka de andra.

Vad DKIM inte skyddar mot

DKIM är inte ett skräppostfilter. En avsändare kan registrera en ny domän, konfigurera giltig DKIM och skicka fullständigt autentiserat skräppost. Signaturen verifieras rent. Autentisering bekräftar ursprung, inte avsikt eller innehållskvalitet.

DKIM adresserar heller inte spoofing av visningsnamn, där From:-huvudet visar ett betrott namn som "Löneavdelningen" ihopkopplat med en domän som angriparen kontrollerar. Den kryptografiska verifieringen verkar på domänen, inte den visuella presentationen i MUA:en. De flesta nätfiskeförsök på MUA-nivå förlitar sig på visningsnamnsbedrägerier snarare än exakt domänspoofing.

Vad DKIM skyddar mot: exakt domänspoofing, där en angripare försöker skicka som din domän utan att ha din privata nyckel. I kombination med en DMARC-policy p=reject som tillämpar DKIM-anpassning förhindrar detta att den klassen av förfalskade meddelanden når inkorgar hos mottagande leverantörer som tillämpar DMARC.

En praktisk notering: DKIM ensamt räcker inte. Skyddsmodellen kräver DMARC-policytillämpning vid den mottagande MTA:n. DKIM är autentiseringslagret som gör DMARC meningsfullt. SPF är det andra autentiseringslagret och hanterar kuvertsändarverifiering. Alla tre arbetar tillsammans. Frånvaron av någon av dem lämnar ett gap i tillämningskedjan.

Om du redan har konfigurerat DKIM och SPF men ännu inte publicerat en DMARC-post finns signaturerna men ingen tillämningspolicy är aktiv. Övervakningsläge (p=none med rua-rapportering) är ett rimligt första steg: du får aggregerade rapporter som visar autentiseringsresultat för din sändardomän innan du förbinder dig till p=quarantine eller p=reject. Det är infrastrukturens grundkrav.