Как настроить DMARC: отправители и проверки

Если вы хотите узнать, как настроить DMARC, не начинайте сразу с p=reject. Сначала наблюдайте за отправкой, проверьте успешный SPF или DKIM с выравниванием у каждого штатного отправителя и лишь затем постепенно ужесточайте политику. Это помогает ограничить подделку домена, не создавая лишнего риска для счетов, сброса паролей и писем из забытых SaaS-сервисов.

Реальная инфраструктура редко выглядит просто. Ящики работают в Microsoft 365, счета отправляет стороннее приложение, маркетинг использует другую платформу, а складской копир пересылает сканы. Пропущенный отправитель может превратить строгую политику в сбой. Для общей настройки пригодятся создание почты на своём домене и руководство по деловой почте.

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

Что на самом деле делает DMARC

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

DMARC расшифровывается как Domain-based Message Authentication, Reporting, and Conformance. Он позволяет публиковать политику для не прошедшей проверку почты и запрашивать отчёты. Основная спецификация: RFC 7489. Такая проверка не подтверждает безопасность содержимого или конкретную доставку.

При настройке учитывайте следующие связи:

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

Описанные Google требования к массовым отправителям включают SPF, DKIM и как минимум запись DMARC с p=none. Для соответствующих отправителей также необходимо выравнивание From через SPF или DKIM. Применимые условия уточняйте в ответах Google о требованиях к отправителям.

Что проверить до настройки DMARC

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

Начните с трёх направлений.

SPF: используйте одну подходящую запись для фактического домена конверта. Лимит 10 относится к механизмам и модификаторам, требующим DNS, включая вложенную проверку, а не ко всем DNS-запросам.
DKIM: включите и проверьте его там, где он поддерживается. Используйте ключи 2048 бит, если провайдер поддерживает такую конфигурацию.
Учёт отправителей: перечислите все системы с вашим From, включая почтовую платформу, CRM, бухгалтерию, поддержку, формы, сканеры и маркетинг.

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

Приложение отправляет счета от billing@yourdomain.com, но подписывает доменом поставщика и использует его Return-Path. SPF и DKIM могут пройти для поставщика без выравнивания с вашим From. Если другого успешного выровненного механизма нет, DMARC не проходит.

Именно такие несовпадения объясняют часть проблем, обнаруживаемых при введении ограничений.

Шаг 1: опубликуйте DMARC для наблюдения

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

Создайте TXT под _dmarc.yourdomain.com со следующим значением:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Та же запись в формате файла зоны, а не дополнительная запись:

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Это соответствует принципу примера из RFC 7489. Используйте отдельный обслуживаемый адрес или псевдоним вместо личного ящика. Агрегированные отчёты приходят в XML и могут быстро накапливаться. Проверьте права доступа, а для внешнего адреса при необходимости настройте авторизацию DNS на стороне назначения.

Публикуйте запись у фактического оператора DNS и затем проверяйте остальные механизмы аутентификации. Вопрос «Мои письма попадают в спам» в документации TrekMail помогает разбирать эффекты пересылки и отличать их от проблем, требующих дополнительных тестов.

Шаг 2: изучите отчёты и установите источники отправки

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

В отчётах можно увидеть:

IP-адреса источников, наблюдавшиеся у отправившего отчёт получателя
Результаты аутентификации SPF
Результаты аутентификации DKIM
Результаты выравнивания с From
Обработку, о которой сообщил получатель

Для расследования удобно выделить две группы.

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

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

Отправитель	SPF	DKIM	Выравнивание	Как понимать результат
Правильно настроенный ящик Microsoft 365 или TrekMail	Pass	Pass	Pass	Ожидаемый результат; после изменений проверяйте снова.
Mailchimp или SendGrid без подходящей настройки домена	Pass	Pass	Fail	Аутентификация успешна, но не выровнена с вашим From.
Пересылка с сохранённой корректной подписью DKIM и выравниванием	Fail	Pass	Pass via DKIM	Возможный нормальный результат пересылки.
Неизвестный источник с адресом руководителя и возможной подделкой	Fail	Fail	Fail	Нужна проверка; следующая политика может запрашивать ограничения.

При множестве доменов каждый новый SaaS-сервис добавляет настройку отправки. Единые процедуры помогают управлять этой работой; материал о многодоменном почтовом хостинге рассматривает возможные модели, но не обещает конкретного снижения обращений в поддержку.

Шаг 3: исправьте выравнивание, а не только аутентификацию

Нужен хотя бы один успешный механизм SPF или DKIM с выравниванием. Одного успеха аутентификации мало. В мягком режиме требуется общий организационный домен с видимым From, в строгом режиме домены должны совпадать точно.

