Kā iestatīt DKIM: solis-pa-solim ceļvedis 2026

DKIM iestatīšana ir otrs no trim autentifikācijas soļiem, kas vajadzīgs katram B2B cold email sūtītājam 2026. Atšķirībā no SPF (kas autorizē IP), DKIM kriptogrāfiski paraksta pašu e-pastu — lai saņemošie serveri var verificēt, ka ziņojums nav modificēts transit laikā un ka tas patiešām nāca no jūsu domēna. Iestatīšana ir mēreni tehniska, bet paredzama, kad sekojama pareizi. Šis raksts iet cauri pilnam DKIM iestatīšanas procesam: atslēgu ģenerēšana, DNS konfigurācija, selector stratēģija un verifikācija. Pāris ar SPF iestatīšanas ceļvedi, DMARC policy ceļvedi un SPF/DKIM/DMARC pārskatu.

DKIM (DomainKeys Identified Mail) pievieno kriptogrāfisku parakstu izejošajam e-pastam. Sūtīšanas serveris paraksta ziņojumu ar privāto atslēgu; saņemošais serveris ielādē atbilstošo publisko atslēgu no jūsu DNS un verificē parakstu. DKIM-izturošs e-pasts tiek uzskatīts par uzticamāku katrā lielākajā saņemošajā sistēmā — un DKIM-neizturošs e-pasts tiek uzskatīts par spēcīgu spam signālu.

Kā DKIM strādā

Kad jūsu mail serveris sūta e-pastu, tas pievieno DKIM-Signature galveni ziņojumam. Paraksts tiek aprēķināts, izmantojot privāto atslēgu, ko sūtīšanas serveris tur, pielietots cauri konkrētiem galvenes laukiem un ziņojuma ķermenim. Galvene ietver domēna nosaukumu un “selector” (etiķeti, kas identificē, kura atslēga tika izmantota — noderīgi, rotējot atslēgas).

Kad e-pasts pienāk saņemošajā serverī, serveris:

1. Lasa DKIM-Signature galveni
2. Ekstrahē domēnu un selector
3. Meklē publisko atslēgu pie <selector>._domainkey.<domain> DNS
4. Izmanto publisko atslēgu, lai verificētu parakstu

Ja paraksts verificējas, DKIM iziet. Ja paraksts nevar tikt verificēts — nepareiza atslēga, modificēts ziņojums transit, trūkstošs DNS ieraksts — DKIM neizdodas.

Solis-pa-solim DKIM iestatīšana

Precīzie soļi atkarīgi no tā, kuru sūtīšanas servisu izmantojat, bet paterns ir konsekvents.

1. solis: Ģenerējiet vai iegūstiet publisko/privāto atslēgu pāri. Lielākā daļa modernu sūtīšanas servisu (Google Workspace, Microsoft 365, Smartlead, Lemlist, Apollo, SendGrid) ģenerē atslēgu pāri jums un dod publisko atslēgu publicēšanai DNS. Viņi tur privāto atslēgu. Self-hosted mail serveriem (Postfix + OpenDKIM) jūs paši ģenerējat atslēgas, izmantojot opendkim-genkey.

2. solis: Iegūstiet publisko atslēgu vērtību no sūtīšanas servisa. Ielogojieties servisa admin panelī un meklējiet “DKIM” vai “Email authentication” iestatījumus. Serviss sniedz:

• Selector nosaukumu (piem., google, s1, smartlead, default)
• Publiskās atslēgas vērtību (gara base64-encoded virkne)
• DNS ieraksta nosaukumu izmantošanai (formāts ir <selector>._domainkey.<domain>)

Google Workspace konkrēti: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record.

3. solis: Pievienojiet DKIM ierakstu DNS. DKIM ieraksts ir TXT ieraksts. Host/nosaukums ir <selector>._domainkey (piem., google._domainkey vai s1._domainkey). Vērtība ir tā, ko sūtīšanas serviss sniedza, parasti formatēta kā:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK...

Garas DKIM atslēgas var pārsniegt 255 rakstzīmes (limits per TXT-ieraksta virkni). Lielākā daļa DNS piegādātāju apstrādā to automātiski, sadalot vērtību vairākās quoted virknēs vienā ierakstā. Ja jūsu piegādātājs nedara, jums var nākties sadalīt manuāli ar quoted segmentiem.

4. solis: Gaidiet DNS izplatīšanos. Parasti 5–60 minūtes. Daži piegādātāji (Cloudflare, AWS Route53) izplata sekundēs; citi (vecāki registrars) prasa ilgāk.

5. solis: Verificējiet DKIM ierakstu vietā. Palaidiet dig +short TXT <selector>._domainkey.<domain> — jums vajadzētu redzēt DKIM vērtību. Online rīki kā MXToolbox DKIM Lookup vai DKIM Core testing tool arī verificē, ka publiskā atslēga ir sintaktiski derīga.

6. solis: Verificējiet, ka signing strādā. DNS ieraksta pareizība nenozīmē, ka signing strādā. Sūtiet testa e-pastu no sūtīšanas servisa uz testa adresi (Gmail vai Outlook ar redzamām pilnām galvenēm). Apskatiet galvenes — jums vajadzētu redzēt DKIM-Signature galveni izejošajā mail un dkim=pass Authentication-Results galvenē saņemošajā pusē.

Selector stratēģija

Selector ir etiķete, kas ļauj jums būt vairākām DKIM atslēgām vienam domēnam. Produkcijas komandas izmanto selectors stratēģiski:

