No DMARC record found: одна строка, которой не хватает вашему домену

Коротко

• Сообщение означает, что по адресу _dmarc.yourdomain.com нет записи TXT. Ваш почтовый сервер не сломан.
• Добавьте одну запись TXT с именем хоста _dmarc и значением v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. С p=none доставка остаётся точно такой же, какой была.
• Gmail, Yahoo и Outlook.com требуют эту запись только от массовых отправителей. Добавьте её всё равно: Google считает по всему домену и никогда не снимает статус массового отправителя, а отчёты начинают приходить, только когда запись существует.
• Если сервис проверки всё ещё ничего не находит, ищите не тот DNS-хостинг, удвоенное имя хоста или две записи DMARC. Две записи отменяют друг друга.
• Стандарт изменился в мае 2026 года с выходом RFC 9989: тега pct больше нет, появились t и np. Справка Google по состоянию на октябрь 2026 года всё ещё описывает pct.

«No DMARC record found» (запись DMARC не найдена) означает, что сервис проверки запросил в DNS запись TXT по адресу _dmarc.yourdomain.com и ничего не получил. На вашем почтовом сервере ничего не сломано. Исправляется это одной записью TXT с именем хоста _dmarc и значением v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. С p=none ваша почта доставляется точно так же, как раньше. Вы лишь сообщаете получателям, что участвуете, и начинаете получать отчёты.

DMARC — третья из трёх почтовых записей, наряду с SPF и DKIM. SPF перечисляет серверы, которым разрешено отправлять от имени вашего домена. DKIM подписывает каждое сообщение. DMARC говорит получателю, что делать, когда ни одна из двух проверок не ручается за домен в вашем адресе From, и куда отправлять ежедневную сводку. С мая 2026 года он определён в RFC 9989, который заменил более старый RFC 7489. Многие руководства всё ещё описывают прежнюю версию, как и справочная страница Google по состоянию на октябрь 2026 года.

Какую запись добавить

Войдите туда, где управляется DNS вашего домена. Это компания, на которую указывают ваши серверы имён, и не всегда та, у которой вы купили домен. Добавьте новую запись с такими значениями:

Записанная строкой в файле зоны, готовая запись выглядит так:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Замените example.com своим доменом. Три части делают следующее:

• v=DMARC1 помечает строку как запись DMARC. Он должен стоять первым, с DMARC1 заглавными буквами. Иначе получатели игнорируют всю запись.
• p=none задаёт политику: обращайтесь с моей почтой так, как обращались бы в любом случае. Из-за этой записи ничего не блокируется и не переносится в спам.
• rua=mailto:… задаёт адрес для ежедневных отчётов. Создайте этот адрес или псевдоним с пересылкой вам, прежде чем публиковать запись.

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

Как проверить, что всё получилось

Спросите DNS сами. В macOS или Linux откройте терминал и используйте dig. В Windows используйте nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Если запись действует, строка вернётся в кавычках. Вот что ответил собственный домен Google 5 октября 2026 года:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Пустой ответ означает, что записи ещё нет или она не там, где её ищут получатели. Когда ваш собственный запрос покажет строку, снова запустите сервис проверки, который выдал вам сообщение. MXToolbox, например, формулирует проблему как «No DMARC Record found» и поясняет, что «у вашего домена нет опубликованной записи DMARC».

Что означает каждая часть записи DMARC

Запись состоит из пар tag=value, разделённых точкой с запятой. По стандарту обязателен только v, и он должен быть первым. p ставьте вторым: в справке Google сказано, что «теги v и p должны быть указаны первыми», и прежний стандарт ожидал того же порядка. Вот теги из RFC 9989, раздел 4.7:

Старые записи часто заканчиваются на pct=100. Этот тег был задуман, чтобы применять политику к части писем, не прошедших проверку. RFC 9989 убрал его вместе с rf и ri и объясняет причину:

Опыт эксплуатации показал, что тег «pct» обычно применялся неточно, если только указанное значение не равнялось 0 или 100 (значение по умолчанию), а неточности при других значениях сильно различались от одной реализации к другой.

Получатели обязаны игнорировать неизвестные им теги, поэтому старый pct=100 не вредит. Записи yahoo.com и microsoft.com ещё содержали его 5 октября 2026 года, а справочная страница Google по-прежнему рекомендует pct для постепенного внедрения. В новой записи его не указывайте.

