SMTP Error 458

SMTP reply code 458 is the negative response to the ETRN command. ETRN (RFC 1985, "SMTP Service Extension for Remote Message Queue Starting") lets a client ask a relay server to begin processing queued mail destined for a particular host — typically used by a mail server on an intermittent or dial-up connection asking its upstream relay to "flush" whatever is waiting for it. When that request cannot be satisfied, the server answers:

458 Unable to queue messages for node <x>

This is narrow and specific: 458 is not a generic "message rejected" or "connection refused" error, and it has nothing to do with firewalls, antivirus, or your SMTP client's port/auth settings. It only appears in response to an ETRN <node> command issued during a relay-flush exchange. (Its sibling, 459 Node <x> not allowed, is the policy-refusal variant — used when the relay won't serve that node at all.)

What causes SMTP Error 458?

Per RFC 1985 §5.1, 458 means the server understood the ETRN request but could not queue (initiate delivery for) messages for the named node. RFC 1985 does not enumerate specific underlying causes beyond that — but in practice, a 458 commonly stems from:

• The relay doesn't hold/serve mail for that node. The <node> argument must be a fully qualified domain name the server actually relays for (it may resolve via a CNAME or MX in DNS). If the server isn't a secondary MX / backup relay for that domain, it has nothing to queue and returns 458.
• The queue runner couldn't be started. A transient local condition — the server failed to spawn or hand off to its delivery/queue-processing process for that node.
• Resource or temporary local error on the relay preventing it from scheduling the flush right now.

Because 458 is a 4yz Transient Negative Completion reply under RFC 5321 §4.2.1, it signals a temporary failure: the condition may clear, and the client is permitted to reissue the ETRN command later (RFC 1985 §5.2).

How do I fix SMTP Error 458?

1. Confirm ETRN is the right tool and the node argument is correct. 458 only comes from ETRN <node>. Make sure <node> is the exact FQDN the relay is configured to hold mail for (matching its MX/relay configuration), not a user address or a bare hostname.
2. Verify the server actually relays for that domain. On the relay side, check that it's listed as a backup/secondary MX for the node and that its relay/queue tables include that domain. If it isn't a relay for that node, the correct response may be 459 (not allowed) or 458 — fix the relay configuration rather than retrying.
3. Inspect the relay's queue and mail logs. Look at the server's logs at the moment of the ETRN to see why the queue runner failed (resource limits, a stuck delivery process, permissions on the spool directory).
4. Retry after a delay. Since 458 is transient, wait and reissue ETRN. If it succeeds on retry, the original cause was a temporary local error on the relay.
5. If you're not running ETRN at all, a 458 in your logs likely originates from an upstream relay or a misconfigured backup-MX relationship. This code is not produced by ordinary MAIL FROM / RCPT TO / DATA delivery, so look at the queue-flush / secondary-MX leg of your mail path.

If you send through Courier or another API/provider, you will essentially never see 458 in normal sending — it belongs to relay-to-relay queue management. Seeing it means an ETRN-based flush between mail servers failed, and the fix lives in the relay's configuration and logs, not in your application's send call.