SMTP error 546
Not a real code — a label for a mail loop (554 5.4.6).
Updated Jul 1, 2026
SMTP 546 is not a reply code defined in RFC 5321. It is a label some tools and helpdesks use for a mail loop, which servers actually report as 554 with enhanced status 5.4.6 ("routing loop detected"). It means a message kept getting forwarded until it passed the hop limit. Fix it by finding and removing the circular forwarding rule, self-referencing alias, or auto-responder that closes the loop.
Remove the circular forwarding rule, alias, or auto-responder.
What it means
There is no 546 reply code. The permanent codes that RFC 5321 defines are 500, 501, 502, 503, 504, and 550 through 555. A few more 5xx codes come from later extension RFCs (521 and 556 from RFC 7504, 523 from RFC 5248, and 530, 534, 535, 538 from the AUTH extension RFC 4954), but 546 is in none of them. When 546 shows up in a ticket or bounce summary it is a vendor label for a mail loop. The real wire response is a 554 reply with enhanced status 5.4.6. RFC 3463 defines class X.4.6 as a routing loop that forwarded the message too many times, from either bad routing tables or a user forwarding loop. Microsoft Exchange phrases it as "554 5.4.6 Hop count exceeded - possible mail loop". So if you are chasing a 546, you are really chasing a 5.4.6 too-many-hops loop.
Common causes
Mailbox A forwards to B and B forwards back to A, directly or through a third hop. Each pass adds a Received header until the hop limit is reached and the server rejects the message.
An alias whose expansion includes its own address, or two aliases that reference each other. A common version is an address that forwards to a distribution group it is also a member of.
Two vacation or auto-reply rules that each answer the other reply. RFC 3834 auto-replies are meant to suppress this, but a misconfigured rule will not.
Wrong MX records or smarthost settings that hand mail to a server which hands it straight back. This is common in hybrid setups that mix on-premises Exchange with a cloud service.
How to fix it
- Read the bounce headers
Open the NDR and inspect the Received chain. A repeating pair of hostnames, server X to server Y to server X and around again, points straight at the loop.
- Find and break the circular forwarding
Audit forwarding rules on every mailbox in that chain and remove or redirect the one that closes the loop. Forward to a terminal mailbox, never back to a sender already in the path.
- Check aliases and distribution lists
Confirm no alias expands to include itself and that nested lists do not reference one another.
- Constrain auto-responders
Limit auto-replies to once per sender and stop them firing on mail that already carries auto-submitted or precedence headers.
- Verify MX and relay routing
Confirm MX records and any smarthost or connector settings point to the correct final destination, which matters most in hybrid mail environments.
Paired code
A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:
Common questions
Is 546 a valid SMTP reply code?
No. RFC 5321 defines no 546 reply code. It is a vendor or helpdesk label for a mail loop, which servers report as 554 with enhanced status 5.4.6 (RFC 3463).
What is the real code for an email loop?
A 554 reply paired with enhanced status 5.4.6. In Exchange you will see wording like "554 5.4.6 Hop count exceeded - possible mail loop".
How do I stop a mail loop?
Trace the Received chain in the bounce to find the repeating hostnames, then remove the forwarding rule, self-referencing alias, or auto-reply that sends mail back into the path.