Политика DMARC: выбор none, quarantine или reject

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

Ошибки часто связаны не со сложностью протокола, а с пропущенной проверкой. Запись оставляют на p=none без анализа результатов. Или сразу включают p=reject, не проверив успешную аутентификацию и выравнивание всех законных отправителей. Это может привести к отказу в приёме нужной почты.

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

Что такое политика DMARC?

Политика DMARC задаёт рекомендуемую обработку писем с вашим доменом в From, не прошедших DMARC. Варианты: none, quarantine и reject. Выбор зависит от того, проходит ли каждый законный отправитель SPF или DKIM с выравниванием доменов.

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

Если SPF успешен и его домен выровнен, DMARC проходит.

Если DKIM успешен и его домен выровнен, DMARC проходит.

Если нет успешного выровненного пути, получатель учитывает политику DMARC.

С какой политики DMARC начать?

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

Возможная начальная запись:

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

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

Часто забывают про:

1. Бухгалтерскую программу, отправляющую счета.
2. Кадровые и рекрутинговые системы с предложениями о работе.
3. CRM и маркетинговые платформы с рассылками.
4. Систему поддержки, отвечающую с основного домена.
5. Индивидуальные правила пересылки, нарушающие SPF на следующем узле.

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

Для массовых отправителей запись DMARC уже входит в важные требования к отправке. Рекомендации Google рассматривают аутентификацию домена и выравнивание. Описываемый здесь протокол изложен в RFC 7489.

Как долго оставлять политику DMARC на none?

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

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

Учитывайте:

1. Обычную деловую переписку.
2. Маркетинговые рассылки.
3. Расчётные циклы.
4. Эскалации поддержки.
5. Пересылаемые письма.
6. Автоматизации сторонних сервисов.

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

Пример: платформа рассылок подписывает своей доменной подписью, а SPF проходит только для её невыровненного домена. Успешного выровненного пути нет, поэтому DMARC не проходит. Сначала исправьте выравнивание, а не включайте reject.

В TrekMail процесс настройки DNS показывает нужные записи и помогает их проверить. Он не заменяет полный список всех отправителей. См. добавление домена и обязательные записи DNS.

Почему пересылка может нарушить DMARC?

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

Это различие важно и для опытных администраторов.

У письма несколько идентификаторов отправителя. Пользователь видит From, а адрес в конверте используется для возвратов. SPF проверяет соответствующий домен и IP отправки. DMARC дополнительно проверяет выравнивание этого аутентифицированного домена с видимым From.

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

Поэтому возможны оба результата:

1. SPF не проходит после пересылки.
2. DMARC проходит благодаря успешному выровненному DKIM.

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

ARC передаёт контекст аутентификации через посредников и списки рассылки. Он не заменяет собственное выравнивание; как учитывать эти сведения, решает получатель. Протокол описан в RFC 8617.

Когда переходить на quarantine?

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

Возможная запись:

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

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

Возможный порядок действий:

1. Пользователь сообщает о пропавшем письме.
2. Вы проверяете отправителя, аутентификацию и выравнивание.
3. Исправляете SPF, DKIM или оба.
4. Повторно тестируете до рассмотрения reject.

Некоторые команды вводят ограничения через pct=25 или pct=50. Поддержка и применение зависят от получателя: точное соблюдение доли не гарантировано. Переход на 100% тоже требует достаточной предварительной проверки.

Корректно настроенный управляемый SMTP TrekMail может подписывать письма вашим доменом. Подтвердите это реальными заголовками и выравниванием. Ожидаемый случай ошибки SPF при успешном DKIM после пересылки разбирает «Мои письма попадают в спам».

Когда переходить на reject?

Рассматривайте reject после проверки законных источников и анализа оставшихся ошибок. Reject запрашивает отказ для писем, не прошедших DMARC, но не гарантирует одинаковое действие всех получателей.

Возможная запись:

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

Для многих доменов это подходящая цель после подготовки.

Возможные преимущества:

1. Может ограничить прямую подделку защищённого домена.
2. Может осложнить отдельные виды фишинга и злоупотребления адресом отправителя.
3. Явно сообщает желаемую обработку неудачной аутентификации.
4. Может быть частью более широкой защиты бренда.

