DKIM "Ingen nyckel för signatur": Selektor- och rotationsfixar (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

“Ingen nyckel för signatur” betyder att mottagaren sökte efter DNS-posten din DKIM-signatur pekar på — selector._domainkey.yourdomain — och hittade ingen nyckel: den publicerades aldrig, eller raderades mitt i en rotation. Publicera selektorn din undertecknare faktiskt använder. Bara 10,092,481 domäner — 3.87% — slutför SPF+DKIM+DMARC-triaden, enligt Defaults.Exposed-censuset med 261,086,232 graderade domäner.

Fixen är en DNS-post, hittad i en rubrik. Läs taggarna s= och d= från en riktig DKIM-Signature-rubrik för att ta reda på vilken selektor din e-post är signerad med, publicera (eller reparera) den exakta posten, och föredra CNAME-delegering så att din leverantör roterar nycklar åt dig. Rotera sedan enligt manualen nedan — det här felet betyder vanligtvis att någon raderade en gammal selektor för tidigt.

Vad betyder “dkim ingen nyckel för signatur”?

Varje DKIM-signatur bär två taggar som talar om för mottagaren var den offentliga nyckeln ska hämtas: d= (signeringsdomän) och s= (selektor). Mottagaren söker ett DNS-namn byggt från dem — s._domainkey.d — efter nyckeln. “Ingen nyckel för signatur” betyder att frågan kom tillbaka tom: signaturen finns, men nyckeln den namnger gör det inte.

Formuleringen visas i Authentication-Results-rubriker och DMARC-aggregerade rapporter — den exakta formuleringen varierar per mottagare, men två varianter är viktiga:

Resultatsträng (fragment, som allmänt observerats)	Vad som faktiskt hände	Tillfällig?
`dkim=temperror (no key for signature)`	DNS-frågan misslyckades eller tids ut — mottagaren kunde inte få svar alls	Ja — omförsök godkänns ofta; undersök bara om det är ihållande
`dkim=permerror (no key for signature)`	DNS-frågan lyckades och svaret var “ingen sådan post” — selektorn är genuint frånvarande	Nej — posten saknas tills du publicerar den

Ett engångsmässigt temperror är DNS-väder. En permerror — eller ett temperror som upprepas över dagar och mottagare — betyder att posten signaturen pekar på inte finns i din zon. Det är den här guiden.

Konsekvensen: en overifierbar signatur räknas som inget DKIM alls, så DMARC faller tillbaka på enbart SPF — och SPF bryter under vidarebefordring. Om signaturen är närvarande men ogiltig snarare än frånvarande (body-hash, förvanskad nyckel) är det ett annat fel — se “DKIM-signatur ogiltig”.

Hur hittar jag vilken selektor min e-post är signerad med?

Gissa inte från din leverantörs dokumentation — läs det från ett riktigt meddelande:

Skicka ett meddelande från det drabbade systemet till en postlåda du kontrollerar (en Gmail-adress fungerar bra).
Öppna råkällan (“Visa original” i Gmail, “Visa meddelandekälla” i Outlook).
Hitta DKIM-Signature:-rubriken och läs två taggar: s= är selektorn, d= är signeringsdomänen. Ett illustrativt exempel: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Posten mottagaren söker är s._domainkey.d — här mail2026._domainkey.yourdomain.com. Kontrollera den själv: dig TXT mail2026._domainkey.yourdomain.com +short. Tomt svar = felet är verkligt för varje mottagare.
Upprepa per sändande system. Ett meddelande kan bära flera DKIM-signaturer — postlådeleverantör, nyhetsbrevverktyg, helpdesk — var och en med sitt eget s=/d=-par och post. Åtgärda den misslyckade och notera dess d=: bara en signatur vars d= matchar din From-domän hjälper DMARC.

Varför saknas selektorsposten?

Fyra orsaker förklarar nästan alla dessa fel — kontrollera dem i den här ordningen:

Den publicerades aldrig. Undertecknaren slogs på (eller var på som standard) med en selektor som ingen lade till i DNS. Vanligt med nya verktyg och gateways som signerar oväntat.
Den raderades mitt i en rotation. Någon “städade upp” den gamla selektorn medan meddelanden signerade med den fortfarande var under transport, köade för omförsök, eller väntade på vidarebefordring. Den e-posten är redan signerad med s=old; att radera old._domainkey bryter retroaktivt varje sådant meddelande.
Din DNS-panel förvanskat ett CNAME-mål. Många leverantörer delegerar via CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), och många DNS-paneler lägger tyst till din zon till målet — lagrar s1.domainkey.u123.esp.com.yourdomain.com, som inte löser sig till någonting. Verifiera målet: dig CNAME s1._domainkey.yourdomain.com +short. Samma fälla biter vid verktygsmigrationer — se DKIM misslyckas efter byte av e-postverktyg.
Leverantören roterade, din zon inte. En leverantörsnyckel inklistrad som en statisk TXT-post (istället för deras CNAMEs) blir övergiven av deras schemalagda rotation — undertecknaren flyttar till en selektor du aldrig publicerade. Bara 51.84% av de 261 miljoner domänerna i censuset presenterar en synlig DKIM-nyckel vid skanntillfället (data per 2026-06-29).

Hur åtgärdar jag “ingen nyckel för signatur”?

