TL;DR
4.4.6 signals a routing loop. Keep the exact reply and path evidence, trace forwarding rules and routing configuration, retry with a bounded window only, then escalate; do not suppress the recipient from this path condition alone.
What this code means
X.4.6 names routing-loop detection. This catalog publishes 4.4.6 from exact Rackspace corpus evidence; the IANA mirror records no class confirmation for the pattern, so do not turn the descriptive registry text into a universal class or provider claim.
Provider examples
450 4.4.6 Routing loop detected (G16)Technical meaning
A forwarding rule, routing table, MX setup, or relay chain sent the message back through a previously handled path until delivery was aborted. Rackspace's exact example is "450 4.4.6 Routing loop detected (G16)"; it documents Rackspace behavior, not every provider's wording, reply class, or root cause.
Delivery status
The concrete accepted class-4 result is temporary only in the sense that a repaired path can succeed. A route loop will not be repaired by unlimited retries, and a class-5 interpretation must not be inferred from this record's evidence.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Retry a bounded number of times with backoff while the forwarding or routing fault is traced. Stop after success or the attempt window; if the loop persists, escalate to the mail-flow owner instead of repeatedly sending through the same cycle.
Suppression decision
Do not suppress based on 4.4.6 alone. The code describes a routing or forwarding problem, not an invalid recipient; require a separate permanent, address-specific signal for suppression.
Common causes
- A recipient forwarding rule returns mail into a previously traversed path.
- A routing table, MX record, or relay configuration forms a mail-flow cycle.
- Rackspace's G16 example is evidence for that provider's loop detection only.
Diagnostic steps
- Confirm exactly 4.4.6 and retain the full response and any provider token.
- Trace Received headers and mail-flow logs to find the hop that reintroduces the message to the cycle.
- Check affected forwarding rules, relay paths, routing tables, and MX configuration with their owners.
- Use a bounded retry window; escalate with path evidence if the loop remains.
Actions by owner
Sender administrator
- Hold repeated sends to a bounded retry policy and retain complete path evidence.
- Escalate persistent loops to the recipient domain or provider with response text and timestamps.
Recipient administrator
- Inspect forwarding rules and routing configuration under your control.
- Remove a confirmed loop and verify a new controlled delivery.
Provider
- Trace managed routing and preserve provider-specific diagnostic tokens.
- Repair a confirmed cycle instead of relying on sender retries to clear it.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- Rackspace/emailsrvr.com SMTP response codes — Rackspace's emailsrvr.com postmaster reference for SMTP response and reject codes.
Last verified:
