DMARC для B2B-отправителя: полный гид по настройке для адресного аутрича

Домен без настроенного DMARC технически уязвим для подделки от своего имени, а его письма стартуют с пониженным доверием у корпоративных почтовых систем — и это касается любого домена, с которого идёт адресный B2B-аутрич, не только крупных компаний. Разбираем, как прописать DMARC поэтапно, не сломав доставляемость письмами, которые действительно нужно отправить.

Что такое DMARC и зачем он поверх SPF и DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это DNS-запись, которая говорит принимающим почтовым серверам, что делать с письмом, если оно не прошло проверки SPF или DKIM, и куда присылать отчёты о таких случаях. Сам по себе DMARC не проверяет содержание письма — он опирается на результаты уже существующих механизмов SPF и DKIM.

SPF (Sender Policy Framework) перечисляет, какие серверы имеют право отправлять почту от имени домена. DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к письму, подтверждающую, что оно не изменено в пути и действительно отправлено владельцем приватного ключа домена. DMARC связывает эти две проверки с доменом в поле From и задаёт политику реакции на несовпадение — это и есть последний уровень аутентификации отправителя перед принимающим сервером.

Важный нюанс: DMARC требует совпадения (alignment) домена в поле From с доменом, прошедшим SPF или DKIM — не просто факта прохождения проверки, а именно её привязки к тому же домену, который видит получатель в письме. Из-за этого технического требования настройка стороннего сервиса рассылки без учёта alignment иногда проходит SPF, но всё равно не проходит DMARC — это частая причина путаницы при диагностике.

Зачем DMARC нужен именно адресному B2B-отправителю

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

Отдельно DMARC (вместе с SPF/DKIM) всё активнее становится требованием крупных почтовых провайдеров: без выстроенной аутентификации письма от домена по умолчанию получают меньше доверия, что напрямую снижает доставляемость даже полностью легитимного адресного аутрича по юрлицам.

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

Шаг 1: настроить SPF и DKIM перед DMARC

DMARC без SPF и DKIM не имеет смысла — ему не на что опираться. SPF настраивается TXT-записью в DNS домена, перечисляющей разрешённые IP-адреса или включающей записи провайдера (например, include:_spf.google.com для Google Workspace). Важно не плодить несколько SPF-записей на один домен — допускается только одна, с объединением всех источников через include.

DKIM настраивается через почтового провайдера или сервер отправки: генерируется пара ключей, приватный остаётся на сервере отправки для подписи писем, публичный публикуется в DNS как TXT-запись на специальном селекторе (например, selector1._domainkey.company.ru). После настройки обоих механизмов стоит отправить тестовое письмо и проверить заголовки Authentication-Results на предмет pass по обоим пунктам, прежде чем переходить к DMARC.

Шаг 2: первая DMARC-запись с политикой p=none

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

Шаг 3: читать отчёты rua и находить проблемы

Отчёты rua (aggregate reports) приходят от крупных почтовых провайдеров (Google, Microsoft, Яндекс и других) обычно раз в сутки в формате XML и показывают по каждому IP, который отправлял почту от имени вашего домена: прошёл ли он SPF и DKIM, и сколько писем было отправлено. Читать сырой XML неудобно — обычно используют бесплатные или платные сервисы-парсеры, которые превращают отчёты в читаемую таблицу.

На этом этапе важно найти все легитимные источники отправки: не только основной почтовый сервер, но и, например, CRM-систему, сервис для рассылок, транзакционные уведомления с сайта — если какой-то из них не проходит SPF или DKIM, его нужно добавить в SPF-запись или настроить для него DKIM-подпись, прежде чем ужесточать DMARC-политику.

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

• Проверить каждый IP-источник в отчёте на легитимность — свой это сервис или посторонний
• Убедиться, что все легитимные сервисы (CRM, релей для рассылок, сайт) проходят SPF и/или DKIM
• Оценить долю писем с провалом проверки — если она заметная, разбираться в причине до ужесточения политики
• Держать мониторинг на p=none не меньше двух-четырёх недель, чтобы охватить разные типы отправки

Шаг 4: переход на quarantine и затем reject

Когда отчёты подтвердили, что вся легитимная почта проходит проверки, можно переходить к политике p=quarantine — письма, не прошедшие SPF/DKIM, будут помечаться как подозрительные и, вероятнее всего, попадать в спам у получателя, но не отклоняться полностью. Это промежуточный этап, дающий шанс заметить и исправить упущенный источник до окончательного ужесточения.

Финальный шаг — p=reject, при котором непрошедшие проверку письма отклоняются принимающим сервером полностью. Переходить к нему стоит только после уверенности, что все легитимные источники учтены, и желательно постепенно — через параметр pct, увеличивая долю писем, к которым применяется строгая политика, с 25% до 100%, а не одним шагом для всего трафика домена.

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

Самая частая ошибка — сразу ставить p=reject или p=quarantine, не пройдя этап мониторинга. Это приводит к тому, что легитимные письма (например, от CRM или сервиса рассылок, который забыли включить в SPF) начинают отклоняться или падать в спам без предупреждения, и причину сложно диагностировать без анализа отчётов задним числом.

Вторая — настроить DMARC и никогда не читать rua-отчёты. DMARC без регулярного просмотра отчётов — это включённый мониторинг, данные которого никто не смотрит: проблемы накапливаются незаметно, а домен продолжает быть уязвим для спуфинга даже с формально настроенной записью.

Третья — несколько противоречащих друг другу DMARC или SPF записей на одном домене, что почтовые системы интерпретируют непредсказуемо или вовсе игнорируют всю аутентификацию для этого домена.

Вопросы и ответы