Настройка SPF, DKIM и DMARC: пошаговая инструкция

Три DNS-записи. Без них Gmail, Yahoo и Mail.ru будут относиться к вашим письмам с подозрением - или просто отклонять. С февраля 2024 года Google требует SPF, DKIM и DMARC от всех отправителей более 5 000 писем в день. Yahoo подтянулся через месяц.

Что делают SPF, DKIM и DMARC

Если коротко: они доказывают, что письмо отправили именно вы, а не кто-то, кто подделал заголовок From. Каждый протокол решает свою часть задачи.

SPF (Sender Policy Framework) - список серверов, которым разрешено отправлять почту от имени вашего домена. Почтовик получает письмо, смотрит IP отправителя, сверяет с SPF-записью в DNS. Совпало - хорошо. Нет - подозрительно.

DKIM (DomainKeys Identified Mail) - криптографическая подпись. Каждое письмо подписывается приватным ключом на сервере отправителя. Принимающий сервер берёт публичный ключ из DNS и проверяет подпись. Если тело или заголовки изменились в пути - подпись не сойдётся.

DMARC (Domain-based Message Authentication, Reporting & Conformance) - политика, которая связывает SPF и DKIM вместе. Говорит принимающему серверу: «Если письмо не прошло проверки - вот что с ним делать». Плюс отчёты: кто отправляет от вашего имени и что с этим происходит.

Шаг 1. Настройка SPF

SPF-запись - это TXT-запись в DNS вашего домена. Она перечисляет, откуда легитимно приходит почта.

Минимальный пример

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

Разбор по частям:

• v=spf1 - версия. Всегда spf1, других нет.
• include:_spf.google.com - разрешает серверам Google Workspace отправлять от вашего имени.
• ~all - soft fail для всех остальных. Письмо не отклоняется, но помечается.

Более реалистичный пример

Допустим, вы используете Google Workspace для корпоративной почты, Mailgun для транзакционных писем и Sendinblue для рассылок.

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:mailgun.org include:sendinblue.com -all"

Здесь -all вместо ~all. Hard fail. Всё, что пришло не от перечисленных сервисов, - отклонить. Жёстче, но безопаснее. Мы рекомендуем -all для продакшена, когда вы точно знаете все свои источники отправки.

Проверка

dig TXT yourdomain.com +short | grep spf

Должна вернуться одна строка, начинающаяся с v=spf1. Именно одна. Две SPF-записи - невалидная конфигурация, провайдер может проигнорировать обе.

Частые ошибки SPF

• Более 10 DNS-запросов. SPF имеет лимит в 10 lookup-ов (include, a, mx, redirect считаются). Превысили - запись невалидна. Проверяйте через dmarcian.com/spf-survey или mxtoolbox.com/spf.aspx.
• Две TXT-записи с v=spf1. Объединяйте всё в одну запись. По RFC 7208 домен должен иметь ровно одну SPF-запись.
• Забыли добавить ESP. Подключили Mailchimp, а в SPF не вписали include:servers.mcsv.net. Результат: письма проваливают SPF-проверку.
• Использование +all. Это разрешает отправку кому угодно. Фактически бессмысленная запись. Мы видели такое в продакшене - и каждый раз это кончалось плохо.

Шаг 2. Настройка DKIM

DKIM работает через пару ключей: приватный (на сервере отправителя) и публичный (в DNS). Сервер подписывает заголовки и тело каждого письма. Принимающая сторона достаёт публичный ключ по селектору из DNS и проверяет подпись.

Генерация ключей

Если вы используете внешний ESP (Mailgun, SendGrid, Postmark) - они генерируют ключи за вас. Вы просто добавляете CNAME или TXT-запись. Если настраиваете свой сервер (Postfix, Exim, Haraka):

# Генерация 2048-bit RSA ключа
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Извлечь публичный ключ одной строкой (для DNS)
grep -v "^-" dkim_public.pem | tr -d '\n'

DNS-запись

Публичный ключ размещается как TXT-запись по адресу selector._domainkey.yourdomain.com. Selector - произвольная строка, которую вы выбираете сами. Обычно это s1, mail, google или название ESP.

s1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K...ваш_ключ..."

Длина TXT-записи для 2048-битного ключа превышает 255 символов. Большинство DNS-провайдеров автоматически разбивают запись на чанки. Cloudflare, Route53, DNSimple - делают это прозрачно. Если ваш провайдер не справляется - разбейте строку вручную на части по 255 символов в кавычках.

Проверка

dig TXT s1._domainkey.yourdomain.com +short

Ответ должен содержать v=DKIM1 и публичный ключ. Нет ответа - либо неправильный селектор, либо запись ещё не пропагировалась (TTL обычно 300-3600 секунд).

Частые ошибки DKIM

• 1024-битный ключ. Работает, но Google с 2023 рекомендует минимум 2048 бит. Некоторые провайдеры уже штрафуют за короткие ключи.
• Неправильный селектор в конфиге. В Postfix написали selector=mail, а в DNS создали запись для s1._domainkey. Подпись не пройдёт - селектор не совпадает.
• Пробелы или переносы строк в ключе. Публичный ключ в DNS должен быть непрерывной строкой base64 (внутри кавычек). Лишний перенос - и ключ невалиден.
• Ротация ключей. Мало кто об этом думает, но ключи стоит менять раз в 6-12 месяцев. Создайте новый селектор (s2), добавьте запись, переключите сервер, потом удалите старый. Downtime - ноль, если делать в правильном порядке.

