554 5.7.5 Постоянная ошибка при оценке политики DMARC [SOLVED]

A 554 5.7.5 Постоянная ошибка оценки политики DMARC указывает на сбой в аутентификации электронной почты, препятствующий доставке электронной почты из-за неправильно настроенной записи DMARC.

Владельцы доменов могут столкнуться с сообщением "554 5.7.5 постоянная ошибка, оценивающая политика DMARC" по следующим причинам:

1. Неправильный синтаксис записей SPF, DKIM или DMARC 
2. Избыточные или отсутствующие символы в записях DNS 
3. Отсутствие поддержки электронной почты, выровненной по SPF 
4. Несоответствие доменов подписи DKIM

Постоянная ошибка "554 5.7.5, оценивающая DMARC политика" - это распространенная ошибка, которая останавливает SMTP порты от приема писем с вашего домена. Обычно проблема возникает из-за комбинации настроек в записи SPF, DMARC-записиили почтовой службы.

В этом руководстве мы опишем, как быстро и легко решить эту проблему.

Упростить 554 5.7.5 Постоянная ошибка с PowerDMARC!

Почему вы получаете ошибку "554 5.7.5 Permanent Error Evaluating DMARC Policy"?

Если вы столкнулись с ошибкой "554 5.7.5 permanent error evaluating DMARC policy", вот некоторые распространенные причины этой ошибки:

1. Неполные или неправильные настройки DMARC-записи

Неполные записи DMARC могут привести к ошибкам при оценке политики DMARC. Например, отсутствие тега p=. Если ваша DMARC-запись выглядит примерно так: 

v=DMARC1; pct=100;

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

Аналогично, синтаксические ошибки в вашей записи, такие как лишние символы или пробелы, также могут вызвать постоянную ошибку 554 5.7.5, оценивающую ошибку политики DMARC. 

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

В этом примере символ ":" является неправильным, поскольку за всеми механизмами следует знак равенства (=), а затем значение. 

Правильная последовательность записей DMARC

• Ваша DMARC-запись должна начинаться с имени версии v=DMARC1 
• Метка политики также является обязательной и должна иметь значение none/reject/quarantine 
• Все теги DMARC должны сопровождаться символом "=[значение]" и заканчиваться точкой с запятой (;). 
• Между отдельными механизмами или тегами должен быть одинарный пробел 
• Между каждым заданным механизмом не должно быть пробелов, например: p=none; 

2. Неправильное выравнивание DKIM

DKIM расшифровывается как DomainKeys Identified Mail. Это метод проверки подлинности отправителя электронной почты, который не позволяет злоумышленникам выдавать себя за доменное имя отправителя электронной почты.

Иногда могут возникнуть проблемы с аутентификацией DKIM. Несоответствие между тегом «d=» в подписи DKIM и доменом отправителя приведет к сбою оценки DMARC.

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

3. Неправильная запись SPF

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

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

• Ваша запись SPF должна заканчиваться механизмом отказа (-all или ~all). 
• Избегайте использования нейтральной политики для оценки SPF 
• Избегайте превышения лимитов SPF DNS и поиска пустоты 

4. Отсутствие поддержки электронной почты с SPF-выравниванием со стороны вашего ESP

Иногда, если вы получаете ошибку "554 5.7.5 Permanent Error Evaluating DMARC Policy", это может быть проблемой на стороне вашего поставщика услуг электронной почты. Не все поставщики услуг электронной почты поддерживают письма, выровненные по SPF. Некоторые из них даже обрабатывают SPF-политики внутри компании, что может привести к ошибкам, если у вас включен SPF для вашего домена. 

Исправление "554 5.7.5 Постоянная ошибка при оценке политики DMARC" за 5 шагов

Вы можете выполнить следующие шаги, чтобы потенциально устранить ошибку "554 5.7.5 Permanent Error Evaluating DMARC Policy". Однако решение не гарантировано. Если выполнение этих шагов не устранит ошибку свяжитесь с нами для бесплатной оценки безопасности домена.

1. Удалите лишние символы из записи

Постоянная ошибка 5.7.5 при оценке политики DMARC может быть вызвана различными факторами, но преобладающие причины обычно включают:

• Неправильно использованные кавычки
• Лишние символы или знаки в записи
• Отсутствующая точка с запятой завершает запись.

Вот пример записи, которая выдала эту ошибку:

Сначала эта запись может показаться вам нормальной, но при тестировании мы получили сообщение "5.7.5 permanent error evaluating DMARC policy".

Когда мы проверили еще раз, мы поняли, что в конце записи была лишняя точка - если вы внимательно посмотрите на ту же запись выше, вы увидите, что в конце стоит точка (.). 

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

Вот как выглядит та же запись без ошибок:

2. Измените запись SPF с нейтральной на нейтральную

Если вы получаете сообщение об ошибке "5.7.5 постоянная ошибка при оценке политики DMARC" при попытке отправить электронное письмо, это, вероятно, потому, что ваша запись SPF установлена на Neutral.

SPF расшифровывается как Sender Policy Framework и помогает убедиться, что почтовый сервер, с которого отправляется письмо, является легальным. Недостаточно просто иметь сервер, который отправляет электронную почту; необходимо убедиться, что сервер легален. Именно это и делает SPF: он проверяет, что ваш почтовый сервер имеет соответствующие полномочия.

Почему ваша запись SPF не может быть нейтральной? 

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

Именно поэтому при внедрении DMARC вы должны хотя бы изменить запись SPF на softfail ~all или hardfail -all, чтобы люди знали, что сообщение от вашего доменного имени, скорее всего, безопасно.

3. Проверьте, поддерживает ли поставщик услуг электронной почты письма с SPF-выравниванием

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

Такие поставщики услуг электронной почты, как MailChimp и ProtonMail, имеют собственные записи SPF, и когда вы отправляете электронные письма через них, они не отправляют электронные письма с выравниванием по SFP. Поэтому важно проверить тип SPF-записи поставщика услуг электронной почты, чтобы узнать, поддерживает ли он электронную почту с SPF-выравниванием.

Если да, то ваша DKIM-подпись будет изменена в процессе отправки таким образом, чтобы адрес From соответствовал вашему собственному домену (а не домену MailChimp) и гарантировал, что вы пройдете проверку политики DMARC.

Если это не так, то вам необходимо использовать другого поставщика услуг электронной почты (или изменить настройки существующего поставщика), чтобы вы могли отправлять электронные письма с SPF-выравниванием.

4. Переход к политике p=none для DMARC

Если вы получаете ошибку "554 5.7.5 permanent error evaluating DMARC policy", это означает, что политика DMARC на вашем домене препятствует отправке писем. Чтобы исправить это, вам просто нужно изменить DMARC-запись у вашего DNS-провайдера на политику p=none.

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

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

Например, вы можете изменить эту запись:

к этому:

Что это значит для вас? Вы можете отправлять почту, даже если она не проходит DMARC. Однако в конечном итоге вам придется вернуться к политике p=reject или p=quarantine, чтобы предотвратить подмену почты на вашем домене.

5. Настройка аутентификации DomainKeys Identified Mail (DKIM)

Если вы столкнулись с кодом ошибки "554 5.7.5 permanent error evaluating DMARC policy", это означает, что аутентификация почты DomainKeys Identified Mail (DKIM) не была активирована для вашего домена, поэтому, чтобы пройти DMARC, вам необходимо установить запись аутентификации почты DKIM (если у вас еще нет SPF).

Вот ваши шаги для этого:

• Зарегистрируйтесь на PowerDMARC и выберите генератор DKIM-записей из нашего набора инструментов Power Toolbox. 
• Введите доменное имя, определите селектор (например, selector1) для записи и нажмите кнопку Generate. 
• Наш инструмент автоматически сгенерирует пары открытых и закрытых ключей DKIM. 
• Скопируйте созданное имя TXT-записи и значение TXT-записи (значение открытого ключа) и опубликуйте их в DNS, зайдя в консоль управления DNS. 

Требования к форматированию политики DMARC

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

•  Во-первых, ваша запись DMARC должна начинаться с "v=DMARC1". Это позволяет поставщикам электронной почты знать, что запись отформатирована в соответствии с версией DMARC, которая используется в настоящее время (это 1). 
•  Затем укажите политику. Политика должна быть либо p=none, p=quarantine, либо p=reject. Это указывает поставщикам электронной почты, что делать, если письмо не прошло проверку подлинности. 
• Поле policy в записи DMARC является обязательным полем после поля v= version. Политика может быть одной из трех: p=none, p=quarantine или p=reject. "None" означает, что вы хотите, чтобы почтовый провайдер ничего не делал, когда видит подозрительное письмо с вашего домена - он просто оставит его в покое и даже может доставить. "Карантин" означает, что вы хотите, чтобы подозрительные письма с вашего домена доставлялись как спам или нежелательная почта вместо того, чтобы доставляться как обычная почта. Наконец, "отклонить" означает, что вы хотите, чтобы подозрительные письма с вашего домена отклонялись и вообще не доставлялись.
•  Используйте двоеточия в качестве разделителей между значениями - это хорошая идея использовать двоеточия, а не точки с запятой. Точки с запятой могут вызвать проблемы, особенно когда в одной строке указывается несколько значений.
•  Не используйте лишние символы или плохие кавычки. Лишние пробельные символы в конце строк будут рассматриваться как часть записи, что может вызвать проблемы.

Вот пример хорошей записи DMARC:

Как найти ошибки в политике записей DMARC

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

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

1. Зарегистрируйтесь на PowerDMARC и перейдите к инструменту DMARC Lookup Tool в Power Toolbox.

2. Введите доменное имя в пустое поле.

3. После проверки вашей записи инструмент покажет вам обзор опубликованного синтаксиса и выделит ошибки в вашей записи.

4. Если есть ошибки, они будут выделены на странице. 

5. Как только вы узнаете, откуда берутся ошибки, вы сможете легко их устранить, используя инструкции, приведенные в каждом сообщении об ошибке.

Беспокоитесь ли вы о безопасности своей деловой электронной почты?

Это реальная проблема. На самом деле, многие кибератаки начинаются с электронного письма. В отчете Verizon DBIR за 2019 год сообщается, что 94 % утечек данных начинаются с атак, направленных на людей по электронной почте.

Но это не значит, что вы должны отказаться от работы с клиентами по электронной почте!

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

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

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

Защищен ли ваш домен от подделки электронной почты? Получите свой бесплатную DMARC сегодня!

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

Юнес Тарада

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.

Последние сообщения Юнеса Тарады (см. все)

• Объяснение DMARCbis — что меняется и как подготовиться - 16 апреля 2026 г.
• Неверный формат серийного номера SOA: причины и способы устранения - 13 апреля 2026 г.
• Как отправлять защищенные письма в Gmail: пошаговое руководство - 7 апреля 2026 г.