SMTP error from remote mail server after rcpt

The phrase "SMTP error from remote mail server after RCPT TO" is not a standalone error code. It is the text Exim (the MTA behind cPanel, DirectAdmin, and many hosts) writes into a bounce (NDR) when the receiving server rejected your message during the RCPT TO step of the SMTP conversation — the moment your server names the recipient. The actionable information is the 3-digit reply code and text that immediately follow the phrase.

What does "after RCPT TO" actually mean?

An SMTP delivery is a scripted conversation (RFC 5321 §3.3). Your server announces itself (EHLO), declares the sender (MAIL FROM), then declares each recipient (RCPT TO:<user@domain>). The receiving server validates that recipient and answers. If it accepts, you get 250 OK. If it rejects, it returns a failure code at this stage — and Exim labels the resulting bounce "after RCPT TO" to tell you the rejection happened on the recipient address, not on the sender or the message body (DATA). This is the single most useful clue: the problem is with who you're sending to or the receiving server's policy toward you, not your attachment or HTML.

How do I read the bounce?

Find the line that follows the wrapper. It looks like:

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

The leading digit decides everything (RFC 5321 §4.2.1):

• 5xx = permanent failure (hard bounce). Do not retry as-is. Common at RCPT: 550 5.1.1 no such user, 550 5.7.1 rejected by policy/blocklist, 554 relay denied.
• 4xx = transient failure (soft bounce). A compliant sender retries automatically; Exim defers and retries on its schedule. Common: 450 4.2.1 mailbox temporarily unavailable, 451 4.7.1 (a generic "not authorized/filtered" code per RFC 3463, commonly repurposed by MTAs for greylisting or rate-limiting).

How do I fix it?

Match your fix to the code that follows the phrase:

1. 550 5.1.1 / "User unknown" / "No such user": The recipient mailbox does not exist. Verify the exact address with the recipient (typos, retired accounts). Remove dead addresses from your list — repeatedly hitting unknown users damages sender reputation.
2. 550 5.7.x / "rejected by policy" / "blocked": The receiving server is rejecting you. Check your sending IP and domain against blocklists (e.g. Spamhaus), and confirm SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 9989, the current DMARCbis standard obsoleting RFC 7489) all pass for your From domain. Set valid reverse DNS (PTR) for the sending IP.
3. 450/451 (transient): Often greylisting or rate-limiting in practice, even though the RFC-defined text behind these codes is generic ("mailbox unavailable" / "not authorized or filtered"). Let the MTA retry; do not loop fast. If it never clears, treat it like a policy block and check reputation/auth.
4. 550 (or 554) "relay not permitted" / "relay denied": You are sending through a server you are not authorized to relay on, or hitting the wrong host. RFC 5321 §3.6.2 specifies servers SHOULD return 550 when declining to relay for policy reasons. Confirm you are connecting to the recipient domain's real MX and authenticating if required. (A 551 response is unrelated — per RFC 5321 §3.4 it means "user not local," pointing you to a forwarding address, not a relay refusal.)