Error too many hops

Email "error: too many hops" can happen due to misconfigured mail server, improper spam filter settings, and more. Here are the steps to fix this problem.

It’s really frustrating when you can’t send emails on time.

In most of the cases, senders receive a bounce back message explaining the reason, and most of them are self explaining, but some of them may be unclear.

One such bounce back message is “error: too many hops“.

What does hop mean? Where is the problem? This creates lot of such questions in your mind.

At Bobcares, we help server owners resolve such complex email errors as part of our Server Support Services for web hosts.

Today, we’ll discuss the top 4 reasons for this error and how we fix them.

‘Error: too many hops’ – What this means?

Before we go ahead, let’s get an idea of this error first.

In a normal email delivery mail is sent from the sender to the sender MX, to the receiving MX, and finally to the receiver. But,  there may sometimes be additional servers such as Gateway, AntiSpam, etc. between the sender and the recipient.

So, when you send an email over a network, it will pass through several computers before it reaches the destination. Each transfer between these computers is called a hop.

The “error: too many hops” means that there are too many transfers between the sender and the recipient. So, one of the intermediate servers rejects the message to prevent a potential mail loop.

In most cases, our Hosting Engineers analyze the Non Delivery Report (bounce back) to determine the root cause of the issue.

‘Error: too many hops’ – Causes and Fixes

Let’s now see the main reasons for this error and how our Server Support Engineers fix them.

1) Incorrect forwarders for email accounts

This is one of the common mistakes made by server owners. Most often, users set forwarding emails from one mailbox to another and vice versa.

In other words, users have 2 accounts and mistakenly set these 2 accounts forwarding to each other.

That is, message from first account is forwarded to the second account, and second one to the first, and so on.

As a result, this will create an endless loop, and finally message is returned to the sender.

Solution

In these cases, our Support Engineers analyze the email logs and email delivery route to identify email delivery problems.

For example, in cPanel servers, we use the Track Delivery option to check the email delivery route.

In addition to that, we manually check and delete redundant email forwarders for the domains.

2) Incorrect MX records

This usually happens after hosting account migrations. After migration to the new server, it’s important to update the MX records and SMTP routing information for the emails to work.

But, we’ve seen cases where these changes haven’t done properly. As a result, email loops between the old and new servers.

Similarly, duplicate MX records or MX records with same priority can lead to mail delivery loops.

Solution

Here, our Support Engineers first verify the domain’s MX record using the below command.

dig domain.com MX

If we find any MX records with same priority, we change them to a different priority and it should be fine.

Similarly in case of migrations, we confirm that the MX record and SMTP settings of the domain point to the new server.

At Bobcares, our Migration Specialists always keep a pre-migration checklist and post-migration checklist to avoid such problems after migration.

3) Misconfigured email server

During server migration, the mail servers and the mail routing tables may need to be re-configured with new IPs.

Misconfigured mail servers and mail routing tables can keep mails connecting back to the sender, thereby creating an email loop.

For example, server owners mistakenly set the parameter “mydestination = localhost” in the Postfix configuration file. So, Postfix thinks it should only handle mail addressed to the domain localhost.

As a result, external mails are routed on the server itself, and consequently email bounces with “error: too many hops“.

Similarly, in cPanel servers, the /etc/localdomains and /etc/remotedomains are checked to identify whether the emails are hosted locally or remotely. So, a wrong entry in this file can create infinite email loop.

Solution

We check the server error logs, and if any misconfiguration noted in the mail server settings, we’ll immediately correct them.

For example, we check the postfix configuration file and confirm that the destination parameter values are set correctly.

mydestination = $myhostname localhost.$mydomain localhost

Similarly, in cPanel servers, we check whether the domain uses remote MX. If so, we remove the MX entry on the server and add the domain to /etc/remotedomains file.

[Trouble with Misconfigured Mail server? One of our Server Administrators can assist you here. We are available 24/7.]

