DKIM misslyckas efter byte av e-postverktyg: CNAME- och selektor-migreringsguiden (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.

DKIM bryter efter ett verktygsbyte av två mekaniska skäl: din DNS-panel förvanskat det nya verktygets CNAME-mål — vanligtvis genom att lägga till din egen zon — eller det gamla verktygets selektorer togs bort innan dess e-post tömdes. Bara 3.87% av domänerna — 10,092,481 — slutför SPF+DKIM+DMARC-triaden, enligt Defaults.Exposed-censuset med 261,086,232 graderade domäner.

Åtgärdsordningen: scanna domänen, kontrollera sedan varje ny CNAMEs lagrade mål med dig — ett mål som slutar med ditt eget domännamn är rykande beviset. Reparera posterna vid de auktoritativa namnservrarna, bekräfta att det nya verktyget signerar och godkänner innan du dirigerar riktig e-post via det, och behåll det gamla verktygets selektorer publicerade tills dess trafik töms.

Varför bröt DKIM när du bytte verktyg?

Ingenting om DKIM i sig ändrades — dina selektorer ändrades. Det gamla verktyget signerade med sina selektorer; det nya signerar med olika, vanligtvis delegerade via två eller tre CNAME-poster tillagda under onboarding. Fyra fallgropar förklarar nästan varje post-migrerings-DKIM-misslyckande:

Din DNS-panel lade till din zon till CNAME-målet. Många paneler behandlar alla inklistrade värdnamn som relativa och lagrar tyst target.provider.com.yourdomain.com istället för target.provider.com. Posten finns, panelen visar en grön bockmarkering, och det löser sig till ingenting.
Förvirring med avslutande punkt. Vissa paneler kräver en avslutande punkt (target.provider.com.) för att betyda “absolut — sluta lägga till min zon”; andra avvisar punkten som ogiltig och hanterar absoluthet själva. Samma inklistrade värde är rätt i en panel och förvanskat i nästa.
Det gamla verktygets selektorer raderades på byttesdagen. E-post som det gamla verktyget redan signerat sitter i omförsöksköer och vidarebefordringsvägar i dagar; att ta bort dess selektorer — eller stänga det gamla kontot, vilket dödar dess delegerade CNAMEs — bryter den e-posten retroaktivt.
Du verifierade vid fel namnservrar. Om migreringen inkluderade ett namnservrarsbyte kan de åtgärdade posterna finnas vid en NS-uppsättning medan mottagare fortfarande frågar den andra.

Bara 51.84% av de 261 miljoner domänerna i censuset presenterar en synlig DKIM-nyckel vid skanntillfället (data per 2026-06-29).

Samma migrering lämnar vanligtvis SPF-skräp också — 1,013,416 domäner, ungefär 1 av 138 av dem som försöker med SPF, kör två v=spf1-poster, det klassiska tecknet på att ett leverantörsbyte lade till en post istället för att slå ihop en. Den sidan av flytten har sin egen guide: SPF slutade fungera efter byte av e-postleverantör.

Hur spottar jag en förvanskat CNAME-post?

Lita inte på panelen — fråga DNS vad det faktiskt lagrade. Fråga CNAME-målet för varje selektor det nya verktyget gav dig. Ett illustrativt exempel, som härmar en SendGrid-stilsdelegerad selektor (din leverantörs målform kommer att skilja sig):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Leverantören begärde s1.domainkey.u1234567.wl123.sendgrid.net — men det lagrade målet slutar med .yourdomain.com. Panelen lade till zonen; det namnet löser sig till ingenting, så mottagare hittar ingen nyckel. Den friska versionen:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(En enstaka avslutande punkt i dig-utdata är normal — den markerar ett fullt kvalificerat namn.) Om målet är rätt, följ det ett hopp: dig TXT s1._domainkey.yourdomain.com +short bör returnera leverantörens nyckel. Tomt svar med en korrekt CNAME betyder att problemet är på leverantörens sida av delegeringen — slutför deras verifieringssteg, eller se DKIM “ingen nyckel för signatur” för selektor-nivåns diagnos.

Migreringsmanualen: före, under, efter

Misslyckandet är vanligtvis inte posterna — det är ordningen. DKIM-migreringar går fel vid övergångstillfället eftersom verifiering sker efter bytet, när riktig e-post redan misslyckas.

Fas	Vad man gör	Grind innan man går vidare
Innan bytet	Lägg till det nya verktygets DKIM-CNAMEs (och studsdomänposter), bevisa dem sedan: `dig` varje CNAMEs lagrade mål utifrån ditt nätverk, slutför verktygets egna verifieringssteg och skicka ett test via det nya verktyget till en postlåda du kontrollerar	Testmeddelande visar `dkim=pass` med `d=` = din domän — dirigera aldrig riktig e-post via ett overifierat verktyg
Byttesdagen	Flytta riktig trafik till det nya verktyget. Rör ingenting tillhörande det gamla verktyget: lämna dess selektorer, CNAMEs och konto vid liv	Det nya verktygets e-post godkänns vid riktiga mottagare; det gamla fortsätter godkännas för allt som fortfarande flödar via det
Efter tömningen	Titta på DMARC-aggregerade rapporter tills det gamla verktygets selektorer slutar visas (omförsöksköer och vidarebefordringar körs i dagar — tillåt en vecka eller mer), pensionera sedan dess poster och konto	Gamla selektorer frånvarande från rapporter ≥ 7 dagar innan borttagning

Den fetstilta raden är där migreringar räddas eller förloras: varje kontroll i den kan göras dagar före övergångstillfället, med noll risk för live e-post. Selektor-pensioneringsmekanik — inklusive varför återpublicering med en tom p= slår radering — täcks i rotationsmanualen; den här tabellen handlar om att sekvensera verktygsbyte i sig.

Hur åtgärdar jag DKIM efter bytet?

Kör den kostnadsfria sökningen på defaults.exposed innan du rör DNS. Den läser dina live poster och visar vad mottagare faktiskt ser — inklusive CNAME-mål som zon-tillagts och selektorer som inte löser sig.
Lista de DKIM-poster det nya verktyget förväntar sig. Från dess administratörskonsol — för postlådeleverantörer visar konfigurationsguiderna för Google Workspace och Microsoft 365 var; nyhetsbrev- och CRM-verktyg listar sina CNAMEs under domänautentisering (se Mailchimp/Brevo/Klaviyo-e-post som misslyckas med DMARC).
Kontrollera varje posts lagrade värde med dig CNAME <namn> +short och jämför det tecken för tecken med vad verktyget begärde. Ett mål som slutar med din egen domän = zon-tillagt; skriv in det på nytt, och om panelen fortsätter lägga till, lägg till den avslutande punkten (eller ta bort den, om panelen avvisar punkter).
Verifiera vid de auktoritativa namnservrarna. dig +short NS yourdomain.com, upprepa sedan CNAME-kontrollerna @<den namnservern>. Om migreringen ändrade namnservrar, kontrollera båda uppsättningarna — mottagare kan fortfarande fråga den gamla tills delegering propageras.
Kör om verktygets verifiering och skicka ett testmeddelande. Authentication-Results-rubriken bör visa dkim=pass med d= lika med din domän — ett godkännande på verktygets standarddomän anpassas inte för DMARC.
Lämna det gamla verktygets selektorer publicerade tills dess e-post töms, pensionera dem sedan avsiktligt. Scanna sedan om och arbeta igenom allt annat som flaggas på sidan åtgärda DKIM.

Vanliga frågor

Behöver jag den avslutande punkten på min DKIM-CNAME eller inte? Det beror helt på panelen. Punkten betyder “absolut namn — lägg inte till min zon”; vissa paneler kräver den, vissa lägger till den åt dig, vissa avvisar den. Det enda testet som spelar roll är utdata från dig CNAME <selektor>._domainkey.yourdomain.com +short efter sparande: om målet slutar med din egen domän lade panelen till zonen och du behöver punkten (eller ett annat inmatningsformat).

Kan jag radera det gamla verktygets DKIM-poster på byttesdagen? Nej. E-post som det gamla verktyget signerade finns fortfarande i omförsöksköer och vidarebefordringsvägar, och att radera nyckeln det pekar på bryter de meddelandena retroaktivt. Håll de gamla selektorerna live tills de slutar visas i dina DMARC-aggregerade rapporter — en vecka eller mer — och stäng inte det gamla kontot dessförinnan heller.

Min DNS-panel och det nya verktyget säger båda “verifierat”, men mottagare misslyckas fortfarande med DKIM. Hur? Två vanliga fall: verktyget verifierade mot en cachad kontroll medan de auktoritativa namnservrarna serverar något annat (fråga dem direkt med dig @<ns>), eller DKIM godkänns men på verktygets standard-signeringsdomän snarare än din, så DMARC misslyckas fortfarande med anpassning. Sökningen skiljer de två åt.

Kan båda verktygens DKIM-poster samexistera under överlappet? Ja — och de bör göra det. DKIM har ingen enpostregel: varje selektor är sitt eget DNS-namn, så båda verktygens poster lever sida vid sida utan konflikt, vilket gör regeln om att behålla gamla selektorer under tömningen gratis att följa. (SPF är det motsatta — två v=spf1-poster ogiltigförklarar det, vilket är varför SPF-migreringsguiden handlar om att slå ihop.)

Skicka ägaren rapporten

Om du kör den här migreringen för en kund eller din arbetsgivare, avsluta den med bevis. När det nya verktyget signerar och anpassas, kör om den kostnadsfria sökningen och vidarebefordra den graderade rapporten till företagsägaren: daterat, klarspråkligt bevis på att bytet lämnade domänen fullt autentiserad. Det är artefakten de behöver för förnyelse av cyberförsäkring och nästa leverantörs säkerhetsenkät — det förvandlar “migreringen är klar” från ett påstående till ett dokument.

Kontrollera din DKIM kostnadsfritt

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

Kontrollera din domän → · SPF bröt efter byte av leverantör → · Åtgärda DKIM → · Konfigurera DKIM på Google Workspace → · Enbart aggregerade data. Data lagras och behandlas inom EU.