SMTP error from remote mail server

"SMTP error from remote mail server" is one of the most misread lines in a bounce report. It looks like a standalone error code, but it isn't — it is a wrapper phrase that your sending MTA (most commonly Exim, used by cPanel/WHM, Plesk, and many shared hosts) writes around the actual response the recipient's server sent back. The information you need is always the text that follows it.

What does "SMTP error from remote mail server" mean?

When your server hands a message off to the recipient's mail server, the conversation happens in discrete SMTP commands: MAIL FROM, RCPT TO, DATA, and the final . that ends the message body. If the remote server rejects any of these, Exim records its reply and surfaces it in the bounce wrapped like this:

SMTP error from remote mail server after RCPT TO:<user@example.com>:
host mx.example.com [203.0.113.10]: 550 5.1.1 User unknown

The clause after "after" tells you which stage failed:

• after RCPT TO — the recipient address was rejected (most common). Bad mailbox, blocked sender, or policy/auth check at the recipient.
• after MAIL FROM — the envelope sender / return-path was rejected (often SPF, sender reputation, or rDNS).
• after end of data (or after DATA) — the message itself was rejected after transmission — usually content/spam filtering, DKIM/DMARC failure, or size limits.

Everything after the host line — the 550, the 5.1.1, and the human text — is the real error, generated by the remote system, not by yours. Per RFC 5321 §4.2.1, the leading digit decides your action: 2xx success, 4xx temporary (your server will queue and retry), 5xx permanent (it bounces immediately). The three-dot enhanced status (e.g. 5.1.1) follows RFC 3463 and pinpoints the category. (Exim's error-handling model for host, message, and recipient errors is documented in its specification; the exact wrapper wording itself is standard Exim bounce behavior rather than a single quoted line in that spec.)

The legacy Courier guidance ("configuration errors / blocklist / invalid recipients") wasn't wrong, but it skipped the one step that actually resolves the ticket: read the embedded code. A 4xx and a 5xx with the same wrapper require opposite responses.

How do I fix "SMTP error from remote mail server"?

1. Copy the full line and isolate the real reply. Ignore the wrapper. Find the host, the 3-digit code, and the enhanced status. That string — e.g. 550 5.7.1 or 421 4.7.0 — is what you diagnose.

2. If it's a 4xx (temporary) — usually do nothing. Greylisting, rate limiting, or a transient resource issue at the recipient. RFC 5321 §4.5.4.1 expects senders to retry (typically for ~4–5 days), and Exim already defers and re-queues these automatically. Only investigate if it persists past the retry window — then treat it like a 5xx.

3. If it's a 5xx (permanent), fix by enhanced status:

• 550 5.1.1 "User unknown" / "No such user" — the mailbox doesn't exist. Remove or correct the recipient address; clean invalid and duplicate addresses from your list. (A related code, 5.1.10 (RFC 7505) — typically returned as 556 5.1.10, not 550 — means the recipient domain publishes a "null MX": it accepts no mail at all, so the address as written is undeliverable.) These are recipient-data problems, not a server-config one.
• 550 5.7.1 / 5.7.x "blocked" / "rejected by policy" / "not authenticated" — the recipient's policy refused you. Check that your sending IP/domain isn't on a blocklist (Spamhaus, Barracuda), and that SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) are aligned and passing for your From domain. Failing authentication is the single most common cause of policy 5xx rejections today.
• 554 5.7.x — content/reputation rejection (spam-scored, or sending IP reputation). Review message content, ensure rDNS/PTR matches your HELO hostname, and warm up new IPs.
• 552 5.3.4 "message size exceeds limit" — your message is bigger than the recipient's per-message cap. Reduce attachment size, compress files, or send a link instead.
• 452 4.2.2 / 550 5.2.2 "mailbox full" — the recipient's mailbox is over quota. This is usually returned as a temporary 4xx (Exim's automatic retry applies), but some servers escalate to a permanent 5xx after repeated failures. Nothing you change on your side fixes this; the recipient must clear space, or you wait for retry/escalation.

4. If you authenticate to a relay/provider, verify credentials and transport. A rejection after the wrapper that mentions auth can mean your SMTP login is wrong. Google phased out basic-password (non-OAuth) SMTP access in stages: personal Gmail accounts lost the "Less secure apps" toggle in 2022, and Google Workspace accounts followed with a later cutover finalized in 2025 — so on current Gmail/Workspace accounts an ordinary account password no longer works for SMTP. Use an App Password (with 2-Step Verification enabled) or OAuth2 instead. Use port 587 (STARTTLS) or 465 (implicit TLS); both are valid per RFC 8314.

5. If you send through Courier or another API, the embedded code is passed through from the downstream ESP/recipient. Check the message's delivery status and provider response in your logs to see the same code, then apply the fixes above.

The golden rule: the wrapper never changes, but the fix is entirely determined by the code it wraps.