Как настроить SPF, DKIM и DMARC для домена и проверить, что письма доходят

Если письма с сайта WordPress, интернет-магазина или корпоративного домена уходят в спам или не доходят вовсе, почти всегда нужно смотреть не только на сам сайт, но и на доменную аутентификацию. SPF, DKIM и DMARC не гарантируют попадание во «Входящие», но без них современная почта часто относится к отправителю с недоверием. Особенно это заметно у писем с форм обратной связи, уведомлений WooCommerce, восстановления пароля и других транзакционных сообщений.

Ниже разберём, какие DNS-записи нужны, как их правильно собрать под ваш способ отправки и как проверить, что всё работает не только «по записи в DNS», но и на практике.

Что делают SPF, DKIM и DMARC и почему без них письма хуже доходят

Эти три механизма решают разные задачи.

SPF показывает, каким серверам разрешено отправлять письма от имени домена. Почтовый сервер получателя сверяет IP отправителя с SPF-записью в DNS.

DKIM добавляет к письму криптографическую подпись. Получатель проверяет, что письмо действительно было подписано ключом домена и не было изменено по пути.

DMARC связывает SPF и DKIM с доменом в поле From и задаёт политику: что делать, если проверка не проходит. DMARC также позволяет получать отчёты о том, кто отправляет письма от имени домена.

На практике это означает простую вещь: если вы отправляете письма с сайта через хостинг, SMTP-сервис или почтовую систему, получатель должен видеть, что отправка действительно разрешена владельцем домена. Иначе письмо может попасть в спам, быть помечено как подозрительное или отклонено ещё на этапе приёма.

Сначала определите, откуда именно идут письма

Перед настройкой DNS важно понять источник отправки. Ошибка многих владельцев сайтов в том, что они добавляют записи «наугад», не сверив реальный маршрут письма.

Есть три типичных сценария:

• сайт отправляет письма через встроенную функцию хостинга;
• WordPress подключён к стороннему SMTP-сервису;
• почта отправляется через корпоративный почтовый сервис, например Google Workspace, Microsoft 365 или другой провайдер.

SPF и DKIM должны соответствовать именно тому сервису, который фактически отправляет письмо. Если WordPress настроен на SMTP-сервис, а в DNS указан только хостинг, аутентификация может не пройти.

Для WordPress это особенно важно: системные письма, уведомления плагинов, формы обратной связи и письма WooCommerce часто уходят не с того сервера, который вы ожидаете. Поэтому сначала проверьте настройки отправки в плагине SMTP или в панели хостинга, а уже потом правьте DNS.

Какие DNS-записи нужны

Минимальный набор для нормальной отправки обычно выглядит так:

• SPF — одна TXT-запись для домена;
• DKIM — одна или несколько TXT-записей с публичным ключом;
• DMARC — отдельная TXT-запись для поддомена _dmarc.

Записи добавляются в DNS-зоне домена у регистратора, в панели хостинга или у DNS-провайдера. Интерфейс у всех разный, но принцип один: вы создаёте TXT-запись с нужным именем и значением.

SPF: как собрать запись без лишних ошибок

SPF-запись всегда одна на домен. Если создать несколько SPF-записей, получатель может считать это ошибкой. Поэтому сначала соберите все источники отправки в одну строку.

Пример базовой записи для домена, который отправляет почту только через один SMTP-сервис:

v=spf1 include:example-smtp-service.com -all

Здесь include означает: разрешить серверам, указанным в SPF-политике этого сервиса. В конце -all говорит, что всё остальное запрещено.

Если письма отправляются и с хостинга, и через сторонний сервис, в SPF должны быть оба источника. Пример может выглядеть так:

v=spf1 include:example-smtp-service.com ip4:203.0.113.10 -all

Но не копируйте этот пример вслепую. В SPF нужно указывать реальные механизмы, которые дал ваш провайдер, и реальные IP, если они используются. Лишние механизмы усложняют запись и могут приблизить вас к лимиту DNS-поисков SPF. Это уже зависит от конкретной конфигурации, но на практике длинный и перегруженный SPF — частая причина проблем.

Если вы не знаете, кто именно отправляет письма, сначала посмотрите заголовки уже доставленного письма или настройки SMTP-плагина. Иначе можно «починить» SPF для одного сервиса и сломать отправку для другого.

DKIM: зачем нужен ключ и где его брать

DKIM обычно выдаёт сам почтовый сервис или SMTP-провайдер. Он даёт вам:

• селектор;
• публичный ключ для DNS;
• иногда готовую TXT-запись целиком.

Запись публикуется в DNS в виде TXT для имени, которое обычно выглядит как selector._domainkey. Например:

selector1._domainkey.example.com

Само значение записи содержит публичный ключ. Формат зависит от провайдера, но обычно это строка вида:

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

Важно не путать DKIM-ключи разных сервисов. Если вы сменили SMTP-провайдера, старый DKIM для нового сервиса не подойдёт. У каждого сервиса свой ключ и свой селектор.

После публикации записи провайдер обычно предлагает включить подпись в панели. Без этого ключ в DNS сам по себе ничего не даст: письмо должно быть подписано на стороне отправителя.

DMARC: с чего начать, если домен ещё не настроен

DMARC помогает связать SPF и DKIM с доменом в поле From и задать политику обработки писем, которые не прошли проверку. Для старта лучше не ставить жёсткий запрет сразу, если вы не уверены, что все легитимные отправители учтены.

Базовая запись для начала может быть такой:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Здесь p=none означает режим наблюдения: письма не блокируются только из-за DMARC, а отчёты приходят на указанный адрес. Это полезно на этапе настройки, когда вы ещё проверяете, кто реально отправляет почту от имени домена.

Позже, когда SPF и DKIM стабильно проходят проверку, политику можно ужесточить до quarantine или reject. Но делать это стоит только после проверки, иначе можно случайно начать отклонять свои же письма.

Пошаговая схема настройки

Если упростить процесс, он выглядит так:

1. Определите, какой сервис реально отправляет письма.
2. Возьмите у него SPF- и DKIM-параметры.
3. Добавьте TXT-запись SPF в DNS домена.
4. Добавьте DKIM-запись(и) в DNS.
5. Создайте DMARC-запись в режиме p=none.
6. Подождите обновления DNS.
7. Проверьте заголовки тестового письма и отчёты DMARC.

Если у вас WordPress, отдельно проверьте, что сайт действительно отправляет письма через нужный канал. Часто проблема не в DNS, а в том, что плагин SMTP не подключён, неверно указан логин, не проходит авторизация или хостинг блокирует исходящую почту.

Как проверить, что SPF, DKIM и DMARC работают

Проверка должна быть в двух местах: в DNS и в самом письме.

Сначала убедитесь, что записи опубликованы. Для этого можно использовать любой DNS-проверяющий сервис или команду dig, если вам удобно работать из терминала. Например:

dig TXT example.com

Или для DMARC:

dig TXT _dmarc.example.com

Но наличие записи в DNS ещё не означает, что письмо проходит проверку. Главное — посмотреть заголовки реального письма, отправленного на внешний ящик, например Gmail, Outlook или Яндекс Почту. В заголовках ищите результаты вроде:

• spf=pass или spf=fail;
• dkim=pass или dkim=fail;
• dmarc=pass или dmarc=fail.

Если у вас есть доступ к почтовому ящику получателя, откройте полные заголовки письма. В Gmail это делается через пункт «Показать оригинал». В других сервисах название может отличаться, но смысл один: нужен полный технический заголовок, а не только текст письма.

Дополнительно можно отправить тест на сервисы, которые показывают оценку письма и разбор аутентификации. Это полезно, когда нужно быстро понять, что именно не проходит: SPF, DKIM, DMARC, IP-репутация или содержимое письма.

Если письма всё равно попадают в спам

Даже при корректных SPF, DKIM и DMARC письмо может оказаться в спаме. Это нормально: почтовые системы смотрят не только на аутентификацию, но и на репутацию домена, IP-адреса, содержание письма, частоту отправки и реакцию получателей.

Проверьте несколько вещей:

• отправка идёт с того домена, который указан в From;
• SPF не содержит лишних или конфликтующих механизмов;
• DKIM подписывает именно тот домен, от имени которого отправляется письмо;
• DMARC не конфликтует с поддоменами и сторонними сервисами;
• в письме нет подозрительных ссылок, битых изображений и слишком агрессивных маркетинговых формулировок;
• у домена нет плохой репутации из-за прошлых массовых рассылок или компрометации.

Если письма с сайта идут через хостинг, а хостинг использует общий IP с другими клиентами, репутация может зависеть не только от вас. В таком случае переход на отдельный SMTP-сервис часто помогает, но не решает всё автоматически: DNS и содержимое письма всё равно должны быть в порядке.

Типичные ошибки при настройке

На практике чаще всего мешают не сложные технические проблемы, а несколько повторяющихся ошибок.

• Несколько SPF-записей вместо одной объединённой записи.
• DKIM добавили в DNS, но не включили подпись в почтовом сервисе.
• DMARC поставили сразу на reject, не проверив все источники отправки.
• В From указан один домен, а отправка идёт с другого.
• WordPress шлёт письма через хостинг, хотя SMTP-плагин настроен на другой сервис.
• DNS-запись добавили не в ту зону, например у регистратора вместо фактического DNS-провайдера.

Если вы не уверены, где именно управляется DNS, проверьте NS-записи домена. Это покажет, какой сервис сейчас отвечает за зону. Иначе можно долго искать ошибку в панели, которая вообще не обслуживает домен.

Когда стоит обращаться к хостингу или SMTP-провайдеру

Самостоятельно вы можете проверить DNS, настройки WordPress и заголовки письма. Но есть ситуации, где без поддержки не обойтись:

• SMTP-сервис не выдаёт DKIM или SPF-параметры;
• исходящая почта блокируется на уровне хостинга;
• письма уходят, но сервер получателя отклоняет их по причине репутации IP;
• нужно понять, почему письма не подписываются DKIM на стороне провайдера;
• в DMARC-отчётах видно неизвестные источники отправки, которые вы не контролируете.

Для владельца сайта это нормальная граница: DNS и базовую проверку можно сделать самому, а проблемы на стороне почтовой инфраструктуры, IP-репутации и серверных ограничений лучше разбирать с тем, кто управляет отправкой.

Если коротко: для нормальной доставляемости вам нужны корректные SPF и DKIM для реального отправителя, DMARC в режиме наблюдения на старте и проверка заголовков реального письма. Только после этого имеет смысл ужесточать политику и ждать более стабильной доставки. Это не магия и не гарантия «Входящих», но без этой базы почта с сайта почти всегда работает хуже, чем могла бы.