RFC 7489 определяет мягкое выравнивание относительно домена RFC5322.From. В ответах Google поясняется, что для DMARC достаточно одного успешного выровненного SPF или DKIM. Настройку обоих механизмов выполняйте с учётом применимых требований.

Типичные исправления:

Для маркетинговых платформ настройте и проверьте подпись DKIM своим доменом.
Для обработки возвратов настройте собственный Return-Path или домен возвратных сообщений, если это поддерживается.
В Microsoft 365 включите и проверьте DKIM для своего домена до ограничений.
Для управляемой отправки TrekMail публикуйте точные записи SPF и DKIM, показанные для фактического пути отправки.

Централизованная панель не отменяет корректную настройку DNS. TrekMail может предоставлять записи и, в зависимости от тарифа, управляемый SMTP либо собственный SMTP в Nano. Работу ящиков и службы исходящей отправки следует проверять отдельно.

В Nano отправка идёт через вашего SMTP-провайдера; соответствующие платные тарифы включают управляемый SMTP. Ценовой ориентир TrekMail начинается от $3.50/месяц, также предлагается 14-дневный пробный период платных тарифов. У Nano есть бесплатный вариант без карты. Текущие функции и условия уточняйте в тарифах TrekMail.

Шаг 4: рассмотрите quarantine как промежуточный этап

После наблюдения и тестов можно рассмотреть quarantine. Это уже запрос ограничений: получатель должен обработать не прошедшие проверку письма как подозрительные. Попадание в конкретную папку спама и возможность последующего восстановления не гарантированы. Особенно важно проверить редкие легитимные отправки.

Когда результаты позволяют, замените прежнюю запись следующей:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Чем quarantine может быть полезен до reject?

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

Длительность зависит от циклов отправки. Пара недель может служить ориентиром; 30 дней тоже лишь пример. Редкие важные письма, включая квартальные, требуют отдельных тестов или более долгого наблюдения.

На этом этапе часто обнаруживаются неучтённые плагины WordPress, тестовые CRM, старые копиры и поставщики с месячной отправкой. Quarantine не заменяет их проверку и не гарантирует буфер без потерь.

Шаг 5: рассмотрите reject после проверки результатов

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

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

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

RFC 7489 описывает запрос отклонения при p=reject и неудачной проверке DMARC. Получатели могут применять локальные исключения; политика не исключает любой обман и не подтверждает безопасность содержания.

Перед переходом проверьте как минимум:

Успешную аутентификацию с выравниванием у основной почтовой службы
Успешную аутентификацию с выравниванием у маркетинговых и транзакционных сервисов
Доступные отчёты за несколько недель и отдельные тесты редких критичных операций
Понятное объяснение оставшихся ошибок

После перехода продолжайте проверять отчёты и реальные письма. Новые сервисы и изменения отправки должны проходить тот же процесс.

Распространённые ошибки, влияющие на почту

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

Вводить ограничения до включения и тестирования DKIM
Создавать несколько SPF вместо одной согласованной записи
Считать SPF pass равнозначным DMARC pass
Забывать поставщиков с небольшим объёмом отправки
Без проверки сразу переходить к p=reject
Направлять отчёты на необслуживаемый адрес

Пересылка может нарушить SPF, а сохранённая корректная подпись DKIM с выравниванием позволяет пройти DMARC. Для этого подписанные данные должны сохраниться с учётом каноникализации. Дополнительные сведения есть в материалах «Пересылка почты через псевдонимы» и «Безопасная деловая почта».

Краткий список настройки DMARC

Этот список описывает поэтапный порядок. Адаптируйте его к реальным отправителям и циклам своего бизнеса.

Перечислите все системы с вашим From.
Настройте одну корректную запись SPF для фактического домена конверта.
Включите и проверьте DKIM на поддерживающих его платформах.
Опубликуйте v=DMARC1; p=none; rua=mailto:....
Сопоставляйте отчёты с известными системами и исследуйте неизвестный трафик.
Обеспечьте успешную аутентификацию с выравниванием для каждого штатного отправителя.
После тестов рассмотрите p=quarantine.
Снова проверьте отчёты и важные письма.
После разбора результатов рассмотрите p=reject.

Итог: контролируемая настройка DMARC

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

Для множества доменов полезны единые инструменты. В зависимости от тарифа TrekMail может предоставлять собственные домены, IMAP-ящики, catch-all, пересылку, миграцию и собственный либо управляемый SMTP. Миграция IMAP копирует сообщения, но не заменяет полноценное переключение MX, приложений и отправки. Фиксированные тарифы также имеют лимиты, а DMARC всё равно нужно настроить правильно.

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