SMTP Error 459

SMTP 459 is not one of the reply codes enumerated in RFC 5321's core MAIL/RCPT/DATA table, so generic SMTP-code references that only cover that table omit it. But it isn't undefined either: RFC 1985 (the ETRN / Remote Message Queue Starting extension) standardizes 459 Node <x> not allowed: <reason> as the response to an ETRN command. What you can read reliably regardless of context is its shape, because RFC 5321 §4.2.1 assigns meaning to each digit.

What does SMTP Error 459 mean?

Per RFC 5321 §4.2.1, the two leading digits tell you how to react even when the exact code isn't in the base spec's table:

• First digit 4 = Transient Negative Completion. The command failed, but the condition is considered temporary. The sending MTA is expected to keep the message queued and retry later — this is not a permanent bounce.
• Second digit 5 = Mail system. The reply concerns the status of the receiving mail system (mailbox, host, or delivery policy) rather than syntax (x0z) or the connection (x2z).

So 459 is best read as a transient, mail-system-level deferral. The standard transient 4xx codes in RFC 5321's core table are 421, 450, 451, 452, and 455; 459 isn't among them for a specific reason — it comes from a different RFC. When you see 459, the real diagnostic information is in the accompanying enhanced status code (RFC 3463, e.g. 4.7.1) and the free-text reason after the number — not in the digits 459 themselves.

Where does 459 actually come from?

459 is standardized by RFC 1985 §5.1 as the response to an ETRN command — a request from one MTA asking another to start flushing mail already queued for a given node. RFC 1985 §7 gives the worked example 459 Node foo.bar not allowed: Unable to resolve name. when the request is declined. Postfix implements this exact response for the same purpose (see its ETRN documentation, e.g. 459 <not.a.customer.domain>: service unavailable), which is a good independently-verifiable reference if you want to see the mechanism in a widely-deployed MTA.

If your 459 shows up outside an ETRN exchange — for example, as a rejection during ordinary MAIL/RCPT/DATA relay — it reflects that specific MTA reusing the code for a similar access-control purpose, not the RFC-1985 case itself. Treat the accompanying text as authoritative over any generic "459 means X" claim, and confirm with the receiving server's operator if you're unsure which case you're in.

How do I fix SMTP Error 459?

1. Read the full response line, not just the number. Capture the enhanced status code (e.g. 4.7.1) and the text after 459. A 4.7.x enhanced code points to a security/policy reason (relay denied, sender/client not authorized); other 4.x.x codes point elsewhere.
2. Determine whether it's an ETRN response or a normal relay rejection. If the 459 appeared after your system issued an ETRN command, it's the RFC-1985-standard queue-flush refusal — check that your host/IP is authorized for ETRN with that node. If it appeared during a normal MAIL/RCPT/DATA exchange, it's a non-standard reuse of the code by that MTA for an access-control decision; the text after 459 (e.g. "Node ... not allowed") is your best guide.
3. If it's a "node not allowed"/relay rejection: the server is refusing to route or flush mail for that node. Authenticate the SMTP session (submit on port 587 with STARTTLS or 465 with implicit TLS — both are valid per RFC 8314), and make sure your sending host/IP is permitted to relay through (or request ETRN from) that server.
4. Verify the recipient address. A malformed or unroutable recipient domain can trigger a transient mail-system rejection. Confirm the address and that its domain has valid MX records.
5. Check whether your sending IP or domain is being deferred. Greylisting and reputation blocks often surface as transient 4xx responses. Check your IP against blocklists with a tool such as MxToolbox, and confirm your SPF, DKIM, and DMARC are aligned for the sending domain.
6. Retry on a backoff schedule. Because 4yz is transient, a well-behaved MTA should keep retrying for several days. If 459 clears on retry, it was a temporary defer; if it persists, it's a standing policy/config issue to resolve with the receiving system's administrator.

If you can't obtain the accompanying text and the code is bare 459, contact the receiving server's operator — only they can map their specific 459 usage to a concrete cause.