4) Misconfigured Antispam server

Some web hosts put separate anti spam servers to improve email filtering.

But, it can fail if the outgoing mail route or domain DNS settings are not properly configured. As a result, email loops back between the sender and the Antispam server.

Solution

In this case, our Hosting Engineers analyze the SMTP logs and email headers to understand the origin of the issue.

If we find any configuration problems on the Antispam server such as incorrect SMTP route, DNS settings of the domain, etc. we’ll correct it immediately.

[Need help in fixing this error? Click here to have a Server Expert look at your problem.]

Conclusion

In short, “error: too many hops” can occur due to wrong mail server configuration, improper spam filter settings, and more. Today, we’ve discussed the top 4 reasons for this error and how our Server Support Engineers fix them.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

SEE SERVER ADMIN PLANS

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

  • #1

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… :)

Last edited by a moderator: Jan 27, 2022

cPRex


  • #2

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.

  • #3

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.

Добрый день. 

Периодически не получается отправить письмо на определенный домен, в ответ получаю ниже. 

Никак не могу понять, в чем дело

Диагностические сведения для администраторов:

Формирующий сервер: mx1.auchan.ru

k.konunova@auchan.ru
#< #5.4.6 SMTP; 554 5.4.6 Too many hops> #SMTP#

Исходные заголовки сообщения:

Return-Path: <bav@myDomain.com>
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com
 [209.85.215.70])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4xFiJ012931	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:59:27 +0400
Received: by mail-lf0-f70.google.com with SMTP id b14so1759247lfg.6        for
 <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:59:15 -0800 (PST)
X-Gm-Message-State: ABUngvcBLf0thh31WyKCCd6H8ZSWOYnojzk7GoGoqqzRxetFfJN691J+Rd7ZuwQiWHvwFshJCw1timLnm4cSj2ezetom0NHQM7cU83iRPQN4iO4+a26WtZb/GBLqkTdU3vrL
X-Received: by 10.25.135.130 with SMTP id j124mr640883lfd.88.1478840355521;
        Thu, 10 Nov 2016 20:59:15 -0800 (PST)
X-Received: by 10.25.135.130 with SMTP id j124mr640878lfd.88.1478840355322;
        Thu, 10 Nov 2016 20:59:15 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id h26si4685276lji.97.2016.11.10.20.59.15
        for <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA
 bits=128/128);        Thu, 10 Nov 2016 20:59:15 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.69 as permitted sender) client-ip=209.85.215.69;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.69 as permitted sender) smtp.mailfrom=bav@myDomain.com
Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com
 [209.85.215.69])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4x0bQ012749	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:59:03 +0400
Received: by mail-lf0-f69.google.com with SMTP id b14so1758116lfg.6        for
 <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:59:00 -0800 (PST)
X-Received: by 10.25.205.17 with SMTP id d17mr605323lfg.29.1478840339943;
        Thu, 10 Nov 2016 20:58:59 -0800 (PST)
X-Received: by 10.25.205.17 with SMTP id d17mr605315lfg.29.1478840339740;
        Thu, 10 Nov 2016 20:58:59 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id b84si4668835lfd.285.2016.11.10.20.58.59
        for <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA
 bits=128/128);        Thu, 10 Nov 2016 20:58:59 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.70 as permitted sender) client-ip=209.85.215.70;
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com
 [209.85.215.70])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4wbOb012639	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:58:46 +0400
Received: by mail-lf0-f70.google.com with SMTP id c13so1782971lfg.4        for
 <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:58:37 -0800 (PST)
X-Received: by 10.25.34.70 with SMTP id i67mr434700lfi.155.1478840317548;
        Thu, 10 Nov 2016 20:58:37 -0800 (PST)
