# Vad är DKIM? E-postautentiseringsstandarden förklarad URL: https://notificationharbor.com/sv/journal/vad-ar-dkim Type: blog Locale: sv Published: 2026-09-08 Updated: 2026-09-09 --- > DKIM lägger till en kryptografisk RSA-signatur på varje utgående e-post. Den mottagande MTA:n verifierar signaturen mot din offentliga nyckel i DNS innan den avgör var meddelandet ska hamna. 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 `._domainkey.`, 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. ![Två digitala kuvert säkrade med hänglås som representerar DKIM-signerade e-postmeddelanden i transit](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/95ba5d-img-2.webp) ## 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 `._domainkey.`. 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. ![Terminal som visar DNS TXT-poster för DKIM-selektorkonfiguration](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/02b314-img-3.webp) ## 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 ._domainkey.` 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. ## FAQ ### Vad är DKIM och hur fungerar det? DKIM (DomainKeys Identified Mail) är ett kryptografiskt autentiseringsprotokoll för e-post. Din sändande server signerar varje utgående meddelande med en privat RSA-nyckel och kopplar signaturen till ett DKIM-Signature-huvud. Den mottagande MTA:n frågar din DNS efter motsvarande offentliga nyckel under selektorunderdomänen, verifierar signaturen och rapporterar dkim=pass eller dkim=fail. Det resultatet matar ryktespoängsättning i inkorgen och DMARC-anpassningsutvärdering. ### Vad skyddar DKIM mot? DKIM skyddar mot exakt domänspoofing: en angripare som hävdar att de skickar från din domän utan tillgång till din privata signeringsnyckel. I kombination med en DMARC-policy p=reject och DKIM-anpassning förhindrar det den klassen av förfalskade meddelanden från att nå inkorgar. Det skyddar inte mot spoofing av visningsnamn, skräppost från legitimt autentiserade domäner, eller innehållsbaserat nätfiske där angriparen kontrollerar sin egen giltiga domän. ### Vad är en DKIM-selektor och varför spelar den roll? En DKIM-selektor är en etikett i DKIM-Signature-huvudet (s=-fältet) som berättar för den mottagande MTA:n vilken offentlig nyckel den ska slå upp i DNS. DNS-frågeformatet är selektor._domainkey.dindomän.com. Flera selektorer kan samexistera på en enda domän, varje pekande mot en annan offentlig nyckel. Detta möjliggör oberoende nyckelrotation per sändningstjänst och ren återkallning: ta bort selektor-DNS-posten och den avsändaren kan inte längre signera som din domän. ### Hur ofta bör DKIM-nycklar roteras? De flesta produktionsteam roterar DKIM-nycklar årligen. Den säkra sekvensen är: publicera den nya offentliga nyckeln under en ny selektor i DNS, vänta på TTL-spridning (24 till 48 timmar), byt signeringsnyckeln på din MTA till den nya selektorn, verifiera dkim=pass på utgående testmeddelanden och ta sedan bort den gamla DNS-posten. Att ta bort den gamla posten innan den nya nyckeln är bekräftad aktiv orsakar ett dkim=fail-fönster. ### Överlever DKIM vidarebefordran av e-post? Ja, till skillnad från SPF. När ett meddelande vidarebefordras ändras SMTP-kuvertsändaren och SPF-anpassning misslyckas mot den nya sändar-IP:n. DKIM-anpassning överlever vidarebefordran eftersom signaturen följer med meddelandehuvudena och -texten och inte skrivs om av relay-MTA:er, förutsatt att meddelandetexten inte modifieras i transit. Detta gör DKIM till den mer tillförlitliga autentiseringssignalen för DMARC-policytillämpning av vidarebefordrad e-post. ### Vilken DKIM-nyckellängd ska användas 2026? Använd RSA-nycklar på 2048 bitar. NIST avvecklade 1024-bitars RSA för de flesta användningsfall 2015, och 1024-bitarsnycklar utgör en beräkningsbar risk vid nuvarande beräkningskostnader. Alla större MTA:er och mottagande leverantörer stöder 2048-bitarsnycklar. Om du fortfarande har äldre 1024-bitarsselektorer publicerade i DNS, granska dem: en giltig men avvecklad selektor är en säkerhetsexponering även om din nuvarande signeringsinfrastruktur redan har gått över till längre nycklar. ### Vad är skillnaden mellan DKIM, SPF och DMARC? SPF autentiserar SMTP-kuvertsändardomänen genom att kontrollera om den sändande IP:n är listad i den domänens DNS som auktoriserad. DKIM autentiserar själva meddelandet via en kryptografisk signatur på huvuden och text. DMARC använder SPF- och DKIM-anpassningsresultat för att tillämpa en domänägarepolicy: none, quarantine eller reject. SPF misslyckas vid vidarebefordran; DKIM överlever det vanligtvis. DMARC kräver att minst en anpassning godkänns innan det tillämpar sin policy.