This article takes an in-depth look at one of the most common causes of the following Microsoft 365 mail loop / bounce error:
554 5.4.14Hop count exceeded - possible mail loopATTR34 [SY3AUS99FT999.eop-AUS01.prod.protection.outlook.com]This error means that Microsoft is looping mail back to our servers instead of delivering it to their local user's mailbox. After a certain number of delivery attempts, Microsoft detects the loop and rejects the message.
This can be a complex problem to comprehend but the solutions don't require an in-depth understanding:
There are a variety of unrelated scenarios that can cause Microsoft 365 to trigger a mail loop.
Unfortunately, most of them are outside the scope of our documentation. But we will say that most loops are either caused by bad Connectors (on the senders' side) or by an incorrectly configured Exchange On-Premise hybrid setup.
We've also found a few Microsoft documents that may be helpful in troubleshooting other looping issues:
In some circumstances, when SpamHero delivers a "clean" message to Microsoft 365, the message is accepted for delivery but then instead of being placed in the recipient's email box, it is forwarded back to our servers a moment later. Our servers then process the message again and deliver it to Microsoft 365 and the cycle repeats until the message is rejected for "looping".
The most common cause is the sender having a bad Inbound Connector configuration
Partner Organization to their Microsoft 365 account (but that is not correct). While this approach appears to work, it also has the side-effect of causing some mail deliveries to loop and fail (see the Related questions section, below).
When Microsoft 365 receives an inbound message they inspect the sender's domain and IP address (or TLS certificate) to see whether the message came from an authorized connector. When they find a match, it is always treated as an outbound message (even if it was just accepted for an inbound delivery). And Microsoft always checks the MX record for outbound deliveries, causing the message to be sent back to SpamHero.
Related Microsoft documentation
How does message attribution work?
The problem only occurs when both the sender and recipient are hosted in the same Microsoft 365 geographic tenant region. That's because Microsoft only checks connector settings for "local" senders (based on where the message was delivered). In other words, when the sender and recipient are on different Microsft 365 networks, the sender's connector settings are not found during the delivery process.
Related Microsoft documentation
How does message attribution work?
It could be argued that the connector feature has a bug--particularly since the behavior appears to be inconsistent, depending on which Microsoft server the message was delivered to.
In reality, the connector feature is just counter-intuitive, poorly documented, and widely misunderstood.
The biggest reason we don't just call this a bug is that Microsoft's documentation never says to use the connector feature as a method of whitelisting sender IP addresses (even though their interface heavily implies that it would work).
Microsoft has a tendency to throttle and delay mail from IP addresses that exceed certain volume thresholds. The Inbound Connector feature has been widely misunderstood as the "correct" method of whitelisting sender IP addresses to guarantee fast delivery from a trusted Partner Organization. Many of the largest spam filtering services have used it incorrectly in their setup instructions. As of December 2022, the SpamHero setup instructions have been corrected but there are still many prominent anti-spam services using the "bad" connector instructions at this point.
If your SpamHero account was setup before December 2022, use the following article to fix your Microsoft 365 configuration:
Getting "Hop Count Exceeded" bounce error when sending to SpamHero user (Microsoft 365 / Office 365)
Over the years our support team received intermittent reports of a "mail loop" problem that affected a small fraction of our Microsoft 365 users (formerly Office 365 and Exchange Online before that).
The error usually seemed to start out of nowhere, without any recent configuration changes, and only affected certain sender and recipient combinations. Despite hours of troubleshooting, testing and research we were unable to reproduce the problem with our Microsoft 365 test account. As a result, we couldn't pinpoint the cause but it obviously had something to do with Microsoft's systems. So, we reluctantly asked our users to contact Microsoft tech support for help.
In late 2022 we had a breakthrough in which one of our tests finally reproduced the issue and we were able to narrow in on the exact cause. The key was that the message sender and recipient both had to be in the same Microsoft 365 geographic tenant region.
Next, we discovered that if we sent a minimalistic, plain text message "from" an email domain and IP address that matched a sender's connector then Microsoft 365 would rewrite the message body, add some headers (including a DKIM signature) and then deliver the message to any recipient (even externally).
This made us realize that the connectors feature was really designed to allow On-Premise Exchange servers to route their outbound mail mail through their Microsoft 365 account and enforce their organizational mail policies.
Using a connector to restrict which IPs are allowed to deliver mail to your Microsoft 365 account does not trigger the mail loop issue. In fact, it is the official method that Microsoft recommends for locking down your account to only accept mail from third-party services.
Yes, there is a variety of unrelated scenarios that can cause Microsoft 365 to trigger a mail loop.
Unfortunately, they are outside the scope of our documentation. We will say this though--most loops are either caused by bad Connectors (on the senders' side) or by an incorrectly configured Exchange On-Premise hybrid setup.
Related Microsoft Documentation