DMARC policy: quarantine vs reject — что выбрать в 2026

Выбор DMARC policy — место, где большинство команд вводит deliverability damage, которое они не intended. Неправильный выбор — обычно прыжок в reject слишком рано — производит immediate placement collapse на legitimate mail. Правильный выбор — staged migration с none к quarantine к (опционально) reject — производит градуальное tightening с feedback на каждом шаге. Эта статья — что DMARC policy означают operationally в 2026, когда каждый policy уместен и migration path, не ломающий доставляемость по пути. Пара к гайду по SPF setup, гайду по DKIM setup и обзору SPF/DKIM/DMARC.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) связывает SPF и DKIM вместе с alignment-проверкой и policy-statement. Policy говорит receiving-серверам, что делать, когда authentication проваливается: ничего (none), отправить в спам (quarantine) или reject outright (reject). Выбор имеет material consequences для доставляемости и репутации, и большинство команд не должно начинать с reject.

Что DMARC реально делает

DMARC-запись — TXT-запись на _dmarc.<yourdomain>. Пример:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; pct=100; adkim=r; aspf=r

Куски:

• v=DMARC1 — версия
• p=none|quarantine|reject — policy (что receiving-серверы делают с failing mail)
• rua=mailto:... — куда слать aggregate-отчёты
• pct=100 — какой процент failing mail policy применяется к (полезно для staged rollouts)
• adkim=r|s — DKIM alignment mode (relaxed или strict)
• aspf=r|s — SPF alignment mode (relaxed или strict)

DMARC проверяет две вещи, когда mail приходит:

1. Authentication: Проходит ли SPF ИЛИ DKIM?
2. Alignment: Матчит ли SPF или DKIM домен From-address домен?

Если оба проходят, DMARC проходит. Если оба проваливаются, DMARC проваливается — и policy говорит receiving-серверу, что делать.

Три policy-режима

p=none (monitoring mode). Receiving-серверы репортят на authentication-результатах, но не меняют mail handling. Это starting point для каждой команды. Производит aggregate-отчёты (отправленные на rua адрес), показывающие, какие sending-источники проходят или проваливают authentication. Отчёты — feedback-механизм, позволяющий фиксить authentication issues до tightening policy.

Duration в none: минимум 2–4 недели, дольше, если sending-стек сложный. Цель — подтвердить, что 100% legitimate mail проходит SPF или DKIM с proper alignment до перехода дальше.

p=quarantine. Receiving-серверы шлют failing mail в спам/junk. Получатель всё ещё может найти, но не увидит в inbox. Это safe middle ground — провалы visibly demoted, но не lost. Используйте, как только monitoring-данные показывают, что authentication консистентный.

Распространённый rollout: старт на p=quarantine; pct=10 (10% failing mail карантинится), gradually raise pct до 100 за 2–4 недели. Механизм pct позволяет тестировать impact на малом subset до full rollout.

p=reject. Receiving-серверы отклоняют failing mail outright. Отправитель получает bounce; получатель никогда не видит. Это самый strict policy и производит сильнейший anti-spoofing сигнал — но любая authentication-проблема приводит к legitimate mail loss. Используйте только когда authentication верифицирован working на 100% через каждый sending-источник.

Большинство B2B-команд в 2026 оперирует на p=quarantine, а не на p=reject. Enterprise security-команды и high-target brands (банки, government, large platforms) обычно двигаются к p=reject, потому что spoofing-риск оправдывает operational rigor.

Migration path

Safe DMARC миграция выглядит так:

Phase 1: SPF и DKIM верифицированы working (week 0). До добавления DMARC подтвердите, что SPF и DKIM оба проходят для исходящего mail с каждого sending-сервиса. Используйте header inspection на test sends, чтобы верифицировать dkim=pass и spf=pass результаты.

Phase 2: Добавьте DMARC на p=none (week 1). Опубликуйте DMARC-запись с p=none и rua адресом, который может получать XML-отчёты. Большинство команд используют сторонний сервис (Postmark’s DMARC monitoring, dmarcian, EasyDMARC, Valimail) для парсинга отчётов — manual reading XML aggregate-отчётов не scale’ится.

Phase 3: Monitor 2–4 недели (weeks 2–5). Review DMARC-отчёты. Отчёты показывают:

• Какие sending-источники производили mail, claiming быть с вашего домена
• Прошли ли SPF и DKIM для каждого источника
• Держался ли alignment

Фиксите любые authentication failures (обычно: sending-сервис, не включённый в SPF, или сервис, signing с DKIM, но не aligning к вашему домену).

Phase 4: Двиньтесь на p=quarantine; pct=10 (week 6). Как только отчёты показывают консистентный authentication, начинайте tightening. pct=10 означает 10% failing mail карантинится — low-risk, потому что большинство legitimate mail теперь проходит authentication, и 10% sampling показывает, проваливается ли что-то.

Phase 5: Raise pct gradually (weeks 7–9). Двигайтесь к pct=25, потом pct=50, потом pct=100 за 2–3 недели. На каждом шаге мониторьте отчёты для любого legitimate sending-источника, проваливающегося.

Phase 6 (опционально): Двиньтесь на p=reject; pct=10 и ramp. Если ваша security posture требует (финансовые services, government, brand-protection-critical секторы), повторите pct-ramp для p=reject. Для большинства B2B cold email senders p=quarantine; pct=100 — appropriate stopping point.

Вся миграция занимает 6–12 недель, сделанная правильно. Команды, пытающиеся compress, производят mail loss; команды, пропускающие phases entirely, производят mail loss без diagnostic visibility.

Alignment: тонкая часть

DMARC требует, чтобы либо SPF, либо DKIM не только passed, но и aligned с From-address доменом. Alignment имеет два режима:

• Relaxed (adkim=r, aspf=r): authenticated домен делит organizational домен с From-address. Пример: From info@mail.company.com, DKIM signs с company.com — relaxed alignment проходит, потому что они делят company.com organizational домен.

• Strict (adkim=s, aspf=s): authenticated домен должен exactly match From-address домен. Пример выше: From info@mail.company.com, DKIM с company.com — strict alignment проваливается, потому что они не exactly match.

Relaxed — default и работает для большинства setup’ов. Strict используется в high-security конфигурациях, где любая subdomain variance должна проваливать authentication.

Alignment-проблема, с которой большинство команд encounter: sending-сервисы, signing DKIM собственным доменом (например, generic SendGrid signing domain), а не вашим. Это производит DKIM pass + DKIM not-aligned, что DMARC относит как authentication failure. Фикс — конфигурация sending-сервиса для signing вашим доменом (иногда называется “custom DKIM” или “branded sending”).

Типичные DMARC policy ошибки

Старт на p=reject без мониторинга. Самая damaging DMARC-ошибка. Без monitoring-фазы вы не знаете, какие legitimate-источники проваливают authentication. p=reject приводит к immediate bounce этих legitimate-источников. Продакшен-команды никогда не стартуют на reject.

Пропуск rua адреса. DMARC-запись без rua не производит отчёты. Без отчётов у вас нет feedback на authentication state. Всегда включайте rua, указывающий на адрес, который вы можете мониторить.

Игнорирование DMARC-отчётов неделями. Отчёты приходят, но никто не читает. К тому времени, как кто-то realizes, что есть authentication-проблема, несколько недель кампаний прогнались с failures. Продакшен-команды review’ят DMARC-отчёты еженедельно во время миграции, помесячно steady-state.

Quarantine без ramp. Переход с p=none на p=quarantine; pct=100 за один шаг skip’ает ramp, ловящий edge cases. pct механизм существует precisely для того, чтобы позволить ramp safely.

Забывание subdomain. DMARC-запись на company.com не применяется к mail.company.com по дефолту. Параметр sp= устанавливает policy для subdomain. Команды, публикующие DMARC на apex домене, но не устанавливающие sp, кончают с subdomain mail bypassing policy.

Не aligning DKIM с From-доменом. Когда sending-сервисы подписывают своим доменом, DKIM проходит, но не aligned — и DMARC относит как failure. Всегда верифицируйте alignment, не только pass status, в DMARC-отчётах.

Отношение к DMARC как только security-фиче. DMARC имеет security benefits (anti-spoofing) и deliverability benefits (receiving-системы больше trust mail с DMARC-published доменов). Большинство B2B-команд adopt’ят для доставляемости; security benefit — side effect.

Выбор DMARC policy в 2026 — discipline-of-staging вопрос, не discipline-of-choosing-the-strictest. Команды, получающие хорошие deliverability исходы, используют p=quarantine после careful миграции. Команды, получающие deliverability disasters, прыгают прямо в p=reject без мониторинга и смотрят, как legitimate mail bounces неделями, до того как figure out, почему. Для полного deliverability контекста см. гайд по доставляемости email.