Kör den kostnadsfria sökningen på defaults.exposed innan du rör DNS. Den läser dina live DKIM-, SPF- och DMARC-poster och visar vad mottagare faktiskt ser — inklusive om selektorn löser sig och om ett CNAME-mål har blivit förvanskat.
Publicera selektorn som undertecknaren faktiskt använder — s=-värdet från rubriken, inte den i en gammal manual. Hämta posten från din leverantörs administratörskonsol (Google Workspace DKIM-konfiguration · Microsoft 365 DKIM-konfiguration) och lägg till den exakt på s._domainkey.yourdomain.com.
Föredra CNAME-delegering framför att klistra in en TXT-nyckel. Om din leverantör erbjuder DKIM-CNAMEs, använd dem: nyckeln lever i deras zon, så de roterar den utan att du rör DNS igen — orsak 4 blir omöjlig. Nyhetsbrevplattformar fungerar nästan alla på det här sättet; se Mailchimp/Brevo/Klaviyo-e-post som misslyckas med DMARC.
Verifiera utanför din panel. dig TXT s._domainkey.yourdomain.com +short (eller dig CNAME … för delegerade selektorer) från en dator utanför ditt nätverk. Att panelen visar posten bevisar ingenting om zonen serverar något annat.
Scanna igen och skicka om testmeddelandet. Authentication-Results bör nu läsa dkim=pass. Arbeta sedan igenom allt annat som sökningen flaggar på sidan åtgärda DKIM — en godkänd signatur som inte anpassas till din From-domän misslyckas fortfarande med DMARC.

Hur roterar jag DKIM-nycklar utan att orsaka det här felet?

Rotation är var fungerande konfigurationer brister. Regeln som förhindrar det: en selektor raderas bara efter att det sista meddelandet signerat med den har tömt sig — aldrig vid övergångstillfället. Signerad e-post lever längre än du tror: omförsöksköer körs i dagar, och vidarebefordrade meddelanden verifieras om varje gång de rör sig.

Steg	Åtgärd	Grind före nästa steg
1. Lägg till	Publicera den nya selektorn (`s2._domainkey…`) bredvid den gamla	`dig` bekräftar att den löser sig utifrån
2. Byt	Peka undertecknaren på den nya selektorn	Testmeddelande visar `s=s2` och `dkim=pass`
3. Vänta	Lämna den gamla selektorn publicerad medan flyg-, köad och vidarebefordrad trafik töms	≥ 7 dagar; titta på DMARC-aggregerade rapporter tills den gamla selektorn slutar visas
4. Pensionera	Ta bort den gamla nyckeln — eller ännu bättre, publicera om den med en tom `p=`-tag: “pensionerad”, inte “har aldrig funnits”	Börja aldrig detta vid övergångstillfället — för tidig radering är den #1-orsaken till “ingen nyckel för signatur”

Med CNAME-delegering kör din leverantör exakt den här manualen inuti sin egen zon och du ser det aldrig — det starkaste argumentet för att delegera.

Vanliga frågor

Är “ingen nyckel för signatur” ett temperror eller ett permerror? Båda strängarna finns: temperror är en DNS-sökning som misslyckades eller tids ut — tillfällig, ofta borta vid omförsök — medan permerror betyder att DNS svarade “ingen sådan post”. Ett temperror som upprepas över mottagare visar sig vanligtvis vara en genuint saknad post också. Kontrollera med dig och lita på svaret, inte etiketten.

Betyder det här felet att någon förfalskar min domän? Nej — en bedragare skulle inte signera med din selektor. Det betyder att din egen e-post bär en signatur mottagare inte kan verifiera, så den räknas som osignerad och DMARC lutar på enbart SPF. Fullständig, anpassad autentisering är sällsynt: bara 10,092,481 av 261,086,232 domäner (3.87%) slutförde SPF+DKIM+DMARC-triaden i Defaults.Exposed-censuset (data per 2026-06-29).

Kan jag bara radera den gamla selektorn när den nya fungerar? Inte omedelbart. Meddelanden signerade med den finns fortfarande i omförsöksköer och vidarebefordringsvägar; att radera nyckeln bryter dem retroaktivt. Behåll den gamla posten minst en vecka, titta på dina DMARC-rapporter tills den gamla selektorn slutar visas, pensionera den sedan — helst med en tom p= snarare än radering.

Min leverantörs kontrollant säger att DKIM är konfigurerat, men mottagare rapporterar fortfarande ingen nyckel. Hur? Nästan alltid CNAME-mål-fällan: din DNS-panel lade till din zon till målet (…esp.com.yourdomain.com), så posten finns men pekar ingenstans. dig CNAME selector._domainkey.yourdomain.com +short visar det lagrade målet ordagrant — jämför det tecken för tecken med vad leverantören begärde.

Skicka ägaren rapporten

Om du åtgärdar detta för en kund eller din arbetsgivare, avsluta loopen med bevis. Kör om den kostnadsfria sökningen när selektorn löser sig och vidarebefordra den graderade rapporten till företagsägaren: daterad, klarspråk, DKIM nu verifierande. Det är artefakten de behöver för förnyelse av cyberförsäkring och nästa leverantörs säkerhetsenkät — bevis på en fungerande kontroll, inte bara ett stängt ärende.

Kontrollera din DKIM kostnadsfritt

Se om dina selektorer löser sig — och exakt vad som ska åtgärdas — privat och enbart för ägaren.

Kontrollera din domän → · “DKIM-signatur ogiltig” → · Åtgärda DKIM → · Konfigurera DKIM på Google Workspace → · Enbart aggregerade data. Data lagras och behandlas inom EU.