DMARC p=none, quarantine или reject: руководство для администраторов

Главный компромисс

Выбирая политику DMARC, вы выбираете между наблюдаемостью и применением. p=none даёт мониторинг, не влияя на доставку. p=quarantine отправляет подозрительные письма в «Спам». p=reject полностью блокирует неаутентифицированную почту. Самый безопасный путь — поэтапное внедрение: начните с none, чтобы выявить всех легитимных отправителей, перейдите на quarantine, чтобы оценить последствия, и в итоге дойдите до reject, чтобы полностью защитить домен от подделки.

Почему политика важна для очереди инцидентов

Если вы инженер, отвечающий за доставляемость, ваша главная задача — чтобы легитимные транзакционные письма доходили до получателя, а злоумышленники не могли использовать ваш домен. Если сразу перейти на p=reject без этапа мониторинга, вы, скорее всего, получите инцидент высокого приоритета, когда забытая legacy-система или сторонний маркетинговый инструмент внезапно перестанет доставлять письма.

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

Три уровня политики

1. p=none (режим мониторинга)

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

Когда использовать:

• При первоначальной настройке DMARC.
• Когда вы не уверены, что знаете все сервисы, отправляющие почту от вашего имени.
• Во время миграции на новый email API.

Запись:

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

Компромисс: защиты от подделки нет совсем. Злоумышленники по-прежнему могут отправлять письма от имени вашего домена, но вы увидите это в агрегированных отчётах (RUA).

2. p=quarantine (мягкое применение)

Письма, не прошедшие DMARC, считаются подозрительными. Большинство получателей переместят их в папку «Спам» или «Нежелательная почта».

Когда использовать:

• После того как вы проанализировали отчёты в режиме p=none и убедились, что все легитимные потоки выровнены.
• Как страховочный этап перед полным отклонением.

Запись:

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

Компромисс: поддельные письма становятся менее заметны, но не исчезают полностью. Часть легитимной почты всё ещё может попадать в «Спам», если ключи DKIM ротируются неправильно или SPF-запись упирается в лимит в 10 DNS-запросов.

3. p=reject (полное применение)

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

Когда использовать:

• Когда мониторинг показывает выравнивание 99,9% для всего легитимного трафика.
• Когда риск подделки домена перевешивает риск редких сбоев доставки.

Запись:

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

Компромисс: страховки нет. Если критичная система настроена неправильно, письмо потеряно. Вы увидите эти сбои в отчётах RUA, но пользователь письмо так и не получит.

Чек-лист внедрения для эксплуатации

Не меняйте политику по ощущениям. Меняйте её на основе данных из агрегированных отчётов. Перед каждым переходом проверяйте, что записи корректно распространились, с помощью инструмента вроде SendHQ Email DNS Checker.

Этап 1: обнаружение (p=none)

1. Опубликуйте p=none с адресом rua.
2. Подождите 7–14 дней, чтобы охватить полный деловой цикл писем (включая еженедельные отчёты).
3. Проанализируйте отчёты на предмет «невыровненного» трафика.
4. Выявите легитимных сторонних отправителей (например, Zendesk, Salesforce, Shopify).
5. Настройте DKIM для каждого выявленного отправителя. Это самый надёжный способ обеспечить выравнивание.

Этап 2: тестирование (p=quarantine)

1. Измените политику на p=quarantine.
2. Следите за обращениями в поддержку вроде «Мне не пришло письмо» или «Письмо попало в спам».
3. Проверяйте отчёты RUA на новые всплески сбоев.
4. Если сбои появились, исправьте аутентификацию и оставайтесь на quarantine ещё неделю.

Этап 3: ужесточение (p=reject)

1. Измените политику на p=reject.
2. Убедитесь, что самые критичные транзакционные потоки (сброс пароля, счета) по-прежнему доставляются.
3. Продолжайте мониторинг. DMARC — не та настройка, которую можно «настроить и забыть».

Письмо как побочный эффект

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

Идемпотентность и согласование

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

Кроме того, у агентов не должно быть права самостоятельно отправлять важные письма. Сделайте очередь согласования для контента, созданного агентом, чтобы адрес «From» и содержание соответствовали вашему бренду и политикам аутентификации.

Сколько стоит инфраструктура доставки

Выбор провайдера отправки влияет на то, как вы управляете DMARC. У одних провайдеров настройка DKIM тривиальна, у других приходится вручную добавлять DNS-записи для каждого поддомена.

Оценивая затраты, смотрите на совокупную стоимость владения. Например, отправка 50 000 писем стоит примерно 5 USD в Amazon SES с оплатой по факту (0.10 USD за 1 000 писем), тогда как на тарифах Postmark тот же объём обойдётся примерно в 66 USD (15 USD за 10 000 плюс превышение от 1.20 до 1.80 USD за 1 000).

Среди других вариантов — Resend с бесплатным тарифом на 3 000 писем в месяц (не более 100 в день) и Mailgun от 15 USD в месяц за 10 000 писем. SendGrid теперь вместо бесплатного тарифа предлагает 60-дневный пробный период, а тариф Essentials стоит от 19.95 USD в месяц.

Независимо от провайдера, политика DMARC остаётся главным щитом вашего домена. Если провайдер поддерживает только SPF, при переходе на p=reject риск сбоев доставки выше, потому что SPF ломается при пересылке писем. Только DKIM сохраняет выравнивание при пересылке.

Типичные сценарии сбоев

Ловушка пересылки

Пользователь A отправляет письмо пользователю B. У пользователя B настроена автопересылка пользователю C. Пересылающий сервер часто меняет отправителя в конверте на свой домен, чтобы письмо не пометили как спам. Это ломает выравнивание SPF. Если у вас p=reject и нет подписи DKIM, пользователь C никогда не увидит письмо.

Лимит DNS-запросов

SPF-записи ограничены 10 DNS-запросами. Если добавить в SPF-запись слишком много провайдеров, получатель вернёт permerror. Это приводит к сбою DMARC. Чтобы решить проблему, выберите провайдера, который делает ставку на аутентификацию через DKIM, или используйте SPF flattening.

Проблема «теневого ИТ»

Маркетинговые команды часто подключают новые инструменты (например, новый сервис рассылок), не предупреждая разработку. Они отправляют письма с вашего домена, письма не проходят DMARC и отклоняются. Поэтому этап p=none обязателен.

Сводная таблица для эксплуатации

Политика | Действие | Риск | Наблюдаемость | Рекомендуемое применение

p=none | Нет | Низкий | Высокая | Обнаружение и аудит

p=quarantine | Папка «Спам» | Средний | Высокая | Тестирование и переход

p=reject | Блокировка | Высокий | Средняя | Полная защита в продакшене

Подробнее о технической настройке этих записей читайте в нашем руководстве по DKIM, SPF и DMARC.

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

Подробнее — на https://sendhq.cc.