// 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
mydestinationor 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
- Open the bounce and read the headers of the returned message. Read the
Receivedlines 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. - 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. - On Postfix, check that the domain is declared as local or virtual:
postconf mydestination virtual_mailbox_domains relay_domains postconf -n | grep -i transport
- 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
- Break forwarding circles. Keep forwarding in one direction only, and remove it from the old mailbox once a migration is done.
- Make one server authoritative. On Postfix, add the domain to
mydestination(local users) orvirtual_mailbox_domains(virtual users), never to both, thensystemctl reload postfix. In Exchange Online, set the domain to Authoritative unless some mailboxes really live elsewhere. - 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.
- 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.
- 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.
- 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
- No SPF record on your domainYour domain does not say which servers may send email for it. Add one TXT record and receivers can tell your real emails from fakes.
- SPF error: too many DNS lookups (permerror)SPF allows at most 10 DNS lookups. Above that, the whole record breaks and receivers treat it as invalid. Here is how to slim it down.
- Several SPF records on one domainA domain must have only one SPF record. With two or more, SPF breaks for every email. Merge them into a single line.
- SPF fails: the sending server is not authorizedYour domain has an SPF record, but the server that sent your email is not in it. Find which service sent the email and add it.
- No DKIM signature on your emailsDKIM adds a digital signature that proves an email really comes from your domain. Turn it on in your email provider and publish its key in DNS.