Устранение проблем с доставкой электронной почты для кодов ошибок от 5.4.6 до 5.4.14 в Exchange Online
Неприятно, когда после отправки электронного сообщения возвращается ошибка. В этом разделе описаны коды ошибок 5.4.6, 5.4.14 или другие коды ошибок, связанные с циклами маршрутизирования почты в отчете о невывозе (также известном как NDR, отказов, уведомления о состоянии доставки или DSN).
Почему мне пришло сообщение о недоставке?
Наиболее вероятной причиной является превышение допустимого хмеля сообщений или слом маршрута, по которому доставляется сообщение. В этом разделе предоставляются некоторые причины и решения.
5.4.6 указывает на проблему с циклом или маршрутикой в локальной Exchange Server, с которой вы, скорее всего, столкнулись бы в гибридной среде.
5.4.14 указывает на проблему с циклом или маршрутикой в Exchange Online.
Эта информация относится к диапазону кодов ошибок 5.4.6-5.4.20. Чтобы решить, как устранить проблему, используйте информацию из отчета о недоставке.
| Значок | Описание | Значок | Описание |
|---|---|---|---|
 | Мне пришло сообщение о недоставке. Как мне решить проблему? |  | Я администратор электронной почты. Как устранить эту проблему? |
Мне пришло сообщение о недоставке. Как мне решить проблему?
Как правило, эти проблемы могут быть устранены только администратором Exchange Online, а не средним отправителю электронной почты. Свяжитесь с администратором электронной почты и напишите им эту информацию, чтобы они могли попытаться решить проблему для вас.
Я администратор электронной почты. Как устранить эту проблему?
Наиболее распространенные проблемы и исправления описаны в следующих разделах.
Проблемы с обслуживаемым доменом
Убедитесь, что домен получателя настроен как авторитетный принятый домен в Exchange Online. Дополнительные сведения см. в разделе Управление принятыми доменами в Exchange Online.
Проблемы с гибридной конфигурацией
Если ваш домен является частью гибридного развертывания между Exchange и Exchange Online, проверьте следующие элементы в зависимости от конфигурации.
Маршрут всей входящих сообщений для гибридного домена через Exchange Online
Эта ошибка может произойти, когда запись MX для гибридного домена указывает на Exchange Online, а соединителек, используемый для маршрутизации электронной почты из Exchange Online в локальное Exchange, настроен на использование маршрутизации DNS вместо умной маршрутизации хостов.
Чтобы устранить проблему, настройте выделенный соединители, который будет использоваться для гибридного подключения. Этот соединитатель будет использовать интеллектуальную маршрутику хостов и будет настраивать ваш локальном гибридном сервере как смарт-хост. Самый простой способ устранить проблему — перезахоранить мастер гибридной конфигурации в локальной Exchange организации. Или вы можете проверить конфигурацию соединитетеля, используемого для гибрида, следуя следующим шагам:
Новый EAC
Откройте Центр администрирования Microsoft 365,а затем нажмите центр администрирования Exchange (вам может > потребоваться нажать . сначала покажите все). Появится новый экран EAC.
В центре администрирования Exchange (EAC) нажмите кнопку Mail Flow > соединители.
Выберите соединители, которые используются для гибридного подключения, а затем нажмите его.
Отображается экран свойств соединитетеля.
В статье Маршрутия нажмите кнопку Изменить маршрутику. Отображается экран маршрутизация.
Убедитесь, что правильный IP-адрес или FQDN указан для интеллектуального хоста в локальной Exchange организации.
Классический EAC
Откройте Центр администрирования Microsoft 365,а затем нажмите центр администрирования Exchange (вам может > потребоваться нажать . сначала покажите все).
Щелкните классический Exchange центр администрирования на левой области экрана New EAC.
Вы можете перейти на классический экран EAC только с экрана New EAC.
Щелкните поток почты на левой области. Отображается домашний экран потока почты.
Щелкните вкладку соединители.
Перейдите к маршруту экрана сообщений электронной почты.
Убедитесь, что правильный IP-адрес или FQDN указан для интеллектуального хоста в локальной Exchange организации.
Вы передаете всю исходячую почту из Exchange Online через локальном гибридном сервере
В этой конфигурации ошибка вызвана любой из следующих проблем на соединители из локальной Exchange организации в Exchange Online:
Чтобы устранить проблему, настройте выделенный соединители (от Office 365 до сервера электронной почты вашей организации), который имеет значение Connector Type On-premises* и не предназначен для любых принятых доменов. Самый простой способ устранить проблему — перезахоранить мастер гибридной конфигурации в локальной Exchange организации. Или вы можете проверить конфигурацию соединитетеля (от Office 365 до почтового сервера организации), который используется для гибридного использования, следуя следующим шагам:
Откройте Центр администрирования Microsoft 365,а затем нажмите центр администрирования Exchange (вам может > потребоваться нажать . сначала покажите все).
В EAC щелкните соединители Flow > почты.
Выберите соединитектор, используемый для гибрида, а затем нажмите кнопку Изменить значок 
. Проверьте приведенные ниже сведения.
Дополнительные сведения о маршрутизации почты в гибридных развертываниях см. в статье Маршрутизация транспорта при гибридных развертываниях Exchange.
Причины NDR 5.4.14 и что означает эта ошибка?
Возможны два варианта:
Превышены сведения о NDRs, связанных с количеством переходов
Вот некоторые коды ошибок, связанные с циклами маршрутировки почты или с плохой конфигурацией маршрутировки почты:
Hop count exceeded possible mail loop что значит
Thank you for your reply.
I think the mail loops happen at the edge server.
Yes, our SMTP domain was created as an accepted domain.
Here is the mail delivery status:
Reporting-MTA: dns;alakaimechanicalcorp.com
Received-From-MTA: dns;alakaimechanicalcorp.com
Arrival-Date: Wed, 11 Jul 2007 04:44:38 +0000
Perform a get-accepteddomains on both the Edge and the Hub and make sure they match.
If they match, then you might want to include output from a get-sendconnector as well.
I have got the same message since recently.
recepient@email.com on 15/04/2009 13:10
A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator.
I am using an exchange 2003 server as a mailbox and exchange 2007 server as a transport.
exchange 2007 send all messages to an external smart host.
also in the event log I have started to get a warning:
event id: 15001
The resource pressure changed from Normal to MediumHigh. Statistics:
Queue database and disk space («C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que») = 72% [Normal] [Normal=90% MediumHigh=92% High=94%]
Queue database logging disk space («C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\») = 74% [Normal] [Normal=95% MediumHigh=97% High=99%]
Version buckets = 63 [MediumHigh] [Normal=40 MediumHigh=60 High=100]
Private bytes = 15% [Normal] [Normal=71% MediumHigh=73% High=75%]
Physical memory load = 62% [limit is 94% to start dehydrating messages.]
Inbound mail submission from the Internet, the Pickup directory, and the Replay directory has stopped.
Loading of e-mail from the queuing database, if available, continues.
It looks like only when people attach file(s) they have got this error, if they don’t attach anything everything is working fine.
DSNs и NDRs в Exchange Server
Когда возникает проблема при доставке сообщения, Exchange отправляет отчет о недоставке отправителю сообщения. Этот отчет свидетельствует, что возникла проблема. Отчеты о недоставке содержат код, который указывает, почему сообщение не было доставлено, и возможные решения для доставки сообщения.
Сведения, включенные в отчеты о недоставке, составлены так, чтобы они были понятны и полезны как для пользователей, так и для администраторов. В некоторых случаях отправители могут самостоятельно определить и устранить проблемы (например, в случае опечатки в электронном адресе получателя). В других случаях может потребоваться, чтобы администратор устранил проблему в среде Exchange либо уведомил администраторов в домене назначения о проблемах в их средах обмена сообщениями.
Процедуры, связанные с NDRs в Exchange Server, см. в Exchange Server.
Сведения в отчетах о недоставке
Ниже показан пример отчета о недоставке.
Сведения в отчете о недоставке разделены на два указанных ниже раздела.
Раздел сведения о пользователях. В этом разделе сначала отображается и пытается объяснить (в не технических терминах) причины сбоя доставки сообщения и возможные шаги по успешной доставке сообщения.
Текст, отображаемый в этом разделе, вставляет сервер Exchange, создавший отчет о недоставке.
Если возможно, в раздел сведений для пользователя включается полное доменное имя (FQDN) сервера, отклонившего сообщение (например, mbx01.contoso.com).
Если не удалось доставить сообщение нескольким получателям, будут указаны электронный адрес и причина недоставки для каждого получателя.
Диагностические сведения для администраторов. В этом разделе содержится более подробная техническая информация, которая поможет администраторам устранить проблемы, которые привели к сбою доставки.
Основная информация в этом разделе расширенный код состояния (например, 4.4.7).
Расширенный код состояния возвращается сервером, который создал отчет о недоставке (исходный сервер, которому не удалось доставить сообщение, или сервер назначения, который отклонил сообщение).
От расширенного кода состояния зависит текст, отображаемый в разделе сведений для пользователя (Exchange не изменяет значение кода).
Вы можете использовать команды New-SystemMessage в оболочке управления Exchange для изменения текста, который отображается в разделе пользовательских сведений для данного расширенного кода состояния (включая другой текст на разных языках). Создав настраиваемые пояснения, вы можете предоставить определенный контент для своей среды, например контактные данные службы технической поддержки или ссылки на интрасеть для самостоятельного устранения неполадок. Дополнительные сведения см. в дополнительных сведениях о процедурах для DSNs и NDRs в Exchange Server.
В этом разделе также содержатся указанные ниже сведения.
Генерирующий сервер: сервер обмена сообщениями, создающий NDR. Если удаленный сервер не указан под электронным адресом отправителя, создающий сервер также будет сервером, который отклонил исходное письмо. Если доставка сообщения не удается между отправителями и получателями в Exchange организации, тот же сервер обычно отклоняет исходное сообщение и создает NDR.
Отклоненные получатели: адрес электронной почты получателя в исходном сообщении, которое не может быть доставлено. Если не удается доставить сообщение нескольким получателям, в списке будет отображен электронный адрес каждого получателя. Это поле также содержит указанные ниже вложенные поля для каждого электронного адреса.
Удаленный сервер. FQDN сервера, отклонив исходное сообщение во время передачи SMTP (доставка не удалась после того, как тело сообщения было отправлено, но до того, как сервер признал получение сообщения). Это поле не отображается в указанных ниже случаях.
Сервер, отклонивший сообщение, также создал отчет о недоставке. Такое обычно случается при недоставке сообщений от отправителей получателям в одной и той же организации Exchange.
Удаленный сервер подтвердил получение исходного сообщения, но сообщение было отклонено по другим причинам (например, из-за ограничений, связанных с контентом).
Расширенный код состояния
Ответ SMTP: текстовая строка US-ASCII, возвращаемая сервером обмена сообщениями, отклонив исходное сообщение. Обычно это краткое описание расширенного кода состояния. Эта строка не переписывается Exchange.
Исходные заглавные сообщения. Эта область содержит заглавную часть отклоненного сообщения. В этих полях заголовков могут содержаться полезные диагностические сведения (например, о прыжках сервера в пути маршрутизации сообщения либо о том, совпадает ли значение в поле Кому: с электронным адресом отклоненного получателя).
Стандартные расширенные коды состояния
: 4 указывает на временную ошибку доставки. Код 5 свидетельствует о постоянной ошибке доставки.
: RFC классифицировать значения, как это:
1. Адресная
2. Почтовый ящик (получатель)
3. Система почты (система назначения почты)
4. Сеть и маршруты
5. Протокол доставки почты
7. Безопасность или политика
: Число от 1 до 3 цифр, которое далее классифицирует ошибку.
В таблицах ниже перечислены расширенные коды состояний, которые возвращаются в отчетах о недоставке в наиболее распространенных случаях недоставки сообщений.
Сведения о расширенных кодах состояния в Microsoft 365 или Office 365 и гибридных средах см. в Exchange Online.
Hop count exceeded possible mail loop что значит
We have a hybrid environment with AD Sync
Your message to Info.domain@domain0.mail.onmicrosoft.com couldn’t be delivered.
Info.domain wasn’t found at domain0.mail.onmicrosoft.com.
user Office 365 Info.domain
Action Required Recipient
Unknown To address
How to Fix It
The address may be misspelled or may not exist. Try one or more of the following:
Send the message again following these steps: In Outlook, open this non-delivery report (NDR) and choose Send Again from the Report ribbon. In Outlook on the web, select this NDR, then select the link «To send this message again, click here.» Then delete and retype the entire recipient address. If prompted with an Auto-Complete List suggestion don’t select it. After typing the complete address, click Send.
Contact the recipient (by phone, for example) to check that the address is correct.
The recipient may have set up email forwarding to an incorrect address. Ask them to check that any forwarding they’ve set up is working correctly.
Clear the recipient Auto-Complete List in Outlook or Outlook on the web by following the steps in this article: Fix email delivery issues for error code 5.1.1 in Office 365, and then send the message again. Retype the entire recipient address before selecting Send.
Was this helpful? Send feedback to Microsoft.
More Info for Email Admins
Status code 554 5.4.14
Typically this error occurs because the recipient email address is incorrect or doesn’t exist at the destination domain. This can usually be fixed by the sender. However, sometimes the issue needs to be fixed by the recipient or the recipient’s email admin. If the steps in the How to Fix It section above don’t fix the problem, and you’re the email admin for the recipient, try one or more of the following:
For more information and tips to fix this problem, see Fix email delivery issues for error code 5.4.14 in Office 365.
Hop count exceeded possible mail loop что значит
This forum is closed. Thank you for your contributions.
Answered by:
Question
One of the user getting approval requests (patch applications) from ChangeRequest@i7.com. However, when he respond, replies are rejected – see below.
From: Microsoft Exchange
Sent: 29 September 2011 15:32
Subject: Undeliverable: RE: To install the MS patches at Saturday 11:00 PM CST to Sunday 01:00 AM CST
Delivery has failed to these recipients or distribution lists:
A problem occurred during the delivery of this message. Microsoft Exchange will not try to redeliver this message for you. Please try resending this message later, or provide the following diagnostic text to your system administrator.
The following organization rejected your message: maileme.abc.com.
Sent by Microsoft Exchange Server 2007
Diagnostic information for administrators:
Generating server: cashub2.abc.corp.local
Original message headers:
Received: from edge2.abc.com (192.168.1.1) by
cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 15:31:48 +0100
Received: from cashub2.abc.corp.local (10.10.1.1) by maileme.abc.com
(192.168.1.1) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from Edge1.abc.com (192.168.1.2) by
cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 15:16:44 +0100
Received: from cashub2.abc.corp.local (10.10.1.1) by maileme.abc.com
(192.168.1.2) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from edge2.abc.com (192.168.1.1) by
cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 15:01:39 +0100
Received: from cashub1.abc.corp.local (10.10.1.2) by maileme.abc.com
(192.168.1.1) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from Edge1.abc.com (192.168.1.2) by
cashub1.abc.corp.local (10.10.1.2) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 14:46:06 +0100
Received: from cashub1.abc.corp.local (10.10.1.2) by maileme.abc.com
(192.168.1.2) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from Edge1.abc.com (192.168.1.2) by
cashub1.abc.corp.local (10.10.1.2) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 14:30:31 +0100
Received: from cashub1.abc.corp.local (10.10.1.2) by maileme.abc.com
(192.168.1.2) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from Edge1.abc.com (192.168.1.2) by
cashub1.abc.corp.local (10.10.1.2) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 14:29:56 +0100
Received: from cashub2.abc.corp.local (10.10.1.1) by maileme.abc.com
(192.168.1.2) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from edge2.abc.com (192.168.1.1) by
cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 14:29:25 +0100
Received: from cashub1.abc.corp.local (10.10.1.2) by maileme.abc.com
(192.168.1.1) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from Edge1.abc.com (192.168.1.2) by
cashub1.abc.corp.local (10.10.1.2) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 14:29:25 +0100
Received: from cashub1.abc.corp.local (10.10.1.2) by maileme.abc.com
(192.168.1.2) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from edge2.abc.com (192.168.1.1) by
cashub1.abc.corp.local (10.10.1.2) with Microsoft SMTP Server (TLS)
id 8.2.254.0; Thu, 29 Sep 2011 14:29:24 +0100
Received: from cashub1.abc.corp.local (10.10.1.2) by maileme.abc.com
(192.168.1.1) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
Received: from MBXVS1.abc.corp.local ([fe80::ccc8:f0bb:a3f7:6237]) by
cashub1.abc.corp.local ([fe80::1df1:2e66:80b7:8a5e%10]) with mapi;
Thu, 29 Sep 2011 14:29:24 +0100
Date: Thu, 29 Sep 2011 14:27:30 +0100
Subject: RE: Business Owner Approval for: To install the MS patches at
Saturday 11:00 PM CST to Sunday 01:00 AM CST
Thread-Topic: Business Owner Approval for: To install the MS patches at
Saturday 11:00 PM CST to Sunday 01:00 AM CST
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset=»us-ascii»
Answers
You have i7.com configured as an authoritative accepted domain, meaning that Exchange is responsible for all mail to that domain. However, you have a send connector for i7.com, i7_Domino_Outbound, which sends unresolved i7.com mail somewhere else. Those two are incompatible. You might want to change accepted domain i7.com to ExternalRelay if it’s relayed through the Edge server, or InternalRelay if it’s relayed directly by the hub transport server.
Ed Crowley MVP «There are seldom good technological solutions to behavioral problems.»
Thanks to Rich as well.
All replies
Your Edge server thinks the recipient is internal to your organization or your connectors are fouled up.
Ed Crowley MVP «There are seldom good technological solutions to behavioral problems.»
Under the accepted domain «i7.com» is configured as an authoritative domain which is set to false by default. Apart from this Under the Send connector there is a send connector configured which is set to disabled; address space is configured with «1» cost and under the network tab i am seeing route mail through the following smart host is there which i a unable to ping the smart host. And Under the source servers are all CASHUB server listed.
Apart from this there is only Mail contact in exchange GAL called » changerequest@i7.com» there is no mailbox associated with this kind of email address
When we configure an internal relay domain, some or all of the recipients in this domain don’t have mailboxes in this Exchange organization as i mentioned above there is no mailbox. Mail from the Internet is relayed for this domain through Hub Transport servers in this Exchange organization. but here I am sending the mail inside the org.
As while gng through the below URL for internal mail domain in my scenario Accepted domain is there but set as a Authoritative domain as mentioned above and send connecter is also in place but seems to be disabled so while change the Authoritative to internet relay and enabling the connect will fix the issue