X-Received: by 10.25.34.70 with SMTP id i67mr434695lfi.155.1478840317341;
        Thu, 10 Nov 2016 20:58:37 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id 26si2980991lji.48.2016.11.10.20.58.37        for
 <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA bits=128/128);
        Thu, 10 Nov 2016 20:58:37 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.71 as permitted sender) client-ip=209.85.215.71;
Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com
 [209.85.215.71])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4wNom012558	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:58:23 +0400
Received: by mail-lf0-f71.google.com with SMTP id b14so1755457lfg.6        for
 <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:58:23 -0800 (PST)
X-Received: by 10.25.199.198 with SMTP id x189mr610986lff.164.1478840303031;
        Thu, 10 Nov 2016 20:58:23 -0800 (PST)
X-Received: by 10.25.199.198 with SMTP id x189mr610982lff.164.1478840302817;
        Thu, 10 Nov 2016 20:58:22 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id 71si4677913lft.227.2016.11.10.20.58.22
        for <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA
 bits=128/128);        Thu, 10 Nov 2016 20:58:22 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.69 as permitted sender) client-ip=209.85.215.69;
Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com
 [209.85.215.69])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4w6W2012491	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:58:09 +0400
Received: by mail-lf0-f69.google.com with SMTP id o141so1738076lff.7
        for <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:58:06 -0800 (PST)
X-Received: by 10.25.209.211 with SMTP id i202mr584553lfg.117.1478840286116;
        Thu, 10 Nov 2016 20:58:06 -0800 (PST)
X-Received: by 10.25.209.211 with SMTP id i202mr584545lfg.117.1478840285899;
        Thu, 10 Nov 2016 20:58:05 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id d191si4673758lfg.310.2016.11.10.20.58.05
        for <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA
 bits=128/128);        Thu, 10 Nov 2016 20:58:05 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.70 as permitted sender) client-ip=209.85.215.70;
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com
 [209.85.215.70])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4vkDf012310	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:57:51 +0400
Received: by mail-lf0-f70.google.com with SMTP id t196so1782350lff.3
        for <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:57:46 -0800 (PST)
X-Received: by 10.25.99.12 with SMTP id x12mr479671lfb.174.1478840266321;
        Thu, 10 Nov 2016 20:57:46 -0800 (PST)
X-Received: by 10.25.99.12 with SMTP id x12mr479669lfb.174.1478840266121;
        Thu, 10 Nov 2016 20:57:46 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id i198si4697019lfg.86.2016.11.10.20.57.45
        for <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA
 bits=128/128);        Thu, 10 Nov 2016 20:57:46 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.70 as permitted sender) client-ip=209.85.215.70;
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com
 [209.85.215.70])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4vVnV012225	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:57:31 +0400
Received: by mail-lf0-f70.google.com with SMTP id h201so1759736lfg.5
        for <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:57:31 -0800 (PST)
X-Received: by 10.25.33.131 with SMTP id h125mr449019lfh.49.1478840251156;
        Thu, 10 Nov 2016 20:57:31 -0800 (PST)
X-Received: by 10.25.33.131 with SMTP id h125mr449016lfh.49.1478840250959;
        Thu, 10 Nov 2016 20:57:30 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id p66si4680703lfp.207.2016.11.10.20.57.30
        for <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA
 bits=128/128);        Thu, 10 Nov 2016 20:57:30 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 209.85.215.69 as permitted sender) client-ip=209.85.215.69;
Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com
 [209.85.215.69])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id
 uAB4vChf012166	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:57:17 +0400
Received: by mail-lf0-f69.google.com with SMTP id l68so1814729lfb.1        for
 <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:57:12 -0800 (PST)
X-Received: by 10.25.29.8 with SMTP id d8mr483544lfd.18.1478840232195;
        Thu, 10 Nov 2016 20:57:12 -0800 (PST)
X-Received: by 10.25.29.8 with SMTP id d8mr483540lfd.18.1478840232000;
        Thu, 10 Nov 2016 20:57:12 -0800 (PST)
