Как настроить DKIM: пошаговый гайд на 2026

Настройка DKIM — второй из трёх шагов аутентификации, нужных каждому B2B cold email отправителю в 2026. В отличие от SPF (авторизующего IP), DKIM cryptographically подписывает сам email — чтобы receiving-серверы могли верифицировать, что сообщение не было модифицировано in transit и что оно реально пришло с вашего домена. Настройка moderately техническая, но predictable, когда следуется правильно. Эта статья проходит через полный DKIM setup process: key generation, конфигурация DNS, selector-стратегия и верификация. Пара к гайду по SPF setup, гайду по DMARC policy и обзору SPF/DKIM/DMARC.

DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к исходящему email. Sending-сервер подписывает сообщение private key; receiving-сервер fetch’ит matching public key из вашего DNS и верифицирует подпись. DKIM-passing email рассматривается как более trustworthy каждой major receiving-системой — а DKIM-failing email рассматривается как сильный spam-сигнал.

Как работает DKIM

Когда ваш mail-сервер шлёт email, он добавляет DKIM-Signature header к сообщению. Подпись computed с использованием private key, который sending-сервер держит, applied через конкретные header-поля и тело сообщения. Header включает имя домена и “selector” (label, идентифицирующий, какой key использовался — полезно при ротации keys).

Когда email приходит на receiving-сервер, сервер:

1. Читает DKIM-Signature header
2. Извлекает домен и selector
3. Ищет public key на <selector>._domainkey.<domain> в DNS
4. Использует public key, чтобы верифицировать подпись

Если подпись верифицируется, DKIM проходит. Если подпись не может быть верифицирована — wrong key, модифицированное сообщение in transit, отсутствующая DNS-запись — DKIM проваливается.

Пошаговый DKIM setup

Точные шаги зависят от того, какой sending-сервис используете, но паттерн консистентный.

Шаг 1: Сгенерируйте или получите public/private key pair. Большинство современных sending-сервисов (Google Workspace, Microsoft 365, Smartlead, Lemlist, Apollo, SendGrid) генерируют key pair для вас и дают public key для публикации в DNS. Они держат private key. Для self-hosted mail серверов (Postfix + OpenDKIM) вы генерируете keys сами, используя opendkim-genkey.

Шаг 2: Получите public key value с вашего sending-сервиса. Войдите в admin-панель сервиса и ищите “DKIM” или “Email authentication” настройки. Сервис предоставляет:

• Selector name (например, google, s1, smartlead, default)
• Public key value (длинная base64-encoded строка)
• DNS record name для использования (формат <selector>._domainkey.<domain>)

Для Google Workspace конкретно: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record.

Шаг 3: Добавьте DKIM-запись в DNS. DKIM-запись — TXT-запись. Host/name — <selector>._domainkey (например, google._domainkey или s1._domainkey). Value — то, что предоставил sending-сервис, обычно отформатированное как:

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

Длинные DKIM keys могут превышать 255 символов (лимит per TXT-record строки). Большинство DNS-провайдеров handle это автоматически путём split value в несколько quoted строк внутри той же записи. Если ваш провайдер не делает, вам может понадобиться split вручную с quoted сегментами.

Шаг 4: Дождитесь DNS-пропагации. Обычно 5–60 минут. Некоторые провайдеры (Cloudflare, AWS Route53) пропагируют в секундах; другие (старые registrars) занимают больше.

Шаг 5: Верифицируйте DKIM-запись на месте. Запустите dig +short TXT <selector>._domainkey.<domain> — вы должны увидеть DKIM value. Online-тулы вроде MXToolbox’s DKIM Lookup или DKIM Core’s testing tool также верифицируют, что public key синтаксически валиден.

Шаг 6: Верифицируйте, что signing работает. Корректность DNS-записи не означает, что signing работает. Шлите тестовый email с sending-сервиса на тестовый адрес (Gmail или Outlook с full headers visible). Inspect headers — вы должны увидеть DKIM-Signature header на исходящем mail и dkim=pass в Authentication-Results header на receiving-стороне.

Selector-стратегия

Selector — label, позволяющий иметь несколько DKIM keys для одного домена. Продакшен-команды используют selectors стратегически:

• Per-service selectors: При использовании нескольких sending-сервисов (например, Google Workspace для day-to-day mail и Smartlead для cold outreach), каждый сервис получает собственный selector. Пример: google._domainkey.yourdomain.com и smartlead._domainkey.yourdomain.com. Это изолирует keys per service.

• Ротация: Продакшен-команды ротируют DKIM keys периодически (каждые 6–12 месяцев) для безопасности. Паттерн ротации: deploy нового key с новым selector, переключение sending на новый selector, оставить старый selector в DNS на пару недель, пока in-flight mail завершится, потом удалить старый selector.

• Subdomain separation: При использовании subdomain для разных целей (transactional vs marketing vs cold outreach), у каждого subdomain собственная DKIM-запись. Selector может быть тем же именем через subdomain, но underlying записи разные.

Большинство команд настраивают DKIM раз per service и не ротируют первый год. Mature-команды ротируют ежегодно как security hygiene-практику.

Длина key

DKIM поддерживает 1024-bit и 2048-bit RSA keys. На 2026 consensus:

• 2048-bit: Стандартная рекомендация. Сильнее криптографически, future-proof. Минус: key длиннее и может требовать DNS handling для multi-string TXT-записей (разобрано выше).
• 1024-bit: Всё ещё работает, всё ещё проходит верификацию на каждой major receiving-системе. Marginally слабее, но operationally проще.

Продакшен-команды используют 2048-bit, когда DNS-провайдер handle длинные записи чисто (Cloudflare, AWS Route53, большинство современных провайдеров). Используют 1024-bit, когда застряли со старой DNS-инфраструктурой, не handling длинные записи хорошо.

Типичные DKIM setup ошибки

Добавление записи на неверном DNS host. DKIM-запись должна быть на <selector>._domainkey.<domain>, не на <domain> самом. Некоторые DNS UI делают это confusing. Если верификация проваливается immediately после setup, это первое для проверки.

Truncating длинных keys. 2048-bit keys превышают 255-char TXT-string лимит и нуждаются в split. DNS-провайдеры обычно handle это, но copy-paste ошибки могут truncate key. Всегда верифицируйте full key на месте, используя dig +short TXT <selector>._domainkey.<domain>.

Смешивание private и public key. DNS-запись содержит public key. Sending-сервис держит private key. Никогда не кладите private key в DNS. Большинство команд explicit’но эту ошибку не делает, но редкая плохая документация может к ней привести.

Setup DKIM, но не actually signing. Добавление DNS-записи без конфигурации sending-сервиса для signing исходящего mail производит published public key, который никогда не используется. Всегда верифицируйте, что исходящий mail actually содержит DKIM-Signature headers.

Multiple DKIM записей на том же selector. Некоторые DNS UI позволяют добавить две TXT-записи на том же host. DKIM ожидает одну запись per selector; multiple записи приводят к verification failure.

Не aligning DKIM с From-доменом. DKIM может подписывать одним доменом, в то время как From-address email’а использует другой домен (когда relay-сервисы involved). DMARC alignment требует, чтобы DKIM-signing домен матчил From-домен (или organizational домен). Если вы используете sending-сервис, подписывающий своим доменом вместо вашего, может понадобиться custom DKIM setup, properly aligning.

Пропуск signing-verification шага. Многие setup-провалы surface только когда вы actually inspect outgoing mail headers. Корректность DNS-записи не гарантирует, что signing случается. Всегда тестируйте с реальным outgoing email.

Что делать после того, как DKIM настроен

DKIM — второй из трёх authentication куска. Третий — DMARC, связывающий SPF и DKIM и добавляющий policy-statement. Разобрано в DMARC policy: quarantine vs reject.

Операционно, как только DKIM настроен:

1. Верифицируйте, что и SPF, и DKIM проходят для исходящего mail с каждого sending-сервиса
2. Настройте DMARC в monitoring mode (p=none), чтобы собирать данные об аутентификации
3. Review DMARC отчёты еженедельно первый месяц, чтобы ловить authentication issues до tightening до quarantine или reject

DKIM setup — 30–45 минут per sending service. Сделанный правильно, производит консистентную аутентификацию, поддерживающую inbox placement; сделанный неправильно, silently fails и downstream campaign-перформанс падает.