4.4.6Routing loop detected between mail systems

IANA's own wording on registry pattern X.4.6 ("Routing loop detected") calls it "useful only as a persistent transient error," and code 4.4.6 gives that pattern a temporary class: the message was forwarded between mail systems too many times without reaching its destination, so the handling system aborted the attempt instead of forwarding it forever. The registry's Associated Basic Status Code for X.4.6 is "Not given". That entry does not establish class 4 or class 5 mechanically, and this catalog's canonical mirror leaves the pattern's class-applicability resolution unresolved rather than treating descriptive language as class evidence. This concrete class-4 code is published purely from exact, corpus-collected production evidence, the Rackspace 450 4.4.6 response below, not from an IANA class confirmation.

A routing loop is what the X.4.6 pattern names. The message was forwarded between mail systems too many times, either because of incorrect routing tables or because a forwarding rule sent it back onto a path it had already taken. RFC 3463 (Section 3.4) defines the pattern under the network-and-routing status subject and calls it useful only as a persistent transient error, without formally confirming any class. The registry's Associated Basic Status Code for X.4.6 is "Not given," and this catalog's canonical mirror records the class-applicability resolution status as unresolved (basis: iana_missing_class_evidence), because descriptive prose is not converted into class evidence here. Concrete code 4.4.6 (class 4) rests on exact corpus evidence: Rackspace/emailsrvr.com returns "450 4.4.6 Routing loop detected (G16)" when its system detects an undeliverable mail loop, attaching its own internal reference code (G16) alongside the enhanced status code. In practice the same registry pattern is exclusive neither to class 4 nor to a single reply code. RFC 5248's non-exclusivity clause means a provider could equally reject or bounce a routing-loop condition under a different class or delivery mode, so always confirm the exact class and response text rather than assuming one universal treatment of X.4.6.

The leading digit 4 denotes a temporary failure: the accepted example's own guidance is to try again in a few minutes, on the expectation that whoever controls the forwarding rule or routing table causing the loop may fix it, or that the loop simply will not recur on a later attempt through a different path. This differs from a hypothetical class-5 use of the same X.4.6 detail, which would treat the loop as unrecoverable by retrying. This catalog does publish a class-5 concrete code under the same X.4.6 pattern (5.4.6), but its corpus evidence is a Titan over-quota rejection, not a routing loop — so no permanent-class routing-loop reading is evidenced here.

Class

Temporary failure

Retry

Controlled retry

Suppression

Check the full context

Retry a bounded number of times with backoff, since the receiving system's own guidance treats the condition as potentially transient. Do not retry indefinitely: a routing loop caused by a stale forwarding rule or a broken routing table will not clear itself no matter how many attempts are made, so stop after a reasonable attempt window — the accepted example itself points to escalation if the condition doesn't subside — and hand the problem to whoever administers the affected mail flow instead of continuing to retry a path that keeps looping.

Do not suppress the recipient address based on 4.4.6 alone: the condition names a routing or forwarding misconfiguration somewhere in the path, not an invalid or unreachable address. Suppress only if an independent, address-specific permanent signal appears after the loop has been resolved and the message still cannot be delivered.

• A recipient-side forwarding rule sends the message back toward a system that already handled it — for example, an address that forwards to another address which, directly or through a further rule, routes the message back into this same domain's path — creating a cycle the routing layer eventually aborts.
• A misconfigured routing table, MX record, or mail-relay chain sends the message hopping between systems without ever reaching a final destination, exceeding the accepted hop count before delivery completes.
• In the accepted Rackspace/emailsrvr.com example, the provider's own system detected the loop and rejected the message rather than continue forwarding it indefinitely, appending its internal reference code (G16) and directing the sender to retry later or contact postmaster@emailsrvr.com if the condition persists — documented behavior of this specific provider, not a general definition of code 4.4.6 across providers.

1. Inspect the raw SMTP response and confirm the enhanced code is exactly 4.4.6 with a 4xx basic reply (450 in the accepted example); note any provider-specific internal reference code included in the response (G16 in the accepted example), since it can speed up a support conversation with that provider.
2. Trace the message's path across mail-flow logs or Received: headers to identify which hop forwards the message back into a path it already took; look specifically at recipient-side forwarding rules and at any relay or routing-table entries touching this domain or address.
3. Ask whoever administers the affected mailbox or domain whether a forwarding rule was recently added or changed, and whether any routing table, mail-relay, or MX configuration was modified around the time the loop started.
4. Retry a bounded number of times and stop once the loop is fixed and delivery succeeds, or once the attempt window is exhausted; if the condition persists past that window, escalate directly to the receiving provider (the accepted example names postmaster@emailsrvr.com) rather than continuing to retry.