Received: from mx1.auchan.ru (mx1.auchan.ru. [195.16.40.52])        by
 mx.google.com with ESMTPS id 91si4701761lfr.76.2016.11.10.20.57.11        for
 <k.konunova@auchan.ru>        (version=TLS1 cipher=AES128-SHA bits=128/128);
        Thu, 10 Nov 2016 20:57:11 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning bav@myDomain.com does not designate 74.125.82.69 as permitted sender) client-ip=74.125.82.69;
Received: from mail-wm0-f69.google.com (mail-wm0-f69.google.com
 [74.125.82.69])	by mx1.auchan.ru (8.13.1/8.13.1) with ESMTP id uAB4uWUb011829
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for
 <k.konunova@auchan.ru>; Fri, 11 Nov 2016 08:56:56 +0400
Received: by mail-wm0-f69.google.com with SMTP id r68so20016491wmd.0
        for <k.konunova@auchan.ru>; Thu, 10 Nov 2016 20:56:32 -0800 (PST)
X-Received: by 10.194.55.234 with SMTP id v10mr7335000wjp.10.1478840192430;
        Thu, 10 Nov 2016 20:56:32 -0800 (PST)
X-Received: by 10.194.55.234 with SMTP id v10mr7334994wjp.10.1478840192306;
        Thu, 10 Nov 2016 20:56:32 -0800 (PST)
Received: from mail.myDomain.com (mail.myDomain.com. [212.113.230.58])        by
 mx.google.com with ESMTPS id wg6si8477394wjb.146.2016.11.10.20.56.32
        for <k.konunova@auchan.ru>        (version=TLS1
 cipher=ECDHE-RSA-AES128-SHA bits=128/128);        Thu, 10 Nov 2016 20:56:32
 -0800 (PST)
Received-SPF: pass (google.com: domain of bav@myDomain.com designates 212.113.230.58 as permitted sender) client-ip=212.113.230.58;
Received: from mail.myDomain.com ([::1]) by mail.myDomain.com ([::1]) with mapi id
 14.03.0123.003; Fri, 11 Nov 2016 09:55:38 +0500
From: =?windows-1251?B?weXr/+XiIMDt5PDl6SDC4Ovl8Pzl4uj3?= <bav@myDomain.com>
To: "KSENIYA KONUNOVA (k.konunova@auchan.ru)" <k.konunova@auchan.ru>
Subject: =?windows-1251?B?Rlc6IO3l7vL04Ory8/Du4uroIM7OziDV6+Dk7uru7OHo7eDyILkzIDUx?=
 =?windows-1251?Q?08?=
Thread-Topic: =?windows-1251?B?7eXu8vTg6vLz8O7i6uggzs7OINXr4OTu6u7s4ejt4PIguTMgNTEwOA==?=
Thread-Index: AdI7y35cJYax9NMjQDS7mGLvx6lChQABKThgAAHkViA=
Date: Fri, 11 Nov 2016 04:55:37 +0000
Message-ID: <3104CFD9712F8E44883D9B2851BD9132622307FC@mail.myDomain.com>
Accept-Language: ru-RU, en-US
Content-Language: ru-RU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.246.155]
Content-Type: multipart/alternative;
	boundary="_000_3104CFD9712F8E44883D9B2851BD9132622307FCmailxk3ru_"
MIME-Version: 1.0
X-Spam-Score: 2.036 (**) AWL,DNS_FROM_AHBL_RHSBL,HTML_MESSAGE,SUBJ_ALL_CAPS
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200
X-Scanned-By: MIMEDefang 2.68 on 10.156.1.200

  • Изменен тип

    30 ноября 2016 г. 6:41
    нет активности со стороны задающего

Понравилась статья? Поделить с друзьями:
  • Error the update operation document must contain atomic operators
  • Error syntax error at or near using
  • Error syntax error at or near serial
  • Error syntax error at or near second
  • Error syntax error at or near return