Как создать запись DMARC: DNS, теги и проверка отправки

Желание создать запись DMARC часто возникает после поддельных писем, предупреждений Gmail или просьбы провайдера изменить DNS. Поводом могут стать и неодинаковые результаты SPF и DKIM. Если инфраструктура ещё строится, начните с руководства по деловой почте, чтобы согласовать домен, ящики и DNS.

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

Ниже разобраны основные теги, публикация под _dmarc.yourdomain.com и проверенный переход от наблюдения к запросу ограничений.

Что содержит запись DMARC

Опубликуйте TXT под _dmarc.yourdomain.com, начиная с v=DMARC1 и добавив корректную политику, например p=none, p=quarantine или p=reject. DMARC сообщает желаемую обработку, когда ни SPF, ни DKIM не обеспечивают одновременно успешную проверку и выравнивание с From.

Минимальный корректный пример:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

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

Пример с агрегированными отчётами:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

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

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Согласно RFC 7489, тег v должен быть первым, а p обязателен. Некорректная запись может помешать обработке политики. Подробности протокола изложены в RFC 7489.

Где публиковать DMARC в DNS

Запись размещается не в корне, а под именем _dmarc. Для example.com запрашивается _dmarc.example.com. Другой адрес публикации не предоставит нужную политику при этом поиске.

Частые ошибки: значение под @ или полное имя _dmarc.example.com в панели, ожидающей только _dmarc. Требования к короткому или полному имени зависят от DNS-провайдера.

Проверяйте опубликованную запись вне панели управления:

dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.com

Нужна одна корректная запись политики DMARC, начинающаяся с v=DMARC1. Несколько строк внутри одной TXT-записи не равнозначны нескольким политикам. Другие TXT-значения тоже нужно отличать от DMARC.

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

Основные теги записи DMARC

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

Корректная запись с p=none без rua не запрашивает агрегированные отчёты. Другие журналы могут давать сведения об отправке, но не заменяют автоматически эту обратную связь.

Как выбрать политику

При непроверенных путях отправки можно начать с p=none. После анализа отчётов, сверки отправителей и тестов рассмотрите p=quarantine. К p=reject переходите после проверки критичных и редких легитимных источников. Неизвестный IP сам по себе не доказывает несанкционированную отправку.

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

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

Пошаговое создание записи DMARC

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

1. Перечислите все сервисы: Google Workspace, Microsoft 365, поддержку, CRM, формы, счета и рассылки.
2. Проверьте SPF и DKIM фактических систем отправки. DMARC их не заменяет. Ограничение SPF учитывает механизмы и модификаторы, требующие DNS, включая вложенную проверку, а не все запросы.
3. Создайте обслуживаемый адрес, например dmarc@yourdomain.com, или используйте службу отчётов. Проверьте приватность и необходимую авторизацию DNS внешнего назначения.
4. Начните с p=none, если отправка ещё не полностью проверена.
5. Сопоставляйте доступные отчёты с перечнем систем, журналами и тестами.
6. Выровняйте успешную аутентификацию с доменом From.
7. После проверки рассмотрите p=quarantine.
8. После разбора ошибок и редких операций рассмотрите p=reject.

Возможный пример наблюдения для 2026 года, требующий адаптации к вашей инфраструктуре:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Если используется пересылка, прочитайте руководство по пересылке доменной почты в Gmail. SPF может не пройти на новом сервере. Корректная подпись DKIM с выравниванием позволяет пройти DMARC, если подписанные данные сохранены с учётом каноникализации. ARC может повлиять на локальное исключение получателя, но не превращает DMARC fail в успешную проверку.

Частые ошибки создания записи

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

Особенно часто встречаются такие ошибки:

1. Публикация в корне вместо _dmarc.
Запись под @ расположена не по нужному адресу поиска.

2. Несколько записей политики DMARC.
RFC 7489 описывает прекращение обработки при нескольких записях политики. Это не то же самое, что несколько строк внутри одной TXT-записи.

3. Немедленное включение p=reject.
Забытый сервис может потерять письма сброса пароля, счета или ответы поддержки, если получатель применяет отказ.

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

5. Ожидание, что DMARC исправит пересылку.
Нужен успешный SPF или DKIM с выравниванием. При пересылке SPF может не пройти, а DKIM помогает только при сохранённой корректной и выровненной подписи.

Подтверждения заказов, поддержка и маркетинг используют разные SMTP-сервисы. Вы вводите p=reject до проверки всех систем. Часть писем проходит, другие могут отклоняться. Недостающая проверка отправки становится проблемой клиентов.

Общий процесс разобран в создании почты со своим доменом, включая DNS, ящики, SPF, DKIM и DMARC.

Управление DMARC для многих доменов

Таблицы, разные панели регистраторов и старые TXT-значения затрудняют единообразную настройку. Общая панель и проверяемые записи могут помочь, но должны учитывать фактического оператора DNS и пути отправки.

TrekMail может объединять несколько доменов, общее хранилище, IMAP-ящики, миграцию, catch-all, пересылку и собственный либо управляемый SMTP в зависимости от тарифа. У Nano есть бесплатный вариант до 10 доменов с собственным SMTP. Ориентир платных тарифов составляет от $3.50/месяц. Текущие условия приведены в тарифах TrekMail.

Общая панель может уменьшить переключения между пятью поставщиками и двадцатью вкладками. Она не заменяет проверку всех писем и план смены MX или приложений; импорт IMAP копирует существующую почту.

Последняя проверка перед ограничениями

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

Краткая итоговая проверка:

1. Опубликуйте одну корректную запись политики DMARC.
2. Используйте подходящее имя _dmarc.
3. Начните значение с v=DMARC1; p=....
4. Направьте rua на доступное обслуживаемое назначение.
5. Используйте одну корректную запись SPF для фактического домена конверта.
6. Включите DKIM у поддерживающих его отправителей и проверьте выравнивание.
7. Подтвердите ожидаемый результат внешним DNS-запросом.
8. Начните с none, если важные пути отправки ещё не проверены.

После внедрения DMARC всё равно требует обслуживания. TrekMail может объединять управление доменами, IMAP-ящиками, DNS, SMTP и миграцией в зависимости от тарифа. Информация есть на trekmail.net; изменения нужно продолжать проверять реальными письмами.