DKIM feiler etter bytte av e-postverktøy: CNAME- og velger-migrasjonsveiledningen (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

DKIM bryter etter et verktøybytte av to mekaniske årsaker: DNS-panelet ditt klusset til det nye verktøyets CNAME-mål — vanligvis ved å legge til din egen sone — eller det gamle verktøyets velgere ble fjernet før e-posten var drenert. Bare 3.87% av domener — 10,092,481 — fullfører SPF+DKIM+DMARC-triaden, ifølge Defaults.Exposed-sensus over 261,086,232 graderte domener.

Fikse-rekkefølgen: skann domenet, sjekk deretter hvert nye CNAME-s lagrede mål med dig — et mål som slutter på ditt eget domenenavn er røyksignalet. Reparer postene på de autoritative navnetjenerne, bekreft at det nye verktøyet signerer og består før du ruter ekte e-post gjennom det, og behold det gamle verktøyets velgere publisert til trafikken er drenert.

Hvorfor brøt DKIM da du byttet verktøy?

Ingenting ved selve DKIM endret seg — velgerne dine gjorde det. Det gamle verktøyet signerte med sine velgere; det nye signerer med forskjellige, vanligvis delegert via to eller tre CNAME-poster lagt til under innkoplingen. Fire fallgruver forklarer nesten alle DKIM-feil etter migrering:

DNS-panelet la til sonen din til CNAME-målet. Mange paneler behandler et limt vertsnavn som relativt og lagrer stille mål.leverandor.com.dittdomene.com i stedet for mål.leverandor.com. Posten eksisterer, panelet viser et grønt hake-merke, og den løser til ingenting.
Forvirring om avsluttende punktum. Noen paneler krever et avsluttende punktum (mål.leverandor.com.) for å bety «absolutt — slut å legge til sonen min»; andre avviser punktumet som ugyldig og håndterer absolutt selv. Den samme limte verdien er riktig i ett panel og ødelagt i det neste.
Det gamle verktøyets velgere ble slettet på byttedagen. E-post det gamle verktøyet allerede signerte sitter i forsøkskøer og videresendingsstier i dager; å fjerne velgerne — eller å stenge den gamle kontoen, som dreper de delegerte CNAME-ene — bryter den e-posten retroaktivt.
Du bekreftet på feil navnetjenere. Hvis migreringen inkluderte et navnetjenerskifte, kan de fikset postene eksistere på ett NS-sett mens mottakere fortsatt spør det andre.

Bare 51.84% av de 261 millioner domenene i sensus presenterer en oppdagbar DKIM-nøkkel på skanne-tidspunktet (data per 2026-06-29).

Den samme migreringen etterlater vanligvis SPF-rusk også — 1,013,416 domener, omtrent 1 av 138 av de som forsøker SPF, kjører to v=spf1-poster, det klassiske tegnet på at et leverandørbytte la til en post i stedet for å slå en sammen. Den siden av flyttingen har sin egen veiledning: SPF sluttet å fungere etter at du byttet e-postleverandør.

Hvordan oppdager jeg en ødelagt CNAME-post?

Ikke stol på panelet — spør DNS hva det faktisk lagret. Spør CNAME-målet for hver velger det nye verktøyet ga deg. Et illustrerende eksempel som etterlikner en SendGrid-stil delegert velger (leverandørens målform vil avvike):

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

Leverandøren ba om s1.domainkey.u1234567.wl123.sendgrid.net — men det lagrede målet slutter på .dittdomene.com. Panelet la til sonen; det navnet løser til ingenting, så mottakere finner ingen nøkkel. Den sunne versjonen:

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

(Et enkelt avsluttende punktum i dig-utdata er normalt — det markerer et fullt kvalifisert navn.) Hvis målet er riktig, følg det ett hopp: dig TXT s1._domainkey.dittdomene.com +short bør returnere leverandørens nøkkel. Tomt svar med en korrekt CNAME betyr at problemet er på leverandørens side av delegeringen — fullfør bekreftelsestrinnet deres, eller se DKIM «no key for signature» for velger-nivå-diagnosen.

Migrasjonens kjørebok: før, under, etter

Feilen er vanligvis ikke postene — det er rekkefølgen. DKIM-migrasjoner går galt ved innkoplingen fordi bekreftelse skjer etter byttet, når ekte e-post allerede feiler.

Fase	Hva du gjør	Port før du går videre
Før byttet	Legg til det nye verktøyets DKIM CNAME-er (og sprett-domene-poster), og bevis dem deretter: `dig` hvert CNAME-s lagrede mål utenifra nettverket ditt, fullfør verktøyets eget bekreftelsestrinn, og send en test gjennom det nye verktøyet til en postkasse du kontrollerer	Testmelding viser `dkim=pass` med `d=` = domenet ditt — rut aldri ekte e-post gjennom et ubekreftet verktøy
Byttedagen	Flytt ekte trafikk til det nye verktøyet. Rør ingenting som tilhører det gamle verktøyet: la velgerne, CNAME-ene og kontoen leve	Det nye verktøyets e-post bestås hos ekte mottakere; det gamle fortsetter å bestå for alt som fortsatt strømmer gjennom det
Etter drenering	Se på DMARC samlede rapporter til det gamle verktøyets velgere slutter å dukke opp (forsøkskøer og videresendinger kjører i dager — tillat en uke eller mer), og pensjonerer deretter postene og kontoen	Gamle velgere fraværende fra rapporter ≥ 7 dager før fjerning

Den uthevede raden er der migrasjoner reddes eller tapes: alle sjekkene i den kan gjøres dager før innkoplingen, uten noen risiko for ekte e-post. Velger-pensjoneringssmekanikk — inkludert hvorfor republisering med en tom p= slår sletting — er dekket i rotasjonskjøreboken; denne tabellen handler om å sekvensere selve verktøybyttet.

Hvordan fikser jeg DKIM etter byttet?

Kjør den gratis skanningen på defaults.exposed før du rører DNS. Den leser de live postene dine og viser hva mottakere faktisk ser — inkludert CNAME-mål som ble sone-vedlagt og velgere som ikke løser opp.
List opp DKIM-postene det nye verktøyet forventer. Fra admin-konsollen — for postkasseleverandører, viser Google Workspace- og Microsoft 365-oppsettsveiledningene hvor; nyhetsbrev- og CRM-verktøy lister CNAME-ene sine under domeneautentisering (se Mailchimp/Brevo/Klaviyo-e-poster feiler DMARC).
Sjekk hver posts lagrede verdi med dig CNAME <navn> +short og sammenlign det tegn for tegn med hva verktøyet ba om. Et mål som slutter på ditt eget domene = sone-vedlagt; skriv det inn på nytt, og hvis panelet fortsetter å legge til, legg til det avsluttende punktumet (eller fjern det, hvis panelet avviser punktum).
Bekreft på de autoritative navnetjenerne. dig +short NS dittdomene.com, og gjenta deretter CNAME-sjekkene @<den navnetjeneren>. Hvis migreringen endret navnetjenere, sjekk begge settene — mottakere kan fortsatt spørre det gamle til delegering propagerer.
Kjør verktøyets bekreftelse på nytt og send en testmelding. Authentication-Results-overskriften bør vise dkim=pass med d= lik domenet ditt — et pass på verktøyets standarddomene justerer ikke for DMARC.
La det gamle verktøyets velgere forbli publisert til e-posten er drenert, og pensjonerer dem deretter med vilje. Skann deretter på nytt, og arbeid gjennom alt annet som er flagget på siden fiks DKIM.

Ofte stilte spørsmål

Trenger jeg det avsluttende punktumet på DKIM CNAME eller ikke? Det avhenger helt av panelet. Punktumet betyr «absolutt navn — ikke legg til sonen min»; noen paneler krever det, noen legger det til for deg, noen avviser det. Den eneste testen som betyr noe er utdataene til dig CNAME <velger>._domainkey.dittdomene.com +short etter lagring: hvis målet slutter på ditt eget domene, la panelet til sonen og du trenger punktumet (eller et annet inngangsformat).

Kan jeg slette det gamle verktøyets DKIM-poster på byttedagen? Nei. E-post det gamle verktøyet signerte er fortsatt i forsøkskøer og videresendingsstier, og å slette nøkkelen den peker til bryter de meldingene retroaktivt. Hold de gamle velgerne levende til de slutter å dukke opp i DMARC samlede rapporter — en uke eller mer — og steng ikke den gamle kontoen før det heller.

DNS-panelet mitt og det nye verktøyet sier begge «bekreftet», men mottakere feiler DKIM fortsatt. Hvordan? To vanlige tilfeller: verktøyet bekreftet mot en bufret sjekk mens de autoritative navnetjenerne serverer noe annet (spørr dem direkte med dig @<ns>), eller DKIM bestås men på verktøyets standard signeringsdomene i stedet for ditt, slik at DMARC feiler justering. Skanningen skiller de to.

Kan begge verktøyers DKIM-poster sameksistere under overlappet? Ja — og det bør de. DKIM har ingen enkelt-post-regel: hver velger er sitt eget DNS-navn, slik at begge verktøyers poster bor side om side uten konflikt, noe som gjør det fritt å følge regelen om å holde gamle velgere gjennom dreneringen. (SPF er det motsatte — to v=spf1-poster ugyldiggjør det, noe som er grunnen til at SPF-migrasjons-veiledningen handler om å slå sammen.)

Send eieren rapporten

Hvis du kjører denne migreringen for en klient eller arbeidsgiveren din, avslutt den med bevis. Når det nye verktøyet signerer og justerer, kjør den gratis skanningen på nytt og videresend den graderte rapporten til bedriftseieren: datert, på enkelt norsk, bevis for at byttet etterlot domenet fullstendig autentisert. Det er artefakten de vil trenge til fornyelse av cyberforsikring og neste leverandørsikkerhets-spørreskjema — det gjør «migreringen er ferdig» fra et krav til et dokument.

Sjekk DKIM gratis

Se om det nye verktøyets velgere løser opp — og nøyaktig hva du skal fikse — privat og kun for eieren.

Sjekk domenet ditt → · SPF brøt etter bytte av leverandør → · Fiks DKIM → · Sett opp DKIM på Google Workspace → · Kun aggregerte data. Data lagret og behandlet i EU.