DMARC для домена сайта: как включить защиту и не потерять письма

От имени одного домена письма часто отправляет не только корпоративная почта. К ней добавляются форма заявки на сайте, CRM, сервис рассылок, интернет-магазин, система счетов и служба поддержки. Пока эти каналы не собраны в одну карту, строгая политика DMARC может остановить не подделку, а полезные сообщения: например, уведомления о новых заказах.

DMARC помогает принимающему серверу проверить, связан ли видимый адрес отправителя в поле From с результатом SPF или DKIM, и сообщает предпочтение владельца домена для писем, которые проверку не прошли. Актуальный стандарт RFC 9989 опубликован в мае 2026 года. Он заменил прежние RFC 7489 и RFC 9091, поэтому при настройке важно учитывать не только старые инструкции из поиска.

Сначала разберитесь, что именно проверяет DMARC

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

DMARC считается пройденным, когда согласованную проверку проходит хотя бы один механизм — SPF или DKIM. Это важно для сайта: внешний SMTP-сервис может успешно пройти собственную проверку, но использовать другой домен, не связанный с видимым отправителем. В отчёте такой поток окажется проблемным.

Шаг 1. Соберите карту всех отправителей

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

почтовые ящики сотрудников и общие адреса;
формы обратной связи, заказа, регистрации и восстановления пароля;
CRM, helpdesk и сервисы телефонии;
рассылки, уведомления интернет-магазина и платёжные сообщения;
счета, акты, мониторинг и другие автоматические системы;
старые подрядчики и сервисы, которыми компания уже не пользуется.

Для каждого источника запишите провайдера, домен в видимом From, технический адрес возврата, наличие DKIM, ответственного и контрольное письмо. Карта должна отвечать на простой вопрос: кто имеет право говорить от имени домена и зачем.

Шаг 2. Проверьте SPF и DKIM у каждого рабочего канала

Официальная инструкция Google рекомендует настроить SPF и DKIM до DMARC и дать изменениям DNS время распространиться. Яндекс 360 также предлагает опубликовать DKIM и SPF после настройки доменной почты и предупреждает, что DNS обновляется не мгновенно.

Отправьте контрольные письма из каждого найденного источника на внешний ящик и изучите технические заголовки. Проверьте не только результат pass, но и домен, для которого он получен. Если форма сайта отправляет через хостинговую функцию почты, лучше подключить управляемый SMTP-канал и корректно подписывать сообщения, чем маскировать проблему мягкой политикой DMARC.

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

Шаг 3. Включите DMARC в режиме наблюдения

Запись DMARC размещают в DNS для имени вида _dmarc.example.ru. Для первого этапа политика обычно выглядит как v=DMARC1; p=none; rua=mailto:dmarc@example.ru. Это только пример структуры: адрес для отчётов должен существовать и быть готов принимать XML-файлы.

Политика p=none нужна для наблюдения. RFC 9989 указывает, что она не должна менять существующую обработку писем. Принимающие серверы могут присылать агрегированные отчёты на адрес из rua: в них видны источники отправки, объём сообщений и результаты SPF, DKIM и согласования доменов.

Для отчётов удобно завести отдельный ящик или использовать сервис, который превращает XML в понятную таблицу. Само получение файла ещё ничего не исправляет: нужно сопоставить каждый источник с составленной картой.

Шаг 4. Разберите отчёты и устраните законные ошибки

Разделите источники на три группы. Первая — известные и правильно настроенные. Вторая — известные, но не проходящие согласование. Третья — неизвестные: это может быть забытая интеграция, пересылка или попытка подделки.

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

Шаг 5. Переходите к строгой политике только после проверки

Политика p=quarantine предлагает помещать не прошедшие проверку письма в спам или обрабатывать их с повышенной осторожностью. p=reject предлагает отклонять такие сообщения. Переход оправдан, когда все рабочие источники найдены, исправлены и стабильно проходят DMARC.

Оставьте время на обычный цикл бизнеса: ежедневные заявки можно увидеть быстро, а ежемесячные счета или редкие сообщения службы поддержки — только через несколько недель. Отдельно учитывайте пересылки и почтовые рассылки: косвенная доставка способна менять письмо и создавать сложные исключения. RFC 9989 прямо предупреждает о рисках совместимости при строгой политике.

Что DMARC не решает

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

Поэтому настройку почты нужно сочетать с защитой CMS, учётных записей и форм. Если есть подозрение на вредоносный код или компрометацию, проверка безопасности сайта VOWE включает аудит CMS, плагинов и модулей, прав доступа, форм, хостинга и подозрительных изменений. Это отдельный контур защиты, который DMARC не заменяет.

Чек-лист безопасного внедрения DMARC

Перечислены корпоративная почта, сайт, CRM, рассылки и все автоматические отправители.
Для каждого источника известны видимый From, технический домен и ответственный.
SPF и DKIM проверены на реальных контрольных письмах.
Проверено согласование домена SPF или DKIM с доменом в From.
Создан отдельный рабочий адрес для агрегированных отчётов.
DMARC сначала включён с политикой p=none.
Источники из отчётов сопоставлены с картой отправителей.
Неизвестные серверы исследованы, а не добавлены в разрешённые автоматически.
Редкие сценарии отправки проверены до ужесточения политики.
После перехода на quarantine или reject отслеживаются доставка заявок и отчёты.
Изменения DNS, дата проверки и ответственный записаны в рабочий регламент.

Вопросы о настройке DMARC

Можно ли сразу установить p=reject?

Технически можно, но без карты отправителей это риск для рабочих писем. Безопаснее сначала проверить SPF и DKIM, включить p=none, разобрать отчёты и только после исправления легитимных потоков переходить к строгой политике.

Защитит ли DMARC письма из формы сайта?

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

Заменяет ли DMARC проверку безопасности сайта?

Нет. DMARC снижает риск подделки домена в почте, но не ищет вредоносный код и уязвимости CMS. VOWE отдельно проверяет CMS, компоненты, доступы, формы, хостинг и подозрительные изменения на сайте.