DKIM epäonnistuu vaihtaessasi sähköpostityökaluja: CNAME- ja selektori-migraatio-opas (2026)

Julkaistu 2026-07-08

Luvut päivätty 2026-06-29 · metodologia v7. Aggregoitu väestölaskentadata 261 miljoonan arvioidun verkkotunnuksen yli. Katso miten arvioimme.

DKIM hajoaa työkalunvaihdon jälkeen kahdesta mekaanisesta syystä: DNS-paneelisi mutkisti uuden työkalun CNAME-kohteet — yleensä lisäämällä oman vyöhykkeesi — tai vanhan työkalun selektorit poistettiin ennen kuin sen posti oli tyhjennetty. Vain 3.87% verkkotunnuksista — 10,092,481 — suorittaa SPF+DKIM+DMARC-triadon Defaults.Exposed-palvelun 261,086,232 arvioidun verkkotunnuksen väestölaskennan mukaan.

Korjausjärjestys: skannaa verkkotunnus, sitten tarkista jokaisen uuden CNAMEn tallennettu kohde dig:llä — kohde, joka päättyy omaan verkkotunnukseesi, on savuava ase. Korjaa tietueet auktoritatiivisilla nimipalvelimilla, vahvista, että uusi työkalu allekirjoittaa ja läpäisee ennen kuin ohjaat todellisen postin sen kautta, ja pidä vanhan työkalun selektorit julkaistuina kunnes sen liikenne on tyhjennetty.

Miksi DKIM hajosi kun vaihdoit työkaluja?

Mikään itse DKIMista ei muuttunut — selektorisi muuttuivat. Vanha työkalu allekirjoitti selektoreillaan; uusi allekirjoittaa eri selektoreilla, yleensä delegoiduina kahden tai kolmen CNAME-tietueen kautta, jotka lisättiin käyttöönoton aikana. Neljä karikko selittää lähes kaikki migraation jälkeiset DKIM-epäonnistumiset:

DNS-paneelisi lisäsi vyöhykkeesi CNAME-kohteeseen. Monet paneelit käsittelevät minkä tahansa liimatun isäntänimen suhteellisena ja tallentavat hiljaisesti target.provider.com.sinunverkkotunnuksesi.com:n sijaan target.provider.com:n. Tietue on olemassa, paneeli näyttää vihreän rastin, ja se ratkaisee tyhjään.
Loppupisteen hämmennys. Jotkut paneelit vaativat loppupisteen (target.provider.com.) tarkoittamaan “absoluuttinen — lopeta vyöhykkeen lisääminen”; toiset hylkäävät pisteen epäkelpaana ja käsittelevät absoluuttisuuden itse. Sama liimattu arvo on oikein yhdessä paneelissa ja mutkinut seuraavassa.
Vanhan työkalun selektorit poistettiin vaihdon päivänä. Posti, jonka vanha työkalu jo allekirjoitti, istuu uudelleenyritysjonoissa ja edelleenlähetyksissä päiviä; niiden selektorien poistaminen — tai vanhan tilin sulkeminen, mikä tappaa sen delegoidut CNAMEt — rikkoo kyseisen postin takautuvasti.
Vahvistit väärillä nimipalvelimilla. Jos migraatio sisälsi nimipalvelinmuutoksen, korjatut tietueet saattavat olla yhdessä NS-sarjassa kun vastaanottajat kyselevät edelleen toiselta.

Vain 51.84% väestölaskennan 261 miljoonasta verkkotunnuksesta esittää löydettävän DKIM-avaimen skannaushetkellä (tiedot päivätty 2026-06-29).

Sama migraatio jättää yleensä myös SPF-roskaa — 1,013,416 verkkotunnusta, noin 1 138:sta SPF:ää yrittävistä, ajaa kahta v=spf1-tietuetta, klassinen merkki siitä, että tarjoajanvaihto lisäsi tietueen sen sijaan että olisi yhdistänyt yhteen. Kyseisellä muuton puolella on oma oppaansa: SPF lakkasi toimimasta vaihtaessasi sähköpostipalveluntarjoajaa.

Miten tunnistan mutkineen CNAME-tietueen?

Älä luota paneeliin — kysy DNS:ltä mitä se todella tallensi. Kysy CNAME-kohde jokaiselle selektorille, jonka uusi työkalu antoi sinulle. Havainnollistava esimerkki, jäljittelemällä SendGrid-tyylistä delegoitua selektoria (tarjoajasi kohdekuvio eroaa):

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

