Possible fix to email delivery error "554 5.4.0 Error: too many hops"

[eitanc]

Hello,

I am posting this to share a fix I found, which may help others and possibly encourage cPanel to look into this and possibly find how to prevent the root cause in advance.

I use in my domains the "Email Routing" option of "Local Mail Exchanger".

Sometimes, after a period of time that all was working well (not during the initial config try-and-error cycle) I get an error email report message (I don't recall if incoming or outgoing delivery, today it was incoming) error of "554 5.4.0 Error: too many hops".

A work-like-charm fix that I don't recall how I found and I don't know why it works - is in the cPanel UI, to go to the "Email Routing" section (Email Routing | cPanel & WHM Documentation) and to "refresh" the method by changing it from "Local Mail Exchanger" to "Automatically Detect Configuration" (I guess the other options of "Backup" and "Remote" will work as well, as they are only temporary, but I didn't try them), saving this change, and then selecting the "Local" option again and saving this change. That's all.

I hope this will help someone, sometime...

 

[cPRex]

Hey there! I wouldn't expect this option to have any control on the number of hops a message takes to be delivered. The Local and Remote settings inside cPanel >> Email Routing just tell the local machine to either look toward external DNS for a domain, or not, but the number of hops a message takes is completely controlled by the network.

The most likely explanation for the behavior you saw was that the previous route timed out, and the next time you tried to send the message a new route was established that worked well. The Email Routing change was likely just a coincidence.

 

[eitanc]

Hey there! I wouldn't expect this option to have any control on the number of hops a message takes to be delivered. The Local and Remote settings inside cPanel >> Email Routing just tell the local machine to either look toward external DNS for a domain, or not, but the number of hops a message takes is completely controlled by the network.

The most likely explanation for the behavior you saw was that the previous route timed out, and the next time you tried to send the message a new route was established that worked well. The Email Routing change was likely just a coincidence.

Hi, it is no coincidence. It is a very systematic solution that simply works, without any config change around the time of the issue. I don't know what is the technical reason for this, but it probably does refresh some "stuck" email routing situation.