SPF, DKIM и DMARC: как настроить записи для почты домена

Письмо с вашего домена может уйти в спам, даже если в нём нет ничего подозрительного. Почтовые сервисы сначала проверяют, настоящее ли оно: разрешён ли сервер-отправитель (SPF), подписано ли письмо ключом домена (DKIM) и что делать с письмом, если проверки не прошли (DMARC). Все три — обычные TXT-записи в DNS. Разберём, как их настроить и проверить, на живых примерах: letweb.ru и одного рабочего интернет-магазина.

Как проверить SPF, DKIM и DMARC домена

Три команды покажут, что уже настроено:

dig +short letweb.ru TXT                   # SPF
dig +short dkim._domainkey.letweb.ru TXT   # DKIM, «dkim» — селектор
dig +short _dmarc.letweb.ru TXT            # DMARC

В Windows вместо dig — nslookup -type=TXT _dmarc.letweb.ru. Селектор DKIM у каждого сервиса свой: dkim у Timeweb, mail у Яндекс 360, mailru у VK WorkSpace. Его подсказывает панель, где вы настраиваете почту.

Надёжнее всего проверка на реальном письме. Отправьте письмо себе на Gmail или Яндекс, откройте «Показать оригинал» или «Свойства письма» и найдите строку Authentication-Results:

spf=pass  dkim=pass  dmarc=pass

Три pass — всё настроено. fail или none у любой из проверок — повод разбираться дальше. Если все три проходят, а письма всё равно в спаме, причина в репутации: разбираем её в статье почему письма попадают в спам.

SPF-запись: кто может отправлять почту от домена

SPF перечисляет серверы, которым разрешено отправлять письма от имени домена. У letweb.ru почта на Timeweb, поэтому запись короткая:

v=spf1 include:_spf.timeweb.ru ~all

У домена, с которого письма уходят и с хостинга, и через Яндекс 360, запись длиннее. Так выглядит SPF рабочего интернет-магазина: сайт шлёт заказы с хостинга, а менеджеры пишут из Яндекса:

v=spf1 ip4:176.57.223.0/24 ip4:92.53.96.0/22 ... include:_spf.yandex.net ~all

Как читать SPF-запись:

• include: — разрешить все серверы сервиса, их список сервис ведёт сам;
• ip4: и ip6: — разрешить конкретные адреса или сети;
• ~all — остальным «мягкий отказ»: письмо примут, но с подозрением; -all — жёсткий отказ.

Правила, на которых чаще всего ошибаются:

1. SPF-запись у домена одна. Две записи v=spf1 — ошибка, и проверка провалится целиком. Новый сервис дописывают в существующую запись, а не заводят вторую.
2. Не больше 10 обращений к DNS. Каждый include — минимум одно обращение, а внутри него бывают свои. Превысите лимит — SPF перестанет работать.
3. Форма на сайте — тоже отправитель. Если сайт шлёт письма через свой хостинг, хостинг должен быть в SPF.

DKIM: подпись письма

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

dkim._domainkey.letweb.ru.  TXT  "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Сами ключи создавать не нужно: хостинг, Яндекс 360 и VK WorkSpace генерируют их и показывают готовую запись. Ваша задача — скопировать её в DNS целиком, с правильным именем: селектор._domainkey. Главная ошибка — обрезать длинное значение при копировании.

Длина ключа видна по началу значения: MIGfMA0... — это 1024 бита, как у letweb.ru. Если сервис позволяет выбрать, берите 2048 бит — это современный стандарт.

DMARC-запись: что делать с поддельными письмами

SPF и DKIM проверяют письмо, а DMARC говорит получателю, как поступить, если проверки не прошли. Запись лежит на имени _dmarc. До 24 сентября 2026 года её у letweb.ru не было вовсе, и мы добавили самую мягкую:

_dmarc.letweb.ru.  TXT  "v=DMARC1; p=none"

У магазина, который шлёт письма клиентам каждый день, политика строже, и включены отчёты:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.ru; fo=1; adkim=r; aspf=r

Что значат параметры:

• p= — политика: none — только наблюдать, quarantine — класть подозрительное в спам, reject — отклонять;
• rua= — адрес для ежедневных отчётов: кто и сколько писем отправил от вашего домена;
• adkim= и aspf= — строгость совпадения домена в подписи и в SPF: r — мягкая, поддомены считаются своими;
• fo=1 — присылать отчёт о сбое, если провалилась хотя бы одна проверка.

Вводите DMARC постепенно: сначала p=none с rua, пару недель читаете отчёты и убеждаетесь, что все настоящие письма проходят проверки, потом переходите на quarantine, а если всё чисто — на reject. Резкий переход сразу на reject — частая причина, по которой перестают доходить письма с формы сайта или из CRM, о которых все забыли.

Ошибка «rejected per DMARC policy»

Такой отказ приходит, когда получатель отклонил письмо по DMARC-политике домена в поле «От». Две типичные причины:

• Письмо ушло через сервис, которого нет в SPF и который не подписывает DKIM вашим доменом. Например, CRM или сервис рассылок. Добавьте сервис в SPF и настройте DKIM по его инструкции.
• Форма на сайте отправляет письмо «от имени» клиента. Клиент вписал ivan@mail.ru, сайт отправил письмо с таким адресом в поле «От», и его отклонили: у mail.ru политика p=reject, а ваш сервер не имеет права писать от имени mail.ru. Правильно — отправлять с адреса своего домена, а адрес клиента ставить в Reply-To.

Порядок настройки

1. Выпишите всё, что отправляет письма от вашего домена: почтовый сервис, сайт, CRM, сервис рассылок.
2. Соберите одну SPF-запись со всеми отправителями, закончите её ~all.
3. Включите DKIM в каждом сервисе и добавьте их записи в DNS.
4. Добавьте DMARC с p=none и адресом для отчётов.
5. Через пару недель, если отчёты чистые, ужесточите политику до quarantine.

Все записи добавляются там, куда указывают NS-серверы домена, — об этом в статье DNS-записи домена простыми словами. Если почта на домене ещё не заведена, начните со сравнения сервисов: почта на своём домене.