Tarjoaja pyysi s1.domainkey.u1234567.wl123.sendgrid.net — mutta tallennettu kohde päättyy .sinunverkkotunnuksesi.com:een. Paneeli lisäsi vyöhykkeen; kyseinen nimi ratkaisee tyhjään, joten vastaanottajat eivät löydä avainta. Terve versio:

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

(Yksittäinen loppupiste dig-tulostuksessa on normaalia — se merkitsee täysin hyväksyttyä nimeä.) Jos kohde on oikein, seuraa sitä yhden hypyn verran: dig TXT s1._domainkey.sinunverkkotunnuksesi.com +short pitäisi palauttaa tarjoajan avain. Tyhjä vastaus oikealla CNAMElla tarkoittaa, että ongelma on tarjoajan puolella delegoinnissa — suorita heidän vahvistusvaiheensa loppuun, tai katso DKIM “ei avainta allekirjoitukselle” selektoritason diagnoosiin.

Migraation ohjekirja: ennen, aikana, jälkeen

Epäonnistuminen ei yleensä ole tietueissa — se on järjestyksessä. DKIM-migraatiot menevät pieleen siirtymähetkellä, koska vahvistus tapahtuu vaihdon jälkeen, kun todellinen posti jo epäonnistuu.

Vaihe	Mitä tehdä	Portti ennen etenemistä
Ennen vaihtoa	Lisää uuden työkalun DKIM-CNAMEt (ja palautusosoiteverkkotunnuksen tietueet), sitten todista ne: `dig` jokaisen CNAMEn tallennettu kohde verkon ulkopuolelta, suorita työkalun oma vahvistusvaihe ja lähetä testi uuden työkalun kautta hallitsemaasi postilaatikkoon	Testiviesti näyttää `dkim=pass` arvolla `d=` = verkkotunnuksesi — älä koskaan ohjaa todellista postia vahvistamattomaan työkaluun
Vaihdon päivä	Siirrä todellinen liikenne uuteen työkaluun. Älä koske mihinkään vanhaan työkaluun kuuluvaan: jätä sen selektorit, CNAMEt ja tili eloon	Uuden työkalun posti läpäisee oikeilla vastaanottajilla; vanha työkalu pysyy läpäisevänä kaiken edelleen sen kautta virtaavan kohdalla
Tyhjennyksen jälkeen	Seuraa DMARC-aggregaattiraportteja kunnes vanhan työkalun selektorit lakkaavat näkymästä (uudelleenyritysjonot ja edelleenlähetykset pyörivät päiviä — anna viikko tai enemmän), sitten poista sen tietueet ja tili	Vanhat selektorit puuttuvat raporteista ≥ 7 päivää ennen poistamista

Lihavoitu rivi on missä migraatiot pelastetaan tai hävitään: jokainen siinä oleva tarkistus voidaan tehdä päiviä ennen siirtymää, ilman riskiä live-postille. Selektorin poistomekaniikka — mukaan lukien miksi uudelleenjulkaiseminen tyhjällä p=:llä on parempi kuin poistaminen — käsitellään rotaatio-ohjekirjassa; tämä taulukko koskee itse työkalunvaihdon sekvensointia.

Miten korjaan DKIMin vaihdon jälkeen?

Aja ilmainen skannaus osoitteessa defaults.exposed ennen DNS:n koskemista. Se lukee live-tietueesi ja näyttää mitä vastaanottajat todella näkevät — mukaan lukien CNAME-kohteet, joihin vyöhyke on lisätty, ja selektorit, jotka eivät ratkaise.
Listaa DKIM-tietueet, joita uusi työkalu odottaa. Sen hallintakonsolista — postilaatikkopalveluntarjoajille, Google Workspace- ja Microsoft 365 -asennusoppaat näyttävät missä; uutiskirje- ja CRM-työkalut listaavat CNAMEnsa verkkotunnuksen todennuksen alla (katso Mailchimp/Brevo/Klaviyo -sähköpostit epäonnistuvat DMARC:ssa).
Tarkista jokaisen tietueen tallennettu arvo komennolla dig CNAME <nimi> +short ja vertaa sitä merkki kerrallaan siihen mitä työkalu pyysi. Kohde, joka päättyy omaan verkkotunnukseesi = vyöhykelisäys; kirjoita se uudelleen, ja jos paneeli jatkaa lisäämistä, lisää loppupiste (tai poista se, jos paneeli hylkää pisteet).
Varmista auktoritatiivisilta nimipalvelimilta. dig +short NS sinunverkkotunnuksesi.com, sitten toista CNAME-tarkistukset @<kyseinen nimipalvelin>. Jos migraatio vaihtoi nimipalvelimia, tarkista molemmat sarjat — vastaanottajat saattavat edelleen kyselytä vanhalta kunnes delegointi leviää.
Aja uudelleen työkalun vahvistus ja lähetä testiviesti. Authentication-Results-otsakkeessa pitäisi näkyä dkim=pass arvolla d= yhtä suuri kuin verkkotunnuksesi — läpäisy työkalun oletusverkkotunnuksella ei linjaudu DMARC:ille.
Pidä vanhan työkalun selektorit julkaistuina kunnes sen posti on tyhjennetty, sitten poista ne harkitusti. Sitten skannaa uudelleen ja käy läpi kaikki muut korjaa DKIM -sivulla merkityt asiat.

Usein kysytyt kysymykset

Tarvitsenko loppupisteen DKIM-CNAMEen vai en? Se riippuu täysin paneelista. Piste tarkoittaa “absoluuttinen nimi — älä lisää vyöhykettäni”; jotkut paneelit vaativat sen, jotkut lisäävät sen puolestasi, jotkut hylkäävät sen. Ainoa testi, jolla on merkitystä, on komennon dig CNAME <selektori>._domainkey.sinunverkkotunnuksesi.com +short tulos tallentamisen jälkeen: jos kohde päättyy omaan verkkotunnukseesi, paneeli lisäsi vyöhykkeen ja tarvitset pisteen (tai eri syötteen muodon).

Voinko poistaa vanhan työkalun DKIM-tietueet vaihdon päivänä? Ei. Posti, jonka vanha työkalu allekirjoitti, on edelleen uudelleenyritysjonoissa ja edelleenlähetysketjuissa, ja avaimen poistaminen, johon se osoittaa, rikkoo kyseiset viestit takautuvasti. Pidä vanhat selektorit live-tilassa kunnes ne lakkaavat näkymästä DMARC-aggregaattiraporteissasi — viikko tai enemmän — äläkä sulje vanhaa tiliä ennen sitä.

DNS-paneelini ja uusi työkalu molemmat sanovat “verified”, mutta vastaanottajat epäonnistuvat edelleen DKIM:ssä. Miten? Kaksi yleistä tapausta: työkalu vahvisti välimuistissa olevaa tarkistusta kun auktoritatiiviset nimipalvelimet tarjoavat eri vastausta (kysy niiltä suoraan dig @<ns>:llä), tai DKIM läpäisee mutta työkalun oletusallekirjoitusverkkotunnuksella eikä sinun, joten DMARC epäonnistuu silti linjautumisessa. Skannaus erottaa nämä kaksi.

Voivatko molempien työkalujen DKIM-tietueet olla olemassa samanaikaisesti siirtymän aikana? Kyllä — ja niiden pitäisi. DKIM:llä ei ole yhden tietueen sääntöä: jokainen selektori on oma DNS-nimensä, joten molempien työkalujen tietueet elävät rinnakkain ilman konfliktia, mikä tekee pidä-vanhat-selektorit-tyhjennyksen-ajan -säännöstä vapaan seurata. (SPF on päinvastoin — kaksi v=spf1-tietuetta mitätöi sen, minkä vuoksi SPF-migraatio-opas koskee yhdistämistä.)

Lähetä omistajalle raportti

Jos ajat tätä migraatiota asiakkaalle tai työnantajallesi, sulje se todisteella. Kun uusi työkalu allekirjoittaa ja linjautuu, aja ilmainen skannaus uudelleen ja lähetä arvioitu raportti yrityksen omistajalle: päivätty, selkokielinen todiste siitä, että vaihto jätti verkkotunnuksen täysin todennettuna. Se on artefakti, jota he tarvitsevat kyberturvallisuusvakuutuksen uusimiseen ja seuraavaan toimittajan turvallisuuskyselyyn — se muuttaa “migraatio on tehty” väitteestä asiakirjaksi.

Tarkista DKIMisi ilmaiseksi

Katso, ratkaisevatko uuden työkalun selektorit — ja täsmälleen mitä korjata — yksityisesti ja vain omistajalle.

Tarkista verkkotunnuksesi → · SPF hajosi vaihtaessasi tarjoajaa → · Korjaa DKIM → · Aseta DKIM Google Workspacelle → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.