SPF vs DKIM: kāda atšķirība un kāpēc vajag abus

SPF vs DKIM ir viens no biežākajiem apjukuma punktiem e-pasta autentifikācijā. Dažas komandas domā, ka tie ir alternatīvas — jūs izvēlaties vienu. Citas pieņem, ka tie dara to pašu. Ne viens, ne otrs nav patiess. SPF un DKIM atrisina dažādas problēmas, izmanto dažādus mehānismus, un abi ir vajadzīgi pareizai e-pasta autentifikācijai 2026. Šis raksts paskaidro, ko katrs dara, kā tie atšķiras, kāpēc vajag abus un kā DMARC tos sasaista. Pāris ar SPF iestatīšanas ceļvedi, DKIM iestatīšanas ceļvedi un DMARC policy ceļvedi.

SPF autentificē sūtīšanas IP; DKIM autentificē ziņojuma saturu. Tie atbild uz dažādiem jautājumiem: SPF jautā “vai šis serveris ir autorizēts sūtīt šim domēnam?” DKIM jautā “vai šis ziņojums ir mainīts kopš tā sūtīšanas?” Abām pārbaudēm jāizturēja, lai DMARC uzskatītu e-pastu par pareizi autentificētu.

Ko SPF dara

SPF (Sender Policy Framework) ir IP-bāzēts autentifikācijas mehānisms. Domēna īpašnieks publicē DNS ierakstu, kas saraksta IP adreses (vai hostname), autorizētas sūtīt mail no domēna. Kad saņemošais serveris saņem mail, claiming būt no domēna, tas pārbauda sūtīšanas IP pret SPF ierakstu.

Ja IP ir sarakstā → SPF iztur. Ja IP nav sarakstā → SPF neizdodas.

Mehānisms ir binārs un balstīts uz vienu signālu: IP, kas piegādāja mail saņemošajam serverim.

SPF stiprās puses: vienkārši iestatāms (viens DNS ieraksts), ātri pārbaudāms (viens lookup), zems overhead.

SPF vājās puses: viegli salūzt, kad mail tiek pārsūtīts (pārsūtīšana maina sūtīšanas IP). Neautentificē ziņojuma saturu — tikai sūtīšanas avotu. Var neizdoties edge cases kā mailing lists, kas re-izplata mail caur dažādiem IP.

Ko DKIM dara

DKIM (DomainKeys Identified Mail) ir kriptogrāfijas-bāzēts autentifikācijas mehānisms. Sūtīšanas serveris paraksta e-pasta saturu ar privāto atslēgu; saņemošais serveris ielādē atbilstošo publisko atslēgu no DNS un verificē parakstu.

Ja paraksts verificējas → DKIM iztur (ziņojumu parakstīja kāds ar privāto atslēgu un nav mainīts). Ja paraksts neverificējas → DKIM neizdodas.

Mehānisms pārbauda divas lietas uzreiz: ka ziņojums nāk no kāda, autorizēta parakstīt domēnam (viņiem ir privātā atslēga), un ka ziņojuma saturs nav modificēts pārvades laikā.

DKIM stiprās puses: pārdzīvo mail pārsūtīšanu (paraksts ceļo ar ziņojumu). Autentificē ziņojuma saturu, ne tikai avotu. Robusts pret tampering.

DKIM vājās puses: sarežģītāks iestatīt nekā SPF (atslēgas ģenerēšana, DNS konfigurācija, signing konfigurācija sūtīšanas serverī). Nedaudz vairāk apstrādes overhead uz ziņojumu.

Side-by-side salīdzinājums

Aspekts	SPF	DKIM
Kas tiek autentificēts	Sūtīšanas IP	Ziņojuma saturs + sūtītājs
Mehānisms	DNS lookup of IP saraksts	Kriptogrāfisks paraksts
Pārdzīvo pārsūtīšanu	Nē	Jā
Iestatīšanas sarežģītība	Zema	Vidēja
Ietekmē maršrutēšanas izmaiņas	Jā	Nē
Pievieno izmēru ziņojumiem	Nē (tikai DNS pārbaude)	Jā (paraksts galvenēs)
Verificē	Visi lielākie saņēmēji	Visi lielākie saņēmēji

Kāpēc vajag abus

2026 “vai nu SPF, vai DKIM” nav pietiekami cold email. Iemesli:

DMARC alignment prasa, lai abi izturētu tīri. DMARC (policy slānis virs SPF un DKIM) prasa, lai vai nu SPF, vai DKIM izturētu ar alignment uz From-domēnu. Praksē alignment uzticamāks ar DKIM (jo paraksti ceļo ar pārsūtīto mail), bet DMARC strādā vislabāk, kad abi iztur.

Saņemošās sistēmas sver abus signālus. Gmail, Outlook, Yahoo visi factor SPF un DKIM savos spam klasifikatoros. Having one iztur un one neizdodas — dzeltens karogs; having abi iztur — spēcīgākais leģitīmā-sūtītāja signāls. Having neviens neiztur essentially garantē spam mapes placement.

Dažādi neveiksmju režīmi tiek noķerti ar dažādām pārbaudēm. SPF noķer “kāds izmanto manu domēnu no neautorizēta IP”. DKIM noķer “ziņojums ir mainīts vai parakstīts no kāda bez privātās atslēgas”. Spam kampaņa, kas spoofo jūsu domēnu, varētu izturēt vienu, bet neizdoties otru; izturēt abus daudz grūtāk fake.

Atjaunošanas ceļi atšķiras. Kad SPF salūzt (piem., sūtīšanas servisa IP mainās), DKIM joprojām iztur, ja pareizi konfigurēts — tā autentifikācija pilnībā neneizdodas. Kad DKIM salūzt (piem., atslēgas rotācija iet greizi), SPF joprojām iztur — tā autentifikācija pilnībā neneizdodas. Redundance nodrošina noturību.

Kā DMARC tos sasaista

DMARC ir policy slānis virsū. Tas izmanto SPF un DKIM rezultātus plus alignment pārbaudi, lai izlemtu, ko darīt ar e-pastu.

DMARC alignment pārbaude prasa, lai vai nu SPF domēns vai DKIM domēns atbilstu (vai izlīdzinātos ar) From-adreses domēnu. Tā:

• SPF iztur ar pareizu alignment → DMARC var izturēt
• DKIM iztur ar pareizu alignment → DMARC var izturēt
• Abi iztur ar alignment → spēcīgākā autentifikācija
• Neviens neiztur ar alignment → DMARC neizdodas

DMARC policy (p=none, p=quarantine, p=reject) paziņo saņemošajām sistēmām, ko darīt, kad DMARC neizdodas (apskatīts detalizēti DMARC policy ceļvedī).

Produkcijā mērķis nav izvēlēties starp SPF un DKIM — tas ir iestatīt abus pareizi, lai DMARC abus izturētu kā belt-and-suspenders. Kombinētā sistēma apstrādā edge cases, ko jebkurš atsevišķs mehānisms neizdotu.

Tipiski apjukuma punkti

“Mums ir SPF, tāpēc mums nevajag DKIM.” Nepareizi. SPF vien nav pietiekams DMARC alignment daudzos reālos scenārijos (pārsūtīšana, mailing lists, multi-domain sūtīšana). DKIM ir nepieciešams noturībai.

“DKIM ir svarīgāks, tāpēc mēs izlaidīsim SPF.” Nepareizi citā virzienā. SPF ir pirmā autentifikācijas pārbaude, ko lielākā daļa saņēmēju vada; SPF neveiksme ieliek mail back foot, pirms DKIM vispār tiek novērtēts. Abi svarīgi.

“SPF un DKIM autentificē to pašu citādāk.” Subtili nepareizi. Tie autentificē dažādus aspektus — IP vs saturs. Redundance ir tīša.

“DMARC aizvieto SPF un DKIM.” Nepareizi. DMARC ir policy slānis, kas atkarīgs no SPF un DKIM. Bez tiem DMARC nav nekā, ko uzspiest.

“Es varu izmantot tikai vienu, jo sūtītāja serviss apstrādā otru.” Dažreiz patiess vienkāršiem iestatījumiem, bet produkcijas cold email gandrīz vienmēr ietver vairākus sūtīšanas servisus, custom domēnus un edge cases, kur abu paturēšana vietā nodrošina izšķirošu redundanci.

Bottom line: SPF un DKIM nav alternatīvas — tie ir komplementāri autentifikācijas mehānismi, kas atrisina dažādas problēmas. Produkcijas cold email iestatījumi 2026 konfigurē abus, plus DMARC virsū, un verificē alignment katram sūtīšanas servisam. Jebkura no tiem izlaišana atstāj plaisu, ko DMARC nevar pilnībā aizvērt.