Что такое политика DMARC? «Нет», «Карантин» и «Отклонить»

Мошенничество с электронной почтой — одна из самых распространенных и опасных киберугроз, с которыми сегодня сталкиваются организации. Согласно отчету Verizon о расследованиях утечек данных, фишинг по-прежнему остается одной из основных причин утечек данных, и большинство атак начинается с поддельного домена электронной почты.

Политика DMARC — это ваша первая линия защиты. Определена в RFC 7489, DMARC (Domain-based Message Authentication, Reporting, and Conformance) — это протокол аутентификации электронной почты, который указывает принимающим почтовым серверам, что делать, если электронное письмо не проходит проверку аутентификации. Без него злоумышленники могут свободно выдавать себя за ваш домен, чтобы атаковать ваших клиентов, сотрудников и партнеров.

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

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

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

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

Как работает политика DMARC?

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

Пошаговый процесс аутентификации:

1. Отправитель электронного письма отправляет сообщение, в котором утверждается, что оно пришло с вашего домена.
2. Получающий почтовый сервер выполняет проверку аутентификации SPF и DKIM для сообщения.
3. Если сообщение проходит любую из этих проверок и домен совпадает с полем заголовка «From», оно проходит аутентификацию DMARC и попадает в папку «Входящие» получателя.
4. Если сообщение не проходит проверку DMARC, сервер считывает вашу запись DMARC из ваших записей DNS.
5. В соответствии с опубликованной вами политикой DMARC сервер доставляет, помещает в карантин или отклоняет неаутентифицированное сообщение.
6. Принимающий сервер отправляет сводные отчеты DMARC обратно на адрес, указанный в вашей записи DMARC.

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

Без согласования злоумышленник может обойти проверку SPF для одного домена, при этом подделав адрес отправителя, который фактически видят ваши получатели, под совершенно другой домен.

Перед настройкой DMARC

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

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

Рекомендуем прочитать: Фишинг по электронной почте и статистика DMARC: тенденции в области безопасности на 2026 год

3 варианта политики DMARC

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

1. p=нет

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

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

p=none не обеспечивает никакой защиты от подделки адресов электронной почты, поскольку:

• Нежелательные письма по-прежнему доставляются
• Мошеннические сообщения по-прежнему попадают в почтовые ящики
• Злоумышленники могут свободно использовать ваш домен

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

2. p = карантин

p=quarantine — это переходная политика принудительного применения. Она предписывает принимающему почтовому серверу с осторожностью относиться к сообщениям, не прошедшим аутентификацию, и перенаправлять их в папку «Спам» или «Нежелательная почта» получателя вместо папки «Входящие».

На письма, прошедшие аутентификацию DMARC, это никак не влияет. Только неаутентифицированные сообщения рассматриваются как подозрительные и удаляются из папки «Входящие».

Политика политика карантина обеспечивает активное соблюдение правил, одновременно создавая «подушку безопасности». Если легитимный источник электронной почты был неправильно настроен и начинает проваливать проверки DMARC, письма попадают в папку «Спам», а не отклоняются сразу. Вы можете обнаружить проблему, исправить ее и избежать сбоев в потоке электронной почты.

Переходить в режим p=quarantine следует только после тщательного анализа отчетов DMARC и подтверждения того, что все известные легитимные отправители проходят надлежащую аутентификацию.

3. p = отклонить

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

Полное отклонение подделка домена на корню, защищает репутацию вашего бренда и сигнализирует почтовым провайдерам о том, что ваш домен заслуживает доверия, что может улучшить доставку ваших легитимных писем в папку «Входящие».

Однако настройка p=reject не допускает ошибок. Все письма от легитимных отправителей, которые не прошли надлежащую аутентификацию до перехода на эту политику, будут отклонены. Перед тем как приступить к этому шагу, необходимо убедиться, что все легитимные отправители внесены в белый список и проходят аутентификацию DMARC.

Другие теги политики DMARC, о которых вам следует знать

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

sp= (Политика поддоменов)

Тег sp= определяет, как ваша политика DMARC применяется к субдоменам. Если вы настроили политику для корневого домена, но оставили sp= , ваши субдомены по умолчанию наследуют политику корневого домена. В большинстве случаев это подходит, но если вы хотите применить другой уровень принудительного исполнения к субдоменам, вам необходимо явно указать это.

Например, если для вашего корневого домена установлено значение p=reject, но субдомен ещё не готов к полному применению политики, вы можете установить значение sp=quarantine, чтобы применить к нему более мягкую политику.

pct = (тег процента)

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

Вместо того чтобы сразу переключить весь трафик, можно начать с pct=10 или pct=25 и постепенно увеличивать значение, отслеживая отчеты.

adkim= и aspf= (режимы выравнивания)

Эти два тега определяют, насколько строго DMARC проверяет соответствие домена для DKIM и SPF соответственно. Доступны два варианта: r (режим с пониженными требованиями) и s (строгий режим). Режим с пониженными требованиями допускает совпадение субдомена, то есть mail.yourdomain.com пройдет проверку на соответствие для yourdomain.com.

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

fo= (Параметры отчетности об ошибках)

Тег fo= определяет, когда генерируются отчеты DMARC . По умолчанию значение равно 0, что означает отправку отчета только в случае сбоя как SPF, так и DKIM. Установка fo=1 приводит к отправке отчета при сбое либо SPF, либо DKIM.

Установка параметра fo=s или fo=d приводит к формированию отчетов, посвященных сбоям SPF или DKIM соответственно. Для более полного понимания причин сбоев наиболее полезной настройкой является fo=1.

Сравнение настроек DMARC: p=none, p=quarantine и p=reject

Выбрать один из трёх вариантов политики DMARC проще, если сравнить их друг с другом. Воспользуйтесь этой таблицей в качестве краткого справочника при выборе политики, наиболее подходящей для вашего текущего этапа внедрения DMARC.

Большинству организаций следует рассматривать этот процесс как поэтапный: начать с p=none, проанализировать отчеты DMARC, исправить ошибки в настройках, перейти к p=quarantine, а затем перейти к p=reject после проверки всех легитимных источников электронной почты.

Как перейти из состояния p=none в состояние p=reject

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

Шаг 1: Опубликуйте запись с параметром p=none и начните сбор данных

Для начала опубликуйте запись DMARC со значением p=none и действительным адресом rua=. Это переведет вас в режим мониторинга.

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

Шаг 2: Проанализируйте сводные отчеты DMARC

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

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

Перед внесением каких-либо изменений в политику следует отслеживать результаты аутентификации DMARC в течение как минимум двух–четырёх недель. С помощью сводных отчётов PowerDMARC легко отслеживать эти тенденции с течением времени.

Шаг 3: Устранение несоответствий в настройках SPF и DKIM

Для каждого легитимного источника почты, который не проходит проверку DMARC, необходимо выяснить и устранить первопричину. К типичным мерам по устранению относятся добавление отсутствующих IP-адресов в запись SPF, настройка подписи DKIM для сторонних почтовых сервисов, а также исправление ошибок конфигурации в потоках перенаправленной почты.

Регулярная проверка отчетов DMARC поможет вам выявить эти проблемы, прежде чем они приведут к сбоям в доставке.

Шаг 4: Добавьте всех надежных отправителей в белый список

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

Шаг 5: Перейти в режим p=карантин при уровне от 10 до 25 процентов

Используйте тег pct=, чтобы сначала применить новую политику к определенной доле сообщений с ошибками. Начните с настройки p=quarantine при значении pct=25 и внимательно следите за отчётами.

Если легитимные письма начинают попадать в папку «Спам», значит, у вас есть отправитель, с которым необходимо разобраться, прежде чем продолжать.

Шаг 6: Увеличьте значение p (карантин) до 100 процентов

Как только вы убедитесь, что 25 % сообщений с ошибками действительно являются несанкционированными, увеличьте значение pct= до 100 и продолжайте мониторинг.

Шаг 7: Перейти к p=reject

Как только p=quarantine начнёт работать стабильно со 100-процентным показателем, не задерживая легитимную почту, вы сможете перейти к полному применению фильтра. Теперь все неавторизованные сообщения будут блокироваться до доставки.

Хостируемый сервис PowerDMARC хостируемый сервис DMARC может полностью взять на себя управление этим переходом, автоматизировав обновление политик без необходимости ручных изменений DNS на каждом этапе.

Отчетность по DMARC: сводные отчеты и отчеты для экспертизы

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

Существует два типа отчетов, и они служат совершенно разным целям.

Распространенные ошибки в настройке политики DMARC и способы их устранения

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

Отсутствует или неверно сформирована запись DMARC TXT

Публикация с указанием неверного имени хоста, отсутствие тега v=DMARC1 или создание дубликатов записей приведет к тому, что принимающие серверы полностью проигнорируют вашу политику. К распространённым ошибкам при указании имени хоста относится использование dmarc.yourdomain.com вместо _dmarc.yourdomain.com.

Решение: Проверьте вашу запись с помощью инструмента DMARC Record Checker от PowerDMARC до и после любого изменения DNS.

SPF и DKIM не совпадают

Ваши проверки SPF и DKIM могут пройти успешно, но ваши сообщения все равно не пройдут проверку DMARC, если аутентифицированный домен не совпадает с заголовком «From». Это одна из наиболее часто неправильно понимаемых причин сбоев при внедрении DMARC.

Решение: Проверьте настройки выравнивания adkim= и aspf= в записи DMARC. Для большинства организаций правильным значением по умолчанию является «Relaxed alignment» (смягченное выравнивание), которое допускает совпадение субдоменов без необходимости точного совпадения домена.

Ошибки при доставке легитимных писем после перехода в режим принудительной доставки

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

Решение: Во время расследования вернитесь к p=quarantine с низким значением pct=. Найдите неисправного отправителя в ваших сводных отчетах, исправьте его настройки SPF или DKIM, убедитесь, что он стабильно проходит проверку, а затем вернитесь к прежним настройкам.

Превышение ограничений на количество запросов DNS по SPF

Максимальное количество записей SPF ограничено 10 поисков в DNS. Если вы отправляете достаточное количество писем через сторонние платформы, вы превысите этот лимит, что приведет к сбою SPF и, как следствие, к сбоям DMARC для легитимной почты.

Решение: Проведите аудит записи SPF и воспользуйтесь автоматизированным управлением SPF, чтобы упростить запись и не превышать лимиты запросов.

Адрес для отправки отчетов не настроен

Без действующего адреса rua= у вас будет развернута политика, но вы не сможете отслеживать, работает ли она, что вызывает сбои или происходит ли подделка адресов в вашем домене.

Решение: С самого начала всегда указывайте действительный адрес rua=. Если вы управляете несколькими доменами, используйте централизованную платформу отчетности, чтобы объединить сводные отчеты DMARC в одном месте.

Защитите свой домен с помощью PowerDMARC

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

PowerDMARC создан для того, чтобы упростить управление всем этим процессом. Платформа обеспечивает поддержку на каждом этапе — от создания первой записи DMARC до полного внедрения политики p=reject. Она включает в себя удаленное управление политиками, панели автоматической отчетности, оповещения об угрозах в режиме реального времени, а также мониторинг SPF и DKIM для всех ваших доменов.

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

Ваш домен — это ваш бренд. Не оставляйте его без защиты.

Закажите демонстрацию и сделайте первый шаг к полной аутентификации и обеспечению соблюдения правил электронной почты уже сегодня.

Вопросы и ответы

1. Какова политика DMARC по умолчанию?

По умолчанию политика DMARC отсутствует. Если запись DMARC отсутствует, принимающие серверы не будут выполнять проверки DMARC. При первоначальном создании записи DMARC рекомендуется для целей мониторинга использовать значение p=none.

2. Могут ли политики DMARC повлиять на доставляемость электронной почты?

Да, при правильной реализации политики DMARC могут повысить доставляемость на 10–15 %, поскольку почтовые провайдеры больше доверяют аутентифицированным доменам. Однако неправильная реализация может привести к тому, что легитимные письма будут помещены в карантин или отклонены.

3. В чём разница между SPF, DKIM и DMARC?

SPF проверяет, что отправляющий сервер авторизован, DKIM обеспечивает целостность сообщений с помощью криптографических подписей, а DMARC обеспечивает соблюдение политик и формирование отчетов на основе результатов проверки SPF и DKIM.

4. Как долго мне следует придерживаться режима «p=none», прежде чем переходить к более строгим правилам?

Оставьте значение p=none не менее чем на 30 дней, чтобы собрать полные отчеты DMARC. Для крупных организаций с несколькими источниками электронной почты рекомендуется выделить 60–90 дней, чтобы обеспечить идентификацию и надлежащую аутентификацию всех легитимных отправителей.

5. Какая политика DMARC является наиболее эффективной?

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

6. Как исправить политику DMARC?

Вы можете обновить свою политику DMARC, отредактировав запись DMARC TXT непосредственно в консоли управления DNS и изменив значение тега p=. Если вам нужен более простой вариант, сервис Hosted DMARC от PowerDMARC позволяет обновить политику одним щелчком мыши.

7. Какую политику DMARC вы бы использовали для отклонения писем, не прошедших проверку DMARC?

Используйте параметр p=reject. Это указывает почтовым серверам-получателям полностью блокировать любые сообщения, не прошедшие аутентификацию DMARC. Такие письма не попадут ни в папку «Входящие», ни в папку «Спам» адресата. Если вы хотите, чтобы письма, не прошедшие аутентификацию, попадали в папку «Спам», а не блокировались полностью, используйте вместо этого параметр p=quarantine.

• О сайте
• Последние сообщения

Майтхам аль-Лоуати

Эксперт по кибербезопасности, генеральный директор PowerDMARC

Майтем - технологический предприниматель, эксперт по кибербезопасности, генеральный директор и основатель PowerDMARC с 15-летним опытом работы в отрасли. Майтем получил степень Global MBA в Манчестерском университете и различные профессиональные сертификаты, включая CISSP, CISM, CRISC и ISC2 CCSP.

Последние сообщения Maitham Al Lawati (см. все)

• Статистика фишинга и DMARC: тенденции в области безопасности электронной почты на 2026 год — 6 января 2026 г.
• Как исправить ошибку «SPF-запись не найдена» в 2026 году — 3 января 2026 года
• SPF Permerror: как исправить слишком много DNS-запросов — 24 декабря 2025 г.