all guides

// how to fix

Bounce "554 5.4.6 Hop count exceeded - possible mail loop": fix it

Email bounced with 5.4.6 or 5.4.14 hop count exceeded? The message is going round in circles between servers. Find the loop and break it.

What it means

Each time an email passes through a server, that server adds a Received line to the headers. This is a "hop". If a message collects too many hops, servers assume it is going round in a circle (a mail loop) and stop it with a bounce. It usually looks like this:

554 5.4.6 Hop count exceeded - possible mail loop

Microsoft 365 uses 554 5.4.14 Hop count exceeded - possible mail loop, sometimes followed by ATTR1 or ATTR34. According to Microsoft, 5.4.14 comes from Exchange Online and 5.4.6 usually from an on-premises Exchange server. Postfix also uses status 5.4.6, for example with the text mail for yourdomain.com loops back to myself or mail forwarding loop for user@yourdomain.com.

Why it happens

  • Forwarding in a circle. Address A forwards to B, and B forwards back to A (or through C). Common after setting up forwarding on both an old and a new mailbox.
  • MX points to a server that does not know the domain. The server receives the mail, does not consider itself the final destination, looks up the MX and sends it to… itself. On Postfix, this happens when the domain is missing from mydestination or the virtual domain settings.
  • Two systems each think the other has the mailbox. Typical in hybrid Exchange or during a migration: on-premises sends to the cloud, the cloud sends back on-premises.
  • Wrong connectors or gateways. A filtering gateway sends mail to Microsoft 365, and a connector or rule sends it back to the gateway.
  • Accepted domain set to relay. In Exchange Online, a domain set as "internal relay" forwards unknown recipients to another server, which sends them back.
  • Auto-replies and forwarding rules that answer each other.

How to check

  1. Open the bounce and read the headers of the returned message. Read the Received lines from the bottom up. You will see the same two or three server names repeating: they form the loop. Our guide to reading email headers explains each line.
  2. Check the MX records of the recipient domain on the domain scanner, or with dig MX yourdomain.com +short. They must point to the server or service that really hosts the mailboxes. See also MX record pointing to a CNAME or IP.
  3. On Postfix, check that the domain is declared as local or virtual:
    postconf mydestination virtual_mailbox_domains relay_domains
    postconf -n | grep -i transport
  4. On Microsoft 365, in Exchange Online PowerShell:
    Get-AcceptedDomain | Format-Table Name,DomainType
    Get-Mailbox user@yourdomain.com | Format-List ForwardingAddress,ForwardingSmtpAddress
    Get-InboxRule -Mailbox user@yourdomain.com
    Get-InboundConnector; Get-OutboundConnector
    Message trace in the Exchange admin center also shows the path a message took.

How to fix it

  1. Break forwarding circles. Keep forwarding in one direction only, and remove it from the old mailbox once a migration is done.
  2. Make one server authoritative. On Postfix, add the domain to mydestination (local users) or virtual_mailbox_domains (virtual users), never to both, then systemctl reload postfix. In Exchange Online, set the domain to Authoritative unless some mailboxes really live elsewhere.
  3. Fix the MX so it points to the system that hosts the mailboxes. After a provider change, update it at your DNS host and remove old entries.
  4. Fix hybrid routing. Make sure each mailbox exists in one place only (a mailbox in the cloud must be a "remote mailbox" on-premises, not a second mailbox), and that connectors only send to the other side for recipients that really live there.
  5. Review gateways. If a filtering service sits in front of your mailboxes, the inbound path (gateway → mailbox) and outbound path (mailbox → gateway → internet) must not send the same message back.
  6. Stop auto-reply wars with rules that do not reply to automated messages.

Check that it is fixed

Send a new message to the address that looped and check that it arrives with only a few Received lines. If you changed DNS, allow time for propagation. Then send a test from that domain to the address on the Delivmail home page to confirm outgoing mail and authentication are also fine after the routing change.

Check that it is fixed

DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.

Related guides