Шаг 3. Настройка DMARC

DMARC объединяет SPF и DKIM в одну политику. Без DMARC почтовый провайдер решает сам, что делать с непрошедшим письмом. С DMARC - вы говорите ему, что делать.

Начальная запись

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100"

Разбор:

• v=DMARC1 - версия. Единственная.
• p=none - политика: ничего не делать, только собирать отчёты. Начинайте с этого.
• rua - адрес для агрегированных отчётов (XML, приходят раз в сутки).
• ruf - адрес для forensic-отчётов (детали каждого провала). Gmail их не шлёт, Yahoo - шлёт.
• pct=100 - процент писем, к которым применяется политика.

Путь к p=reject

По нашему опыту, переход занимает 4-8 недель. Торопиться не надо - одна забытая интеграция, и ваши легитимные письма полетят в корзину.

Схема:

1. Неделя 1-2: p=none. Собираете отчёты. Смотрите, кто отправляет от имени вашего домена. Часто обнаруживаются сервисы, о которых вы забыли: CRM, тикетная система, инструмент для опросов.
2. Неделя 3-4: p=quarantine; pct=25. Четверть непрошедших писем уходит в спам. Мониторите жалобы и bounce rate.
3. Неделя 5-6: p=quarantine; pct=100. Все непрошедшие - в спам. Если тишина - всё чисто.
4. Неделя 7-8: p=reject. Полная защита. Поддельные письма отклоняются на уровне SMTP.

Проверка

dig TXT _dmarc.yourdomain.com +short

Должна вернуться строка, начинающаяся с v=DMARC1. Если пусто - либо ошибка в имени записи (забыли _dmarc. в начале), либо DNS ещё не обновился.

Частые ошибки DMARC

• Сразу p=reject. Без фазы мониторинга. Мы проверяли: у 40% доменов при переходе на p=reject без подготовки обнаруживается минимум один забытый сервис-отправитель. Итог - потеря легитимной почты.
• Нет rua-адреса. DMARC без отчётов - как мониторинг без алертов. Формально работает, практически бесполезен. Используйте бесплатные парсеры: DMARC Analyzer, Postmark DMARC, dmarcian free tier.
• Несовпадение alignment. DMARC проверяет, что домен в From совпадает с доменом в SPF (envelope-from) или DKIM (d= тег). Если ваш ESP отправляет от своего домена в envelope-from, SPF alignment провалится. Нужен DKIM alignment - или настроить custom return-path.

Alignment: деталь, которая ломает всё

DMARC требует, чтобы хотя бы один из протоколов (SPF или DKIM) прошёл проверку И совпал по домену с заголовком From. Это называется alignment. Без него DMARC не пройден, даже если SPF и DKIM по отдельности работают.

Пример. Вы отправляете от team@yourdomain.com. ESP использует bounce-12345@esp.com как envelope-from. SPF проверяется для esp.com, а From - это yourdomain.com. Домены разные. SPF alignment провален.

Решение: настроить DKIM с d=yourdomain.com (большинство ESP позволяют это через custom DKIM). Тогда DKIM alignment пройдёт, и DMARC будет доволен. Или настроить custom return-path (subdomain типа mail.yourdomain.com), тогда SPF alignment тоже сойдётся.

Проверка всего вместе

После настройки отправьте тестовое письмо на Gmail-аккаунт. Откройте письмо, нажмите «Показать оригинал» (Show original). В заголовках увидите:

Authentication-Results: mx.google.com;
    dkim=pass header.i=@yourdomain.com header.s=s1;
    spf=pass (google.com: domain of team@yourdomain.com designates 198.51.100.42 as permitted sender);
    dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=yourdomain.com

Три pass - значит всё работает. Если видите fail или softfail - возвращайтесь к соответствующему шагу.

Инструменты для диагностики

• mail-tester.com - отправляете письмо на сгенерированный адрес, получаете оценку от 0 до 10 с детальным разбором SPF, DKIM, DMARC.
• mxtoolbox.com - проверка DNS-записей, блеклистов, SMTP-диагностика. Самый используемый инструмент в индустрии.
• Google Postmaster Tools - если шлёте на Gmail, здесь видно репутацию домена и IP, процент спама, ошибки аутентификации.
• dig / nslookup - для быстрой проверки прямо из терминала. Никакого GUI, зато мгновенно.

Полный чеклист dig-команд:

# SPF
dig TXT yourdomain.com +short | grep spf

# DKIM (подставьте ваш selector)
dig TXT s1._domainkey.yourdomain.com +short

# DMARC
dig TXT _dmarc.yourdomain.com +short

# MX (бонус - убедиться, что домен вообще принимает почту)
dig MX yourdomain.com +short

Что насчёт субдоменов

DMARC-политика основного домена по умолчанию распространяется на субдомены (через тег sp=). Но SPF и DKIM нужно настраивать отдельно для каждого субдомена, с которого идёт отправка.

Типичная схема для средней компании:

• yourdomain.com - корпоративная почта (Google Workspace, Exchange)
• mail.yourdomain.com - маркетинговые рассылки (ESP)
• notify.yourdomain.com - транзакционные уведомления (Postmark, SES)

Каждый субдомен - свой SPF, свой DKIM-селектор. Это больше работы, зато репутация маркетинговых рассылок не влияет на транзакционные письма. А это критично: уведомление о сбросе пароля не должно попадать в спам из-за того, что промо-рассылка набрала жалоб.