SMTP error 4.4.6 Routing loop detected

What SMTP error 4.4.6 means

The message went round in a circle. Two systems each believed the other was responsible for the address and kept handing it back, until one of them counted the hops and stopped it. The registry allows this only as a transient failure, so the message is held and retried rather than bounced immediately, but nothing improves until the forwarding arrangement is corrected. A forward, an alias or a pair of relay rules pointing at each other cause almost all of them.

Network and routing status
Sent by Whichever system counted the hops and stopped the message circulating
Occasional

What SMTP error 4.4.6 Routing loop detected actually means

Every system that handles a message stamps a header on it, and every system counts those stamps. Once the count passes the limit that platform enforces, it stops the message rather than let it circulate for ever, and that is what produces this report. Two things follow. First, it is a configuration fault between two systems rather than a delivery failure at a destination, so it will repeat for every message to that address until somebody changes a setting. Second, because the registry fixes this as transient only, the sending system holds the message and keeps trying: it does not bounce at the moment the loop is spotted, it bounces later when the message becomes too old to keep.

A routing loop caused the message to be forwarded too many times, either because of incorrect routing tables or a user- forwarding loop. This is useful only as a persistent transient error.
— RFC 3463

How 4.4.6 appears in a bounce

The leading 4 is the server's verdict rather than part of the code's identity: it marks this as a temporary failure, which means the sending server is still retrying.

RFC 3463 is explicit about which verdicts this code can carry: “This is useful only as a persistent transient error.”

What causes SMTP error 4.4.6 on a business phone system

A mailbox forward pointing at an address that comes backA user forwards to an external address which turns out to be an alias routing into the same tenant. Each system does exactly what it was told, and the message shuttles between them until a hop limit intervenes.
Two organisations both relaying the same domain to each otherCommon after a merger or an acquisition, where both tenants keep the shared domain configured to pass mail onward to the other. Neither will accept final responsibility for an address that no longer has a mailbox anywhere.
A migration left half configuredThe old on-premise server relays unknown recipients to the tenant, while the tenant still has a connector sending that domain back to on-premise. Mail for anyone whose mailbox has already moved is fine; anyone missed by the migration loops.
A distribution group containing its own addressEither directly, or through a nested group several levels down that expands back to the parent. The expansion repeats on every pass and the message multiplies as well as circulating.
A mail contact whose external address resolves locallyA contact created to point at an outside supplier, where the address on it belongs to a domain the same system is authoritative for, delivers the message straight back to itself.

How to fix SMTP error 4.4.6

Read the received headers of a looping message from the bottom upThe two hostnames that alternate down the list name the pair of systems handing the message back and forth. This one step usually identifies the fault before you have opened any admin console.
Check forwarding on the recipient, including inbox rulesMailbox forwarding set by an administrator is easy to spot. A rule the user created inside Outlook is not shown on the mailbox settings page at all, and it is the version that catches people out.
Compare how both systems classify the shared domainOnly one system can be the final destination for a domain. Where both are set to pass mail on, decide which holds the mailboxes and set the other to relay to it, not the other way round as well.
Remove connectors left over from a migrationA connector that made sense during coexistence becomes a loop the moment the other side starts relaying back. Once every mailbox has moved, the on-premise route should be taken out rather than left in place in case it is needed.
Expand groups fully before ruling them outList the complete membership including nested groups and look for the group's own address. Systems will happily accept a group that contains itself and only discover the consequence at delivery time.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 4.4.6

Will the sender be told, or does the message just vanish?

They will be told eventually. Because the code is transient the message stays queued and is retried, so the sender may first see a delay notification. It only turns into a proper bounce once the message has been held too long, which is reported as delivery time expired rather than as a loop.

Why does it affect one address when everyone else is fine?

Because loops are created per recipient, not per domain. A single mailbox with a forward pointing somewhere that routes back will loop while every colleague on the same system receives normally.

We set up forwarding to a personal address and it broke immediately.

Check what that personal address does with the mail. If it is itself forwarding back to the work address, or is an alias on a domain your tenant also handles, the two will bounce the message between them. Forward in one direction only, or use a shared mailbox instead.

Related SMTP status codes

Source. SMTP error 4.4.6 Routing loop detected is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes