Defaults.Exposed › Исправления › Guides

«DMARC Policy Not Enabled»: что имеют в виду чекеры и честный первый шаг за 5 минут (2026)

Опубликовано 2026-07-08

Показатели по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 млн оценённых доменов. См. как мы выставляем оценки.

«DMARC policy not enabled» означает одну из двух разных вещей: у вашего домена вообще нет записи DMARC либо есть запись со значением p=none. Лишь 10,59% доменов — 27 640 987 из 261 086 232 — имеют принудительную политику DMARC, по данным переписи Defaults.Exposed. Опубликовать мониторинговую запись — пять минут; принудительное применение — это проект.

Это руководство расшифровывает предупреждение, даёт точную TXT-запись для публикации и точное место, куда её ставить, разбирает синтаксические промахи, из-за которых проваливаются первые попытки, и честно настраивает ожидания от первой недели отчётов DMARC. Это намеренно не руководство «почините DMARC за 5 минут» — пять минут дают вам видимость, а не защиту.

Что на самом деле означает «DMARC policy not enabled»?

Чекеры вроде MXToolbox сваливают два разных вывода в одно оранжевое предупреждение, а путь исправления зависит от того, какой из них у вас:

Данные по состоянию на 2026-06-29.

В первой строке живёт большая часть интернета: 75,11% оценённых доменов вообще не публикуют запись DMARC, а ещё 14,29% сидят на p=none. Важна инверсия последней строки: у 89,41% доменов нет принудительной политики DMARC — из 261 086 232 оценённых доменов переписи. Если ваш чекер показывает предупреждение, вы в подавляющем большинстве. Это не утешение; именно поэтому подделка почты остаётся дешёвой.

Одно уточнение, которое сбережёт вас от путаницы позже: DMARC — это слой политики поверх SPF и DKIM, проверяемый по заголовку From, который реально видит ваш получатель. «Not enabled» означает, что вы пока не сказали получателям что-либо делать. Если три значения политики для вас в новинку, объяснение простым языком — в статье что такое DMARC: none, quarantine, reject.

Что честно можно исправить за пять минут?

Опубликовать запись. Вот и всё честное обещание.

v=DMARC1; p=none; rua=mailto:[email protected]

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

Чего это не делает: p=none ничего не защищает. Поддельная почта доставляется ровно как вчера, и чекер при повторном сканировании завтра может по-прежнему говорить «policy not enabled» — справедливо, потому что зелёная галочка зарезервирована за quarantine или reject. Почему — мы разобрали в статье p=none — это не защита; поэтапный путь к политике, которая реально блокирует подделку, — в руководстве от p=none к p=reject. Пятиминутный шаг ниже — это то, с чего вы начинаете; то руководство — то, чем вы заканчиваете.

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

1. Запустите бесплатное сканирование, прежде чем трогать DNS. Оно скажет, какой из двух случаев у вас на самом деле — нет записи или p=none — и стоят ли под ней SPF и DKIM, что определяет, как быстро вы сможете потом перейти к принудительному применению.
2. Выберите адрес для получения отчётов. Выделенный ящик вроде dmarc-reports@yourdomain для начала подходит. Если вместо этого вы используете сервис анализа отчётов, см. FAQ ниже — у сторонних адресов есть тихий подвох.
3. Добавьте TXT-запись на хосте _dmarc. В большинстве DNS-панелей (разобранный пример — в руководстве по настройке DMARC у IONOS) вы вводите _dmarc в поле host/name — панель автоматически дописывает ваш домен, получается _dmarc.yourdomain.com. Значение: v=DMARC1; p=none; rua=mailto:[email protected]
4. Убедитесь, что запись резолвится. dig TXT _dmarc.yourdomain.com (или любой онлайн-чекер) должен вернуть ровно одну запись, начинающуюся с v=DMARC1. Большинство изменений DNS видны в течение минут; низкий TTL помогает.
5. Пересканируйте. Ваш отчёт покажет DMARC в режиме мониторинга — честное отражение того, где вы находитесь: отчёты включены, принудительное применение впереди.

Одна запись покрывает и ваши поддомены: получатели, не найдя записи на mail.yourdomain.com, откатываются к политике организационного домена, так что для начала мониторинга не нужна запись на каждый поддомен.

Какие ошибки при добавлении записи самые частые?

Почти каждая неудачная первая попытка — одна из этих, и они важны, потому что запись, которую невозможно распарсить, трактуется как отсутствие записи. Перепись насчитывает 48 648 опубликованных записей DMARC, которые не парсятся; опечатки, которые люди реально публикуют, каталогизированы в переписи опечаток DMARC.

• Не тот хост. Запись должна жить по адресу _dmarc.yourdomain.com, а не на самом домене. На голом домене она ничего не делает, и чекеры продолжают сообщать “no DMARC record found”.
• Двойное дописывание домена. Ввод _dmarc.yourdomain.com в панель, которая дописывает домен сама, даёт _dmarc.yourdomain.com.yourdomain.com. Вводите просто _dmarc.
• Запятые вместо точек с запятой. Теги разделяются ;. Нераспарсиваемая запись трактуется как отсутствие записи.
• Отсутствующий или не на своём месте v=DMARC1. Он должен быть первым тегом, написанным в точности так; записи, начинающиеся с p=, не проходят парсинг.
• Пропущенный mailto: в rua. rua=dmarc@yourdomain невалидно; должно быть rua=mailto:[email protected].
• Две записи DMARC. Получатели, найдя более одной записи v=DMARC1, игнорируют их все — то же семейство сбоев, что и множественные записи SPF.
• «Умные» кавычки из копипаста. Фигурные кавычки или неразрывные пробелы, пронесённые из документа, ломают парсинг. Если чекер говорит, что запись искажена, а на вид она правильная, — перенаберите её вручную.

Как будут выглядеть отчёты rua в первую неделю?

Настройте ожидания сейчас, чтобы не решить, что всё сломано:

• Они приходят примерно раз в сутки, от каждого получателя. Google обычно шлёт один агрегированный отчёт каждые 24 часа; Microsoft, Yahoo и другие — по своим циклам. Для небольшого домена первая неделя — это обычно горстка писем, в основном от [email protected].
• Это сжатые XML-вложения, а не дашборд. В сыром виде они почти нечитаемы; бесплатный парсер превращает их в таблицу отправителей.
• Объём следует за объёмом вашей почты. Если вы отправляете мало почты или в основном провайдерам, которые не отчитываются, ждите скудных данных. Две тихие недели — норма для домена с малым объёмом; проверьте запись через dig, а не считайте, что она не сработала.
• Готовьтесь к сюрпризам. Большинство доменов обнаруживают отправителей, о которых забыли, — CRM, инструмент выставления счетов, контактную форму. Каждому нужно выравнивание SPF или DKIM, прежде чем вы сможете включить принудительное применение. Если отчёты показывают, что DMARC не проходит, хотя SPF и DKIM по отдельности проходят, — это проблема выравнивания, см. DMARC не проходит, а SPF и DKIM проходят.

И вообще запросите отчёты: 64,3% доменов с записью DMARC не публикуют адрес rua=, поэтому не получают от неё отчётов — срез переписи по этому вопросу в статье DMARC вслепую. Всё, что вы здесь узнаете, питает развёртывание принудительного применения — мониторинг это первая неделя того проекта, а не пункт назначения. Застрять на p=none навсегда — самый частый способ, которым домены оказываются в тех 89,41%.

Часто задаваемые вопросы

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

Я опубликовал запись — почему чекер всё ещё говорит «policy not enabled»? Потому что он говорит вам правду: ваша политика — none, а зачёт чекеры резервируют за quarantine или reject. Вы присоединились к доменам, которые мониторят, но не применяют политику принудительно, — по состоянию на 2026-06-29 лишь 10,59% из 261 086 232 оценённых доменов применяют её принудительно. Предупреждение исчезнет, когда вы завершите развёртывание до принудительного применения.

Нужно ли настраивать SPF и DKIM до добавления DMARC? Чтобы ваша почта проходила DMARC, нужен хотя бы один из них — с выравниванием, — но они не обязаны быть идеальными до публикации p=none. Мониторинг — это именно способ найти сломанное: у 70 368 600 из 261 086 232 оценённых доменов (по состоянию на 2026-06-29) мягкий SPF и нет принудительного DMARC, и именно из отчётов они узнали бы, что их тормозит.

Можно ли отправлять отчёты стороннему анализатору вместо собственного ящика? Да — но адрес rua на другом домене требует, чтобы поставщик опубликовал запись авторизации (yourdomain._report._dmarc.vendor.com), иначе получатели молча не отправят отчёты. Уважаемые сервисы делают это автоматически; если отчёты так и не приходят, проверьте это в первую очередь.

Отправьте владельцу отчёт

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

Проверьте свой домен бесплатно

Узнайте, какой из двух случаев у вас — нет записи или p=none — и что под этим стоит, приватно и только для владельца.

Проверьте свой домен → · Исправить DMARC → · От p=none к p=reject → · Как мы выставляем оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.