Нужен ли DMARC, если вы отправляете всего несколько писем в день?

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

Источники: правила Google для отправителей, Sender Best Practices от Yahoo и объявление Microsoft для отправителей больших объёмов, все по состоянию на октябрь 2026 года. Если вы отправляете тридцать писем в день с одного ящика, никто из них этой записи не требует. И всё же есть три причины добавить её сейчас.

• Порог считается по домену и не обнуляется. Google суммирует все сообщения на личные аккаунты Gmail, которые приходят с одного основного домена, включая поддомены. В его вопросах и ответах для отправителей сказано: «Отправители, которые хотя бы один раз соответствовали указанным выше критериям, навсегда считаются массовыми отправителями».
• И Google, и Yahoo рекомендуют её всем. Google пишет: «мы рекомендуем всегда настраивать SPF, DKIM и DMARC для ваших доменов». Yahoo «настоятельно призывает всех отправителей публиковать политику DMARC для каждого домена, который отправляет почту».
• Без записи вы не получаете отчётов. По ним видно, какие серверы отправляют почту с вашим доменом в строке From: и ваши собственные сервисы, и посторонние.

Для массовых отправителей отсутствие записи имеет последствия. Вопросы и ответы Google для отправителей указывают для этого временную ошибку 4.7.31: «у отправляющего домена нет записи DMARC, или запись DMARC не задаёт политику DMARC». Та же страница говорит, что с ноября 2025 года письма, которые не отвечают требованиям, ждут «временные и постоянные отклонения».

Запись добавлена, а проверка всё ещё ничего не находит?

Тогда причина обычно в одном из следующих пунктов. Пройдитесь по ним с запросом dig, приведённым выше.

• Вы изменили DNS не там. Если ваши серверы имён находятся у другой компании, а не у регистратора, записи, введённые у регистратора, никогда не запрашиваются. dig +short NS example.com показывает, кто отвечает за ваш домен.
• Неверное имя хоста. Запись находится на самом example.com или на удвоенном имени, как описано выше. Получатели запрашивают только _dmarc.example.com.
• Записей DMARC две. Стандарт здесь строг: «Если для одной цели возвращается несколько записей политики DMARC, все они отбрасываются». Объедините их в одну. Два адреса для отчётов указываются в одном rua через запятую.
• Первый тег не равен в точности v=DMARC1. Строчные буквы, опечатка вроде DMARC 1 или p= перед ним делают запись недействительной.
• Тип записи не TXT, или значение вставлено из документа с типографскими кавычками. Вводите значение простым текстом, без кавычек, если справка вашего DNS-хостинга их не требует.
• Старый ответ ещё в кэше. Резолверы некоторое время помнят ответ «такой записи нет». Спросите один из своих серверов имён напрямую, добавив его имя к запросу, например dig +short TXT _dmarc.example.com @ns1.example.net. Если запись там видна, сервисы проверки тоже скоро её увидят.

Куда приходят отчёты и что с ними делать

Каждый получатель, которому пришла почта с вашим доменом в строке From, отправляет отчёт на адрес rua. Согласно странице Google об отчётах DMARC, они «обычно отправляются раз в день по электронной почте». Отчёт приходит как файл XML, обычно сжатый, вложенный в письмо. Формат описывает RFC 9990.

Google предупреждает, что крупные организации «могут получать до сотен и даже тысяч отчётов ежедневно», и рекомендует группу или отдельный ящик. Число зависит от того, сколько вы отправляете и на сколько доменов, поэтому один-два ящика дают гораздо меньше. Достаточно псевдонима вроде dmarc@ с фильтром в отдельную папку.

