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

Три DNS-записи, без которых почтовые сервисы относятся к письмам с подозрением. С февраля 2024 года Gmail требует и SPF, и DKIM, и DMARC от тех, кто шлёт на личные ящики Gmail больше 5 000 писем в день. Yahoo ввёл похожие требования для массовых отправителей в том же феврале. Подробности в разборах требований Gmail и требований Yahoo.

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

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

SPF (Sender Policy Framework) это список серверов, которым разрешено отправлять почту от имени вашего домена. Почтовик получает письмо, смотрит IP отправителя, сверяет с SPF-записью в DNS. Если IP в списке есть, проверка пройдена, если нет, письмо выглядит подозрительно. Содержимое SPF не проверяет вовсе: письмо со взломанного аккаунта в вашем ESP уйдёт с разрешённого сервера и SPF пройдёт. Целостность самого письма проверяет уже DKIM.

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

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. Именно одна. При двух записях проверка по RFC 7208 заканчивается ошибкой permerror, и SPF не работает вовсе.

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

• Более 10 DNS-запросов. SPF имеет лимит в 10 lookup-ов, и в счёт идут include, a, mx, ptr, exists и redirect. Если запросов больше, запись считается невалидной. Проверяйте через dmarcian.com/spf-survey или mxtoolbox.com/spf.aspx.
• Две TXT-записи с v=spf1. Объединяйте всё в одну запись. По RFC 7208 домен должен иметь ровно одну SPF-запись.
• Забыли добавить сервис рассылок. Подключили новый сервис, а его include в SPF не вписали, и письма проваливают SPF-проверку. Значение берите из документации сервиса: у многих конверт письма идёт с их собственного домена, и тогда include не нужен вовсе.
• Использование +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-панелей делит её на строки сама, в других это приходится делать вручную: части по 255 символов в кавычках подряд. Получатель склеивает их без пробелов, поэтому лишний пробел на стыке ломает ключ.

Проверка

dig TXT s1._domainkey.yourdomain.com +short

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

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

• 1024-битный ключ. Работает: RFC 8301 обязывает получателей принимать ключи от 1024 бит, но подписывать советует ключом не короче 2048.
• Неправильный селектор в конфиге. В Postfix написали selector=mail, а в DNS создали запись для s1._domainkey. Подпись не пройдёт, селектор не совпадает.
• Пробелы или переносы строк в ключе. Публичный ключ в DNS должен быть непрерывной строкой base64 внутри кавычек. Лишний перенос, и ключ невалиден.
• Ротация ключей. Мало кто об этом думает, но ключи стоит менять регулярно, подробнее об этом в статье о ротации ключей DKIM. Создайте новый селектор (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-отчётов (детали каждого провала). В них фрагменты писем, поэтому многие провайдеры их не отправляют.
• Тега 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. Флаг t=y по RFC 9989 просит получателя не применять политику целиком, а опуститься на ступень ниже: для quarantine это none, для reject это quarantine. Смотрите отчёты, мониторите жалобы и 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. Без фазы мониторинга. Почти всегда находится забытый сервис-отправитель, и итогом будет потеря легитимной почты.
• Нет 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 тоже сойдётся.

Пересылка ломает SPF, но не DKIM

Когда получатель пересылает письмо, дальше его отправляет уже почтовый сервер получателя со своего IP, и SPF исходного домена не сходится. Подпись DKIM при этом остаётся верной, если письмо по дороге не меняли. Поэтому DMARC требует пройти хотя бы одну проверку из двух, а подпись DKIM своим доменом важнее SPF. Списки рассылки, которые дописывают футер, ломают и подпись, для таких посредников есть ARC (RFC 8617): он передаёт получателю результаты проверок, сделанных до изменения письма.

Как читать отчёты DMARC

Агрегированные отчёты приходят XML-файлом в архиве. Для каждого IP, с которого шла почта от вашего домена, там указано число писем, результат SPF и DKIM и применённая политика. Смысл первых недель в инвентаризации: найти всех своих отправителей и довести их до прохождения проверок. Читать XML глазами неудобно, поэтому отчёты обычно отправляют в сервис-анализатор. Если его домен чужой, он должен подтвердить приём отчётов записью в DNS, иначе отчёты не дойдут. Как это проверить, разобрано в проверке DMARC.

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

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

Когда все три записи работают и политика DMARC строже none, можно добавить логотип рядом с письмом через BIMI. Запись собирается в генераторе BIMI.