SPF vs DKIM: в чём разница и зачем нужны оба

SPF vs DKIM — одна из самых частых точек confusion в email-аутентификации. Некоторые команды думают, что они alternatives — выбираете один. Другие предполагают, что они делают то же самое. Ни одно не верно. SPF и DKIM решают разные проблемы, используют разные механизмы, и оба нужны для proper email authentication в 2026. Эта статья объясняет, что каждый делает, как они различаются, зачем нужны оба и как DMARC связывает их. Пара к гайду по SPF setup, гайду по DKIM setup и гайду по DMARC policy.

SPF аутентифицирует sending IP; DKIM аутентифицирует message content. Они отвечают на разные вопросы: SPF спрашивает “авторизован ли этот сервер шлать для этого домена?” DKIM спрашивает “был ли изменён этот message с момента отправки?” Обе проверки должны проходить, чтобы DMARC считал email properly authenticated.

Что SPF делает

SPF (Sender Policy Framework) — IP-based механизм аутентификации. Domain owner публикует DNS-запись, listing IP-адреса (или hostname), authorized шлать mail с домена. Когда receiving-сервер получает mail, claiming быть с домена, он проверяет sending IP против SPF-записи.

Если IP в списке → SPF pass. Если IP не в списке → SPF fail.

Механизм бинарный и основан на одном сигнале: IP, доставивший mail receiving-серверу.

Сильные стороны SPF: simple для setup (одна DNS-запись), fast для check (один lookup), low overhead.

Слабые стороны SPF: ломается easily, когда mail forwarded (forwarding меняет sending IP). Не аутентифицирует message content — только sending source. Может fail в edge cases вроде mailing list, которые re-distribute mail через разные IP.

Что DKIM делает

DKIM (DomainKeys Identified Mail) — cryptographic-based механизм аутентификации. Sending-сервер signs email’s content с private key; receiving-сервер fetches matching public key из DNS и верифицирует signature.

Если signature verifies → DKIM pass (message был signed кем-то с private key и не был altered). Если signature не verifies → DKIM fail.

Механизм проверяет две вещи at once: что message приходит от кого-то authorized to sign для домена (у них есть private key), и что message content не был modified in transit.

Сильные стороны DKIM: survives mail forwarding (signature travels с message). Аутентифицирует message content, не только source. More robust против tampering.

Слабые стороны DKIM: more complex для setup, чем SPF (key generation, DNS-конфигурация, signing-конфигурация на sending-сервере). Slightly more processing overhead per message.

Side-by-side сравнение

Aspect	SPF	DKIM
Что аутентифицируется	Sending IP	Message content + sender
Mechanism	DNS lookup of IP list	Cryptographic signature
Survives forwarding	Нет	Да
Setup complexity	Low	Medium
Affected by routing changes	Да	Нет
Adds size to messages	Нет (DNS-only check)	Да (signature в headers)
Verified by	Все major receivers	Все major receivers

Почему нужны оба

В 2026 “либо SPF, либо DKIM” не sufficient для cold email. Причины:

DMARC alignment требует, чтобы оба passed cleanly. DMARC (policy слой поверх SPF и DKIM) требует, чтобы либо SPF, либо DKIM passed with alignment к From-домену. На практике, alignment more reliable с DKIM (потому что signatures travel с forwarded mail), но DMARC works best, когда оба passing.

Receiving-системы weight оба сигнала. Gmail, Outlook, Yahoo все factor SPF и DKIM в свои spam classifiers. Having one pass и one fail — yellow flag; having оба pass — сильнейший legitimate-sender сигнал. Having neither pass essentially гарантирует spam folder placement.

Разные failure mode caught разными checks. SPF ловит “кто-то использует мой домен с unauthorized IP”. DKIM ловит “message был altered или signed кем-то без private key”. Spam-кампания, spoofing ваш домен, могла бы pass one, но fail other; passing оба much harder to fake.

Recovery paths differ. Когда SPF ломается (например, IP sending-сервиса меняется), DKIM всё ещё проходит, если configured correctly — так что authentication не полностью fails. Когда DKIM ломается (например, key rotation goes wrong), SPF всё ещё проходит — так что authentication не полностью fails. Redundancy provides resilience.

Как DMARC связывает их

DMARC — policy слой сверху. Он использует SPF и DKIM results плюс alignment check, чтобы decide, что делать с email.

DMARC alignment check требует, чтобы либо SPF домен, либо DKIM домен матчили (или aligning с) From-address домен. Так:

• SPF passes с proper alignment → DMARC может pass
• DKIM passes с proper alignment → DMARC может pass
• Оба pass с alignment → сильнейшая authentication
• Ни один не pass с alignment → DMARC fails

DMARC policy (p=none, p=quarantine, p=reject) говорит receiving-системам, что делать, когда DMARC fails (разобрано в деталях в гайде по DMARC policy).

В продакшене цель — не выбирать между SPF и DKIM — это set up оба correctly, чтобы DMARC had оба passing как belt-and-suspenders. Combined system handle edge cases, которые any single механизм would fail.

Типичные точки confusion

“У нас есть SPF, так что DKIM не нужен.” Неверно. SPF alone не sufficient для DMARC alignment во многих real-world сценариях (forwarding, mailing list, multi-domain sending). DKIM нужен для resilience.

“DKIM more important, так что мы skip SPF.” Неверно в другом направлении. SPF — первая authentication check, которую большинство receivers run; failing SPF ставит mail на back foot до того, как DKIM даже gets evaluated. Оба matter.

“SPF и DKIM аутентифицируют то же самое differently.” Subtly неверно. Они аутентифицируют разные аспекты — IP vs content. Redundancy intentional.

“DMARC заменяет SPF и DKIM.” Неверно. DMARC — policy слой, зависящий от SPF и DKIM. Без них DMARC nothing to enforce.

“Я могу использовать только один, потому что sender service handle другой.” Sometimes true для simple setup, но продакшен cold email almost always involves multiple sending-сервисов, custom доменов и edge cases, где having оба in place provides crucial redundancy.

Bottom line: SPF и DKIM не alternatives — это комплементарные механизмы аутентификации, решающие разные проблемы. Продакшен cold email setup в 2026 конфигурируют оба плюс DMARC сверху и верифицируют alignment для каждого sending-сервиса. Skipping either leaves gap, который DMARC не может полностью close.