SPF, DKIM и DMARC: ваш домен отправляет почту, даже если вы — нет

Зачем любому домену сайта записи почтовой аутентификации, как SPF, DKIM и DMARC работают вместе и как дойти до политики reject, не потеряв собственные письма.

Инфраструктура · Опубликовано: 30 сентября 2026 г. · 6 мин чтения · Анна Ковалёва

«Мы не рассылаем почту» — один из самых частых ответов, когда проверка находит отсутствующую запись SPF или DMARC. И он не по существу. Кто угодно в интернете может поставить ваш домен в поле From. Поверят ли такому письму Gmail или Outlook, решают несколько TXT-записей в вашем DNS, — и если их нет, от имени вашего домена не говорит никто.

Почему это касается владельца сайта

Подделка и фишинг. Без политики DMARC принимающие серверы не получают от вас никаких указаний, что делать с письмами, которые выдают себя за ваш домен и не проходят проверки. Фальшивые счета и письма «сброс пароля» от support@вашдомен отправить дёшево, а доверие к настоящему сайту они подрывают всерьёз.

Ваши собственные уведомления. Формы обратной связи, подтверждения заказов, сброс пароля — даже «статический» сайт обычно что-то отправляет. Обработчик формы, который вызывает PHP mail() прямо с веб-сервера и подставляет в From адрес посетителя, проваливает все проверки и попадает в спам или не доходит вовсе.

Требования почтовых провайдеров. С февраля 2024 года Gmail и Yahoo требуют от всех отправителей SPF или DKIM, а от массовых — и то и другое, плюс запись DMARC (минимум p=none) и домен в From, выровненный хотя бы с одним из них. Другие провайдеры движутся в ту же сторону. Письма, не отвечающие правилам, всё чаще отклоняются, а не просто фильтруются.

SPF: кому можно отправлять

SPF — это TXT-запись на самом домене со списком серверов, которым разрешено отправлять от его имени:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

На чём чаще всего спотыкаются:

• Только одна запись. Две TXT-записи, начинающиеся с v=spf1, — это не «действуют обе», а постоянная ошибка: получатели считают SPF сломанным. Объедините их в одну.
• Десять DNS-запросов. include, a, mx, exists, redirect и ptr стоят по одному запросу, вложенные include тоже считаются. После десятого проверка завершается ошибкой. Прежде чем добавлять новые сервисы, уберите те, которыми больше не пользуетесь.
• Окончание имеет значение. -all означает, что все остальные не проходят; ~all — мягкий отказ, разумный вариант, пока вы ещё собираете список отправителей; +all разрешает отправку всему интернету и хуже, чем отсутствие записи.

SPF проверяет адрес отправителя в конверте (адрес для возвратов), а не заголовок From, который видит пользователь. Поэтому одного SPF недостаточно.

DKIM: подпись на каждом письме

DKIM подписывает исходящие письма закрытым ключом, а открытый ключ публикуется в DNS под селектором:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Каждый сервис-отправитель — почтовый провайдер, инструмент рассылок, API транзакционной почты — выдаёт свой селектор и ключ или CNAME на запись, которой управляет сам. Используйте 2048-битные ключи RSA, если провайдер это позволяет, и удаляйте селекторы сервисов, от которых отказались. В отличие от SPF, подпись DKIM переживает пересылку, поэтому из двух механизмов она надёжнее.

DMARC: политика, которая всё связывает

DMARC находится по адресу _dmarc и говорит получателям, что делать с письмом, не прошедшим проверку, и куда присылать отчёты:

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

Письмо проходит DMARC, если SPF или DKIM прошли и домен, для которого они прошли, выровнен с доменом в From. SPF, прошедший для домена возвратов вашего почтового сервиса, не засчитывается; подпись DKIM с d=example.com — засчитывается.

Внедряйте поэтапно:

1. p=none с отчётами rua. Ничего не блокируется; вы получаете ежедневные агрегированные XML-отчёты обо всех серверах, отправляющих от имени вашего домена. Используйте парсер или сервис отчётов, а не читайте XML глазами.
2. Почините каждого легитимного отправителя, который не проходит: добавьте в SPF, настройте DKIM, убедитесь, что в From стоит ваш домен.
3. p=quarantine — при желании сначала с pct=, чтобы применить политику к части непрошедших писем.
4. p=reject. Поддельные письма отклоняются на входе.

p=none — режим наблюдения, а не защита. Сидеть на нём годами значит собрать данные и так ничего с ними и не сделать.

Домены, которые не отправляют почту

Припаркованные домены, домены только с редиректом и старые названия брендов — любимые цели для подделки, потому что за ними никто не следит. Закройте их полностью:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject"

Нулевая MX-запись (example.net. MX 0 .) дополнительно сообщает другим серверам, что домен не принимает почту.

Как проверить

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com

Первая команда должна вернуть ровно одну строку v=spf1. Для DKIM нужен селектор: откройте отправленное вами письмо, найдите заголовок DKIM-Signature и возьмите значение s=. Заголовок Authentication-Results полученного письма показывает вердикты SPF, DKIM и DMARC в одном месте.

Отчёт SiteScan проверяет DNS-часть за вас: помечает отсутствующую запись SPF, несколько записей SPF, слишком разрешительный +all, отсутствующую запись DMARC и политику DMARC, оставленную на p=none. DKIM он не проверяет — селекторы нельзя обнаружить через DNS, не зная их имён, — поэтому проверьте его на реальном письме.

Чек-лист

1. Ровно одна запись SPF, меньше десяти запросов, окончание ~all или -all.
2. DKIM настроен для каждого сервиса, который отправляет от имени вашего домена.
3. Уведомления сайта идут через провайдера с аутентификацией, From — ваш домен, посетитель — в Reply-To.
4. DMARC есть, отчёты rua приходят, политика движется от p=none к p=reject.
5. У доменов, которые не отправляют почту, стоят v=spf1 -all и p=reject.