5.4.14 Hop Count Exceeded Office 365
Reuquen Boyett
I had this happen to me a few weeks back after migrating a mailbox to the cloud. It created a message loop, the fix, per MS support, was to move the mailbox back, then move it back to the cloud again. This fixed the issue. Essentially on-prem thought it was a cloud mailbox, and cloud thought it was on-prem, so they kept sending it back and forth til its hop count was exceeded.
The error "554 5.4.14 Hop count exceeded - possible mail loop ATTR34" indicates that the email message has exceeded the maximum number of hops allowed to deliver an email. This can happen if there is a misconfiguration in the mail routing between your Office 365 tenant and your on-premises Exchange Server 2016.
Disable transport rules: Temporarily disable any transport rules on both your Office 365 tenant and your on-premises Exchange Server 2016 to see if they are interfering with mail delivery.
Check for mail flow connectors: Verify that you have the correct mail flow connectors configured in your Office 365 tenant. Ensure that the connectors are configured to allow relaying from your on-premises Exchange Server 2016 to your Office 365 tenant.
Review Exchange Tracking logs: Analyze the Exchange Tracking logs on both your Office 365 tenant and your on-premises Exchange Server 2016 to identify the exact point where the email message is getting stuck.
Check for IP reputation issues: If your on-premises Exchange Server 2016's IP address has a poor reputation, it could be causing emails to be blocked by external mail servers. Check your IP address on spam blacklists and take steps to improve your IP reputation if necessary.
Review sender authentication records: Ensure that your on-premises Exchange Server 2016 has the necessary sender authentication records in place, such as SPF and DKIM. These records help verify that your server is authorized to send emails on behalf of your domain.
Engage Microsoft support: If you have exhausted all of the above troubleshooting steps and the issue persists, consider contacting Microsoft support for further assistance. They may have more advanced tools and expertise to help identify and resolve the problem.
We have a UTM in use. Incoming mails reach us without any problem. Outgoing mails are partially rejected. The error message appears. "SMTP error from remote mail server after end of data: 554 5.4.14 Hop count exceeded - possible mail loop ATTR1".
Sophos UTM does not officially support O365 in a secure manner. As you have to use a host based relay (Based on IP), O365 offers a commonly used IP. There is no check, that those emails are from your Account. O365 does not support authentication relay either. Therefore the implementation is insecure and most likely not smart (Combining a on premise solution with a cloud based solution seems odd to me).
The customer has removed the old local exchange server and is now using the Office 365 cloud solution. The customer is aware that this is not the most secure solution but does not want to change it. At the moment there is a host-based relay entry with the Office 365 IP addresses. Nevertheless, there are frequent mails that are rejected due to a mail-loop. Do any other settings need to be made on the UTM?
Recently we configured our mailflow to go from Office 365 directly to our CES. Now we are seeing issues with an exceeded hop count. This occurs when CES is trying to deliver the mail to an recipient that is also in Office 365. Somehow the message is directed to our Office 365 and send again to CES. This is repeated untill the hop count reach the max.
When we send mail to a recipient that has another mailsolution, the problem doesn't occur.
What I don't understand is why our CES is delivering the message to our Office 365 and not to the Office 365 from the recipient.
We find out that a misconfigured indeed was the causing the issue. In Office 365 the connector (Inbound from my organization) was configured for checking a cerificate. Because of an error the certificate we use in CES also we hitting the connector... and the mailloop was created.
Hello, we also have this problem. And we have checked the guide at Cisco and followed it letter to letter. But we also get a loop. Can you point to more exactly were you have issues with the certificate?
Hello Maraz,
The problem was with the inbound receive connector. In some strange way mails from our Cisco configuration to a Microsoft Tenant were received in our tenant again. Our tenant 'saw' that it wasn't mail for one of our users, so it was again forwarded to Cisco. Cisco deliverd it to Microsoft 365... and see there, a loop was created
In the end we discovered that a wrong certificate was used in our inbound connector. With replacing the certificate the problem was solved.
I hope you can quickly solve you problem.
Kind regards,
Arjan
But how can the certificate play a role in this? I do not get it. We solved in another way. On the "Exchange"-side the customer configured, on the outgoing mail rule, an exception when coming from the ESA-boxes. That way we broke the loop.
We don't understand exactly how this happened. Somehow this (wrong) certificate causes that message were received in our tenant. An mail-consultant figured this out for us and solved the problem. I'm happy the problem was resolved, although I don't understand I exactly ;).
We have exactly the same issue, could you pls guide how/where we can create the exception. Our environment have 1 on-prem server, O365 which has inbound and outbound connectors towards onprem and CES. Currently we are having email loop for few domains but not for all. Kindly assist.
Hi @sunil-tiwari
The certificate was configured for the Exchange 365 connector. We didn't make an acception, but correct the configuration in Exchange 365.
Under the inbound-connector (Your org to O365) you can configure how to identity your mailserver. There we configured the subjectname of the certificate that is used by our on-premise server.
We often get questions regarding mail forwarding in Exchange Online. As you already know, Exchange Online is a shared service. We must take care that users cannot take the service down by creating mail loops. It is sometimes a little confusing for our customers that we handle this somewhat differently than in Exchange on-premises organizations. With this blog post we will give you an overview of how we handle possible mail loop scenarios and how this affects your mail flow. If you are the kind of a person that loves digging into the details, this post is for you!
You may have ended up here because you ran into a possible mail loop scenario. This blog post should help you to get a better understanding about how we handle possible mail loop scenarios, how they can occur and what to do to prevent them. I recommend checking the Fix possible mail loop insight in the Recommended for you area of the Mail flow dashboard in the Security & Compliance Center (protection.office.com) or the converged security portal (security.microsoft.com). It notifies you when a mail loop is detected in your organization.
First things first: in the cloud, the number of times a message can be redirected, forwarded, or replied to automatically is limited to 1. On-premises Exchange servers are limited to 3 (as documented here).
Mostly important for Exchange Online customers who run an on-premises Exchange organization in a Hybrid configuration: we also check if current recipient mail address is already present within an X-MS-Exchange-Inbox-Rules-Loop header for incoming messages. If that is the case, then we silently drop the message as well (not yet relevant in Exchange Online because the X-MS-Exchange-Inbox-Rules-Loop limit is currently 1 which means we drop the message if any X-MS-Exchange-Inbox-Rules-Loop header exists when the message arrives, regardless of which address the header contains).
If the message is redirected or forwarded to another tenant, we add another X-LD-Processed header containing the tenants ID (we do not replace any existing X-LD-Processed header). If the message comes from an external address and is redirected to another external address, we also stamp the Resent-From header to indicate that Exchange has touched it.
We also detect if there is a loop within the directory. You normally should not run into this kind of loop. It can occur, for example, when a mailbox has forwarding configured and ForwardingAddress refers to itself. This job is done while the message is processed. If we detect a loop here, the message will be dropped and we NDR the sender with:
This header is added when forwarding happens due to ForwardingSmtpAddress or ForwardingAddress properties set on a mailbox. In the case where the mailbox also has DeliverToMailboxAndForward:$true, when recipient A forwards a message to recipient B, there will be two copies of the message. One to the original recipient A and the other to the forwarded recipient B. The value of the header in the message to the forwarded recipient B will contain ;. The header looks like this:
The purpose of this header with ForwardingHandled value is to prevent forwarding message multiple times in scenarios like Centralized Mail Transport (aka CMT or CMC), where the message to the original recipient is routed out of the service and then back to the service. In a CMC scenario the message will be forwarded first when the message enters the service. When the message gets routed out and sent back to the service, duplicate forwarding will be prevented by looking at this header in the message. Please have a look at Scenario 5 at the end of this post to get a better understanding of the workflow in CMC scenario.
4a15465005