SMTP Error 446

What is SMTP Error 446?

"SMTP Error 446" is the label many mail tools, control panels, and glossaries attach to a "maximum hop count exceeded" condition: a message was rejected because it passed through too many mail servers (hops) on its way to the recipient, which almost always means it was caught in a mail loop.

One thing to be clear about up front: 446 is not a real SMTP reply code. RFC 5321 — the SMTP standard — does not define a 446 reply, and it does not appear in the standard list of SMTP return codes. RFC 5321 §6.3 only describes detecting looping in the mail system by counting Received: header fields; it sets no numeric hop limit you can rely on across systems and assigns no reply code to that condition.

So when you see "446," treat it as a human-readable name for the hop-count/loop problem, and look at the real bounce codes your mail system actually emits.

What are the real codes for "hop count exceeded"?

The relevant enhanced status code is X.4.6 — "Routing loop detected" (RFC 3463). In practice you'll see it returned by real mail servers as a permanent 554 reply with a 5.4.x enhanced code. Per Microsoft's Exchange Online NDR guidance, the messages you'll actually see are:

• 554 5.4.6 Hop count exceeded - possible mail loop — always generated by on-premises Exchange Server (typically a hybrid setup).
• 5.4.14 Hop count exceeded - possible mail loop ATTR34 — always generated by Exchange Online. Exchange Online typically wraps this in a 554 (or similar 5xx) envelope code, so in an actual NDR you'll usually see it delivered as something like 554 5.4.14 Hop count exceeded - possible mail loop ATTR34.

A note on classification: RFC 3463 itself describes the bare X.4.6 detail code as a persistent transient error. But the way mail servers actually deliver this condition — Exchange in particular — is as a permanent failure (a 554 reply carrying a 5.4.x enhanced code). So in the real world this is a permanent bounce, and the common "446 is transient, just wait and retry" advice is wrong for it: retrying without fixing the loop will keep bouncing.

What causes it?

A Received: header is stamped each time a server handles the message; when that count crosses a server's configured ceiling, delivery is aborted to stop an infinite loop. The underlying cause is almost always a routing loop, per RFC 3463 X.4.6: "a routing loop caused the message to be forwarded too many times, either because of incorrect routing tables or a user-forwarding loop." Common triggers:

• A user/server forwarding loop — A forwards to B and B forwards back to A, or an auto-forward rule points at an address that loops home.
• MX / accepted-domain misconfiguration — the recipient domain isn't configured as an authoritative accepted domain, so the message ricochets.
• Hybrid connector misconfiguration (Exchange/Microsoft 365) — e.g. the inbound connector uses DNS routing instead of smart-host routing, or the outbound on-premises connector is missing or scoped to specific domains.

How do I fix SMTP Error 446 (hop count exceeded)?

The fix is to find and break the loop — not to raise a hop limit (most platforms don't expose one, and increasing it just delays the same bounce):

1. Read the bounce / NDR carefully. Confirm the real code (554 5.4.6 vs 5.4.14) — it tells you whether the loop is on-premises or in Exchange Online.
2. Inspect the Received: headers of a looping message. Repeating server names show you exactly which two hosts are bouncing it back and forth.
3. Audit forwarding rules — mailbox forwarding, transport/mail-flow rules, distribution-list memberships, and any aliases. Remove the rule that sends mail back toward its source.
4. Verify the recipient domain is an authoritative accepted domain on the receiving system. In Microsoft 365, see Manage accepted domains in Exchange Online.
5. Check your MX records and connectors. In a hybrid Exchange deployment, the simplest fix is to rerun the Hybrid Configuration Wizard so the connectors use correct smart-host routing; otherwise verify the inbound connector points at the right smart host and the on-premises outbound connector isn't scoped to specific domains.
6. If you relay through a third-party provider (SendGrid, Amazon SES, Mailgun, etc.), make sure you aren't relaying mail for a domain back to a server that relays it to you — open a support ticket with the message headers if the loop isn't obvious.

What about the "verify your domains" and "hop count 10–256" advice?

Verifying/owning your sending domains is good hygiene and can resolve accepted-domain routing problems, but on its own it does not "fix 446." And there is no universal "set the hop count between 10 and 256" knob — that figure isn't from RFC 5321 (which sets no enforceable limit) and most hosted platforms don't let you change it. Focus on eliminating the loop; the count takes care of itself.