Настройка 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"

Разбор:

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

Путь к p=reject

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

Схема:

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

В прежней версии этой схемы на третьей неделе стоял pct=25, и в спам уходила четверть писем. Реализации RFC 9989 этот тег пропускают и применяют политику целиком, поэтому переходный режим теперь задают флагом t=y.

Проверка

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-селектор. Это больше работы, зато репутация маркетинговых рассылок не влияет на транзакционные письма. А это критично: уведомление о сбросе пароля не должно попадать в спам из-за того, что промо-рассылка набрала жалоб.