SMTP 554 5.4.6 too many hops: find the forwarding loop

554 5.4.6 Too many hops means a message has been relayed between mail servers more times than

the hop limit permits, and the MTA that noticed stopped it to prevent an infinite loop. It is a

5xx, so it is permanent - but unlike most permanent failures, the fault is in **routing

configuration you control**, not in the recipient and not in your reputation.

The useful property of this error is that the evidence is inside the message. Hop counting is done

by counting Received: header fields, so a bounced message is a complete record of the loop.

How hop counting works

RFC 5321 requires every MTA to prepend a Received: header. It also tells implementations to

count those headers and refuse a message that has accumulated too many, precisely because a

forwarding loop would otherwise circulate forever. The limit is per-MTA and configurable: Postfix

defaults hopcount_limit to 50, Sendmail's MaxHopCount defaults to 25, and Exchange and the

large cloud providers enforce their own ceilings.

A normal message has three to eight Received: headers. Thirty is not a busy route; it is a loop.

Read the bounce

Reporting-MTA: dns; mail.yourdomain.com
Action: failed
Status: 5.4.6
Diagnostic-Code: smtp; 554 5.4.6 Too many hops

Received: from mail.yourdomain.com (mail.yourdomain.com [203.0.113.10])
        by relay.partner.example (Postfix) id 4A1; Tue, 14 Oct 2026 09:14:02 +0000
Received: from relay.partner.example (relay.partner.example [198.51.100.7])
        by mail.yourdomain.com (Postfix) id 9C2; Tue, 14 Oct 2026 09:14:01 +0000
Received: from mail.yourdomain.com (mail.yourdomain.com [203.0.113.10])
        by relay.partner.example (Postfix) id 4A0; Tue, 14 Oct 2026 09:14:00 +0000
Received: from relay.partner.example (relay.partner.example [198.51.100.7])
        by mail.yourdomain.com (Postfix) id 9C1; Tue, 14 Oct 2026 09:13:59 +0000

Two hostnames, alternating, one second apart. That is the loop, and the two hosts named in it are

the two places to look. You do not need to guess.

The five causes

1. Mutual forwarding. A mailbox on server A forwards to an address on server B, and that

address forwards back to A - often because someone set up a forward years ago and nobody

removed it when the mailbox was recreated. This is the most common cause by a wide margin.

1. A forward to an alias that resolves back to itself. sales@ forwards to a distribution

list that contains sales@. Each pass adds two hops.

1. Split-domain routing between on-premises and cloud. During a migration, the on-premises

Exchange thinks the mailbox is in the cloud, and the cloud tenant thinks it is still

on-premises. Each side dutifully forwards to the other. This is the classic hybrid-migration

version of the bug.

1. MX records pointing at a host that does not consider itself the final destination. The host

receives the message, consults its own routing, sees the MX for the domain is itself, and

relays to itself. Exim phrases the related condition as `lowest numbered MX record points to

local host`.

1. A smart host that routes back through the sender. An outbound relay configured to send

everything to a gateway, where the gateway's own outbound route points back at the relay.

Diagnosing it in five minutes

1. Count the `Received:` headers in the bounced message. Over about fifteen, assume a loop.
2. Find the repeated hostname pair. Two names alternating is the loop; the timestamps confirm

it by being seconds apart.

1. Check forwarding rules on both named hosts. Mailbox-level forwards, alias files, and

transport maps. On Exchange, check both ForwardingAddress and ForwardingSmtpAddress - they

are separate settings and only one is visible in the admin centre by default.

1. Verify DNS with dig MX yourdomain.com +short and compare it against what each server

believes. A stale local domain entry on a server whose MX now points elsewhere produces cause

four.

1. Check SPF and DKIM while you are there. Forwarding breaks SPF, because the forwarding host

is not in your SPF record. A loop that eventually delivers via an unexpected path often arrives

failing authentication even after you fix the hop count, so confirm DKIM survives the route.

The ordered fix

1. Remove the forward on whichever side is the duplicate. One of the two is always redundant.
2. If forwarding is genuinely needed in both directions for different addresses, make the

addresses distinct - never have two addresses that each forward to the other.

1. For hybrid Exchange, correct the remote routing address and the mail-enabled user objects so

each side agrees where the mailbox lives.

1. Where a server must relay for a domain it does not host, remove that domain from its local

destination list so it stops treating itself as the endpoint.

1. Re-send one test message and count the Received: headers in the delivered copy. Three to

eight is healthy.

What not to do

• Do not raise the hop limit. It is a safety valve. Raising it converts a loop that fails in

seconds into a loop that circulates fifty copies of every message before failing, and on a busy

server that is an outage.

• Do not add another forward to work around the broken one. Each additional forward adds hops

and makes the loop harder to read.

• Do not suppress the recipient. The address is almost certainly valid; the route to it is

broken.

• Do not retry the message. 554 is permanent, and until the route is fixed every retry

reproduces the loop.

• Do not assume it is the recipient's configuration. It can be - a recipient with a

misconfigured forward will loop your mail back at you - but the Received: headers name the

guilty hosts, so check them before raising a ticket with someone else.

MailPilot's warm-up traffic travels between real connected mailboxes rather than through

forwarding chains, so routing loops surface immediately as a send that never lands rather than as

a slow reputation decline. Its SPF, DKIM and DMARC checks are also the fastest way to confirm that

a route you have just repaired still authenticates end to end.