• Per-servisa selectors: Izmantojot vairākus sūtīšanas servisus (piem., Google Workspace day-to-day mail un Smartlead cold outreach), katrs serviss saņem savu selector. Piemērs: google._domainkey.yourdomain.com un smartlead._domainkey.yourdomain.com. Tas izolē atslēgas uz servisu.

• Rotācija: Produkcijas komandas rotē DKIM atslēgas periodiski (ik pa 6–12 mēnešiem) drošībai. Rotācijas paterns: izvietot jaunu atslēgu ar jaunu selector, pārslēgt sūtīšanu uz jauno selector, atstāt veco selector DNS pāris nedēļas, kamēr in-flight mail pabeidzas, tad noņemt veco selector.

• Subdomain atdalīšana: Izmantojot subdomain dažādiem mērķiem (transakcionāli vs marketinga vs cold outreach), katram subdomain ir savs DKIM ieraksts. Selector var būt tas pats nosaukums cauri subdomains, bet apakšā esošie ieraksti ir dažādi.

Lielākā daļa komandu iestata DKIM vienreiz uz servisu un nerotē pirmajā gadā. Nobriedušas komandas rotē ikgadu kā drošības higiēnas praksi.

Atslēgas garums

DKIM atbalsta 1024-bit un 2048-bit RSA atslēgas. Uz 2026 konsensuss:

• 2048-bit: Standarta rekomendācija. Spēcīgāka kriptogrāfiski, nākotnes-droša. Trūkums: atslēga ir garāka un var prasīt DNS apstrādi multi-string TXT ierakstiem (apskatīts augstāk).
• 1024-bit: Joprojām strādā, joprojām iztur verifikāciju katrā lielākajā saņemošajā sistēmā. Marginālā mērā vājāka, bet operacionāli vienkāršāka.

Produkcijas komandas izmanto 2048-bit, kad DNS piegādātājs apstrādā garus ierakstus tīri (Cloudflare, AWS Route53, lielākā daļa modernu piegādātāju). Izmanto 1024-bit, kad iesprūdis ar vecāku DNS infrastruktūru, kas labi neapstrādā garus ierakstus.

Tipiskas DKIM iestatīšanas kļūdas

Ieraksta pievienošana nepareizajā DNS host. DKIM ierakstam jābūt pie <selector>._domainkey.<domain>, ne pie <domain> pati. Daži DNS UI padara to mulsinošu. Ja verifikācija neizdodas uzreiz pēc iestatīšanas, tas ir pirmais, ko pārbaudīt.

Garu atslēgu truncating. 2048-bit atslēgas pārsniedz 255-zīmju TXT-virknes limitu un vajag sadalīt. DNS piegādātāji parasti to apstrādā, bet copy-paste kļūdas var truncate atslēgu. Vienmēr verificējiet pilnu atslēgu vietā, izmantojot dig +short TXT <selector>._domainkey.<domain>.

Privātās un publiskās atslēgas sajaukšana. DNS ieraksts satur publisko atslēgu. Sūtīšanas serviss tur privāto atslēgu. Nekad nelieciet privāto atslēgu DNS. Lielākā daļa komandu šo kļūdu skaidri nedara, bet reta slikta dokumentācija var pie tās novest.

DKIM iestatīšana, bet nav patiesi signing. DNS ieraksta pievienošana bez sūtīšanas servisa konfigurēšanas signing izejošo mail ražo publicētu publisko atslēgu, kas nekad netiek izmantota. Vienmēr verificējiet, ka izejošais mail patiesi satur DKIM-Signature galvenes.

Vairāki DKIM ieraksti vienā selector. Daži DNS UI ļauj pievienot divus TXT ierakstus vienā host. DKIM gaida vienu ierakstu uz selector; vairāki ieraksti rada verifikācijas neveiksmi.

Neizlīdzinot DKIM ar From-domēnu. DKIM var parakstīt ar vienu domēnu, kamēr e-pasta From-adrese izmanto citu domēnu (kad relay servisi ir iesaistīti). DMARC alignment prasa, lai DKIM-parakstīšanas domēns atbilstu From-domēnam (vai organizācijas domēnam). Ja izmantojat sūtīšanas servisu, kas paraksta ar savu domēnu, nevis jūsu, jums var nākties izmantot custom DKIM iestatīšanu, kas pareizi izlīdzinās.

Signing-verifikācijas soļa izlaišana. Daudzas iestatīšanas neveiksmes iznāk virspusē tikai tad, kad jūs patiesi apskatāt izejošā mail galvenes. DNS ieraksta pareizība negarantē, ka signing notiek. Vienmēr testējiet ar reālu izejošu e-pastu.

Ko darīt pēc tam, kad DKIM ir iestatīts

DKIM ir otrs no trim autentifikācijas gabaliem. Trešais ir DMARC, kas sasaista SPF un DKIM un pievieno policy paziņojumu. Apskatīts detalizēti DMARC policy: quarantine vs reject.

Operacionāli, tiklīdz DKIM ir iestatīts:

1. Verificējiet, ka gan SPF, gan DKIM iztur izejošajam mail no katra sūtīšanas servisa
2. Iestatiet DMARC monitoring režīmā (p=none), lai vāktu datus par autentifikāciju
3. Pārskatiet DMARC atskaites iknedēļas pirmo mēnesi, lai ķertu autentifikācijas problēmas pirms pievilkšanas uz quarantine vai reject

DKIM iestatīšana ir 30–45 minūšu uzdevums, izdarīts vienreiz uz sūtīšanas servisu. Izdarīts pareizi, ražo konsekventu autentifikāciju, kas atbalsta inbox placement; izdarīts nepareizi, klusi neizdodas, un downstream kampaņas veiktspēja krīt.