Адрес должен быть в том же домене, что и запись. Если вы хотите получать отчёты в другом месте, другой домен должен дать согласие, опубликовав собственную запись. Без неё получатели обязаны игнорировать адрес (RFC 9990, раздел 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

Поэтому бесплатный адрес Gmail не подходит как адрес для отчётов: gmail.com такой записи не публиковал, когда мы проверяли 5 октября 2026 года.

В файле каждый блок record соответствует одному отправляющему серверу: его IP-адрес, число сообщений, а в policy_evaluated указано, прошли ли DKIM и SPF для вашего домена. Вы ищете две вещи. Знакомые вам серверы, у которых стоит fail, нужно исправить, и руководство DMARC не проходит, хотя SPF и DKIM проходят объясняет как. Незнакомые серверы означают либо сервис, о котором вы забыли, либо кого-то, кто пользуется вашим именем.

После p=none: когда ужесточать политику

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

Прежде чем ужесточать, нужно, чтобы каждый законный источник вашей почты проходил проверку. RFC 9989 говорит, что такие пробелы «ДОЛЖНЫ быть устранены до любой попытки» применить политику и что, в зависимости от того, как часто вы отправляете, для уверенности «могут потребоваться многие месяцы» отчётов. Страница Google о внедрении считает, что одной недели отчётов «обычно достаточно». С одним ящиком и одним-двумя сервисами вы ближе к цифре Google, но дайте несколько недель, чтобы в отчётах появились и ежемесячная отправка счетов, и форма обратной связи.

В самом шаге два источника расходятся. Google по-прежнему предлагает p=quarantine; pct=5 и постепенное повышение этого числа. Стандарт отказался от pct и предлагает вместо него следующее:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y просит получателей пока обрабатывать непройденные проверки на одну ступень мягче, то есть как none. Когда отчёты остаются чистыми, уберите t=y. Учтите, что получатель, который не знает этого тега, игнорирует его и применяет quarantine полностью и что страницы Google по состоянию на октябрь 2026 года не упоминают t. Если более строгая политика ударит по письмам, которые вы пока не можете исправить, оставайтесь на p=none.

Какова роль WarmupBay

Когда вы подключаете ящик, WarmupBay проверяет SPF, DKIM и DMARC его домена. Если записи DMARC нет, он показывает готовую, которую можно скопировать. Прогрев можно начать и так. Если через 72 часа записей всё ещё нет, прогрев останавливается.

WarmupBay не может добавить запись за вас, потому что ваш DNS принадлежит вам, и он не собирает и не читает отчёты DMARC. Он занимается шагом, который идёт после записей: ваш ящик каждый день обменивается несколькими письмами с другими ящиками общего пула, начиная с трёх и прибавляя по одному в день, чтобы активность отправки нарастала постепенно. 10 писем в день бесплатны. Посмотрите, что охватывают проверка и прогрев, или подключите свой ящик, когда запись будет на месте.

Частые вопросы

Распространяется ли запись DMARC на example.com и на поддомены, например news.example.com?

Да. Получатель сначала запрашивает запись по адресу _dmarc.news.example.com. Если её нет, он обращается к записи организационного домена, example.com. К поддомену применяется политика из sp, если вы её задали, иначе политика из p.

Можно ли опубликовать v=DMARC1; p=none без адреса rua?

Да. Это допустимая запись, и она считается опубликованной политикой. Отчётов вы не получите, поэтому не увидите, проходит ли проверку ваша собственная почта и кто ещё использует ваш домен. Yahoo называет работающий адрес rua настоятельно рекомендуемым, а Google рекомендует всегда его указывать.

Нужна ли запись DMARC второму домену, который я использую только для холодных рассылок?

Да. Получатели ищут запись для домена из адреса From каждого сообщения, поэтому запись на основном домене не покрывает другой домен. Используйте на втором домене ту же строку. Если его отчёты должны приходить на адрес в основном домене, основной домен должен опубликовать разрешающую запись, описанную в разделе «Куда приходят отчёты».

Что должен публиковать домен, с которого никогда не отправляют почту?

Строгую пару. M3AAWG рекомендует для доменов, которые никогда не отправляют почту, запись SPF v=spf1 -all и запись DMARC с p=reject, чтобы никто не мог использовать их в адресе From. Для DMARC это строка v=DMARC1; p=reject по адресу _dmarc.

Хуже ли p=none для моей почты, чем p=quarantine или p=reject?

Опубликованные правила для отправителей Gmail, Yahoo и Outlook.com требуют как минимум p=none и ничего строже. Политика определяет, что происходит с письмами, которые не проходят DMARC, в том числе с поддельными письмами от вашего имени. Одной функции нужно больше: BIMI, логотип рядом с вашими сообщениями, требует quarantine или reject, согласно справке Google.

Источники

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)