Google описывает отказы и ограничения в справке отправителя, включая связанные с DMARC ошибки 4.7.31 и проблемы выравнивания 4.7.32. Возвраты также могут содержать 5.7.26 и упоминание политики домена. Проверяйте полный текст ошибки по ответам Google на вопросы о требованиях к отправителям.

Внимание: старая бухгалтерская SaaS-система без успешного выровненного пути может столкнуться с отказом. Заранее проверьте её письма и предусмотрите действия при проблемах.

Какую запись политики DMARC публиковать в DNS?

Политика публикуется как TXT под _dmarc.yourdomain.com. Размещайте там только одну запись политики DMARC: конфликтующие записи могут помешать обработке.

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

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Настройка DNS в TrekMail обычно рассматривает MX, SPF, DKIM и DMARC вместе. Следующий образец лишь иллюстрирует структуру: quarantine не является универсальным начальным выбором, а SPF и DKIM должны соответствовать фактическому отправителю.

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

Не создавайте дубликаты SPF и не придумывайте значения DKIM. Проверьте необходимость старых MX. При собственном провайдере исходящей почты используйте его требования к SPF и DKIM и отдельно проверяйте выравнивание. См. собственный SMTP (BYO).

Распространённые ошибки политики DMARC

Типичные проблемы: оставленное без анализа p=none, слишком раннее ужесточение, зависимость только от SPF и забытые поддомены. Последствия зависят от реальной почтовой конфигурации.

Обратите внимание:

1. none без анализа и дальнейшего плана. Отчёты сами по себе не вводят ограничения DMARC.
2. Отсутствие выравнивания DKIM при положительном SPF. Пересылка может выявить такую зависимость.
3. Наследование поддоменами. sp= позволяет задать им другую политику.
4. Ограничение SPF: более 10 проверяемых механизмов и модификаторов, требующих DNS, может дать PermError. Это не просто общее число DNS-запросов.
5. Отправка вашим доменом без проверки реальной подписи.

Пример другой обработки поддоменов:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

Основной домен запрашивает reject, а наследующие поддомены получают none. Это относится не только к одному выбранному поддомену; собственная конкретная запись DMARC может переопределить наследуемую политику.

Как TrekMail помогает с настройкой DMARC

TrekMail объединяет управление доменами, проверки DNS и отправку в панели нескольких доменов с общим хранилищем. Это может сократить административную разрозненность, но не заменяет проверку сторонних отправителей и полноценное наблюдение DMARC.

В качестве ценового ориентира TrekMail указывает Starter от $3.50/месяц с управляемым SMTP; Nano предлагается бесплатно с собственным SMTP. Ящики IMAP, собственные домены, catch-all, пересылка, миграция и API зависят от актуального тарифа и условий. Перед выбором уточните цены и функции.

Для DMARC особенно важно знать все системы, отправляющие вашим доменом. Публикация TXT сама по себе этого не решает.

В зависимости от тарифа и настройки можно:

1. Управлять несколькими доменами из одной панели.
2. Проверять нужные DNS-записи до запуска.
3. Использовать управляемый SMTP в соответствующих платных тарифах или собственный SES/SendGrid на Nano.
4. Отделять размещение ящиков от выбора исходящего провайдера.
5. Импортировать старую почту встроенной миграцией IMAP, если исходный сервис позволяет доступ.

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

Итог: ужесточайте DMARC постепенно

Практичный путь начинается с none, успешной аутентификации и выравнивания, затем после проверки ведёт к quarantine и при необходимости к reject. Для каждого этапа нужны данные реального трафика.

Краткий порядок:

1. Наблюдайте с p=none, например, от 2 до 4 недель, отдельно учитывая редкие циклы.
2. Обеспечьте каждому законному отправителю успешный выровненный SPF или, предпочтительно, DKIM.
3. После проверки переходите на p=quarantine.
4. Включайте p=reject, когда оставшиеся ошибки исследованы и законные источники проверены.

Так можно ограничить риск для нужной почты и запросить более строгую обработку подделки домена, при этом решение о приёме и фильтрации остаётся за получателем. Для общего управления ящиками, пересылкой и миграцией изучите документацию TrekMail или сравните тарифы на https://trekmail.net/pricing.