Как прочитать DMARC-политику компании за десять секунд (и что она вам не скажет)

Один DNS-запрос покажет вам, что компания просит мировые почтовые серверы делать с поддельной почтой, отправленной от её имени. Запись находится в открытом доступе, и команда занимает одну строку: dig +short TXT _dmarc.example.com. В ответе вернётся короткая строка параметров, внутри которой — одна инструкция: p=none, p=quarantine или p=reject — выражающая предпочтение владельца домена в случае, если сообщение, использующее его домен, не пройдёт аутентификацию.

Текущая спецификация RFC 9989, опубликованная в мае 2026 года как документ IETF Standards Track, заменила более старый RFC 7489. Она определяет три значения почти лаконично:

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

Прочитайте эти слова ещё раз, потому что они намного слабее, чем это принято признавать в большинстве объяснений DMARC. Политика — это предпочтение, опубликованное отправителем для рассмотрения получателями. Это не инструкция, которую получатель обязан выполнить. RFC 9989 говорит об этом в одном предложении: «Окончательная обработка любого сообщения всегда является вопросом локальной политики и остаётся на усмотрение получателя почты». В этом же разделе раскрываются оба аспекта последствия — получатели «МОГУТ отклонить или поместить в карантин сообщение даже если оно прошло проверку валидации DMARC», и они «НЕ ДОЛЖНЫ отклонять сообщения исключительно на основании опубликованной политики 'reject'», именно чтобы законная почта, отправленная способами, которые DMARC не может описать, и письма от списков рассылки не были уничтожены.

Что же на самом деле значит p=none? Меньше, чем обычно предполагают. По терминологии спецификации — это режим мониторинга: владелец домена собирает сводные отчёты и «не выражает никакого предпочтения по обработке сообщений, не прошедших валидацию DMARC», а получатель, внедривший DMARC, «может всё ещё» проверять использование домена. Это не означает, что что-то отключается на стороне получателя. Спам-фильтры вашего провайдера, оценка репутации, проверка URL и анализ вложений — это отдельные механизмы, которые работают независимо от того, что опубликовал отправитель. Поддельное сообщение, поступившее в домен с p=none, не попадает в ваш ящик благодаря этой записи; оно просто передаётся получателю без выраженного предпочтения, а получатель принимает решение.

Вторая половина недопонимания идёт в другую сторону. DMARC не проверяет опасную часть фишингового письма. Его собственная спецификация перечисляет, что сознательно исключено из области действия, и «анализ содержимого» указан в этом списке. Она также утверждает, что DMARC «не рассматривает использование визуально похожих имён доменов или злоупотребление полем отображения имени отправителя RFC5322.From, читаемым человеком» — именно эти два трюка используются в большинстве писем с выдачей себя за другой бренд. И касательно значения успешной проверки: «успешная проверка DMARC сама по себе не гарантирует, что доставка сообщения в ящик получателя была бы безопасной или желательной». Должным образом аутентифицированное сообщение от временного домена проходит DMARC без проблем. DMARC отвечает на вопрос: кому разрешено использовать домен в заголовке From:. Ничего больше.

Именно здесь правила 2024 года для массовых отправителей регулярно неправильно интерпретируются, включая первую версию этой статьи. Рекомендации Google требуют от отправителей 5000 или более сообщений в день на аккаунты Gmail «настроить DMARC-аутентификацию электронной почты для вашего отправляющего домена», и затем говорят в том же духе: «Ваша политика обеспечения DMARC может быть установлена на none». Собственный Sender Hub Yahoo, который нужно читать отдельно, а не предполагать, что он копирует Google, формулирует требование как «опубликовать действительную DMARC-политику как минимум с p=none — DMARC должен пройти», и не публикует никакого порога числового объёма. Оба набора требований вступили в силу с февраля 2024 года. Ни один не заставляет никого уходить с p=none. Что оба действительно заставляют — так это аутентификацию, которая согласуется: Google требует, чтобы «домен в поле From: заголовка отправителя совпадал либо с доменом SPF, либо с доменом DKIM», а Yahoo говорит, что приемлемо ослабленное выравнивание. Выравнивание, а не строгость — вот что критично.

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

Вам не нужен терминал, чтобы проверить. Бесплатные инструменты поиска — domain checker от dmarcian, DMARC check от MXToolbox — получают запись и выводят политику для вас. Сделайте это для вашего банка, поставщика зарплаты, авиакомпании, на которой вы летаете. Просто прочитайте ответ за то, что он есть: выражение намерения владельцем домена, один из множества входных данных в решении, которое ваш почтовый провайдер принимает самостоятельно, об одном конкретном типе подделки. Это действительно полезная вещь, которую можно прочитать за десять секунд. Это не вердикт о том, безопасно ли следующее сообщение, которое утверждает, что оно от этого бренда.

Исправление, 20 октября 2026. В более ранней версии этой статьи p=none описывалось как доставка подделок в ящик, а p=reject как единственный параметр, который блокирует поддельное сообщение; говорилось, что правила Google и Yahoo 2024 года для массовых отправителей заставили отправителей уходить с p=none; и была приведена цифра примерно одного из трёх доменов с обеспечением. Описания политики были исправлены в соответствии с RFC 9989; Google и Yahoo в действительности принимают p=none, как процитировано выше из их собственной документации; а цифра обеспечения была удалена, потому что в основном отчёте не указана выборка или знаменатель. В статье также теперь указано, что DMARC не проверяет.

@@END@@