SMTP Error 546

Is "SMTP Error 546" a real SMTP code?

No. There is no 546 reply code in RFC 5321, the SMTP standard. The permanent (5xx) reply codes that RFC 5321 itself defines are 500, 501, 502, 503, 504, 550, 551, 552, 553, 554, and 555 — 546 is not among them. (A few other 5xx codes exist but come from later extension RFCs, not RFC 5321: 521 and 556 from RFC 7504, 523 from RFC 5248, and 530/534/535/538 from the SMTP AUTH extension RFC 4954.) If you see "546" in a tool, ticket, or bounce summary, it is a vendor or helpdesk label, not a code a mail server returned on the wire.

What people mean by "546" is a mail loop. When a message is forwarded in a circle, each relay adds a Received: header until the hop limit is hit, and the server rejects it. Mail servers typically report this with a 554 reply code plus the enhanced status code 5.4.6 defined in RFC 3463 — class X.4.6 means "A routing loop caused the message to be forwarded too many times, either because of incorrect routing tables or a user-forwarding loop." In practice (for example in Microsoft Exchange), you will see it phrased as:

554 5.4.6 Hop count exceeded - possible mail loop

So if you are debugging a "546" issue, you are really debugging a 5.4.6 / "too many hops" loop. (Note: this is distinct from the original Courier write-up's "two organizations share the same contact" framing, which describes a CRM/contact-dedup scenario, not an SMTP loop. The SMTP-level problem is circular routing, not duplicate contact records.)

What causes a mail loop (5.4.6)?

• Circular forwarding rules. Mailbox A forwards to B, and B forwards back to A (directly or via a third hop). Each pass adds a hop until the limit is exceeded.
• Aliases or distribution lists that point at themselves. An alias whose expansion includes its own address, or two aliases that reference each other. A common variant: an address that forwards to a distribution group of which it is also a member.
• Auto-responders bouncing off each other. Two vacation/auto-reply rules that each reply to the other's reply. RFC 3834 auto-replies should suppress this, but misconfigured rules don't.
• Misrouted relay / MX configuration. Incorrect MX records or relay (smarthost) settings that send mail to a server which sends it right back — common in hybrid Exchange / on-prem + cloud setups (see Microsoft's 5.4.6–5.4.20 guidance).

How do I fix the mail loop?

1. Read the bounce headers. Open the NDR/bounce and inspect the Received: chain. A repeating pair of hostnames (server X to server Y to server X …) pinpoints the loop.
2. 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 in the path.
3. Check aliases and distribution lists. Make sure no alias expands to include itself and that nested lists don't reference each other.
4. Constrain auto-responders. Limit auto-replies to once per sender, and ensure they don't fire on mail that already carries auto-submitted/precedence headers.
5. Verify MX and relay routing. Confirm MX records and any smarthost/connector settings route to the correct final destination, especially in hybrid mail environments.