SMTP Error 551

SMTP 551 is a permanent negative reply code defined in RFC 5321 §4.2.3 with the canonical text 551 User not local; please try <forward-path>. The receiving server is saying: the mailbox you addressed is not handled here, and (if it can) here is the server you should deliver to instead. Because it is in the 5yz class, it is a permanent failure — retrying the same address against the same server will fail again.

What does SMTP Error 551 mean?

The server you connected to is not authoritative for the recipient's mailbox and is refusing to relay or store the message for it. In the strict RFC reading, 551 is the server's way of redirecting you: the <forward-path> after the message names the correct host or address to try. In practice you will also see vendor variations like 551 User not local or invalid address – relay denied or 551 5.7.1 ..., where providers use 551 to signal an unauthorized relay attempt rather than a true "wrong server" redirect.

Two distinctions matter for diagnosing it:

• 551 vs. 550. RFC 5321 says that when a server declines to relay mail for policy reasons, a 550 response SHOULD be returned — so a "relay denied" condition is more correctly a 550. Some servers (MailEnable, Plesk, older MTAs) emit 551 for the same situation. Treat a 551 mentioning "relay" as an authorization/routing problem on the sending side.
• 551 is not a mailbox-full or temporary error. A full mailbox or a server that is momentarily unavailable produces a transient 4yz reply (e.g. 452 4.2.2), not 551. Don't troubleshoot 551 as a soft bounce — it won't clear on its own.

How do I fix SMTP Error 551?

Work from the most common cause down:

1. Check the recipient address and its MX records. Confirm the address is correct and that the domain's DNS MX records point to the host that actually hosts the mailbox. Misrouted or stale MX records send mail to a server that is not local for the recipient. Verify with dig MX recipientdomain.com (or nslookup -type=mx recipientdomain.com).
2. Send to the host named in <forward-path>. If the 551 reply includes a forward-path, deliver to that server/address. Per RFC 5321, the client should redirect according to the information provided or return the failure to the original sender.
3. Authenticate if you are relaying ("551 ... relay denied"). If you are sending through a provider's SMTP server to an outside domain, you must log in with SMTP AUTH on the submission port (587 with STARTTLS, or 465 with implicit TLS — both are valid per RFC 8314). "Less secure apps" access has been fully retired by Google for both audiences — personal Gmail accounts lost it May 30, 2022, and Google Workspace's admin-console LSA setting was removed September 30, 2024, with OAuth enforcement completed across all Workspace accounts by mid-2025. Use an App Password (with 2-Step Verification) or OAuth2 instead.
4. Fix server routing if you operate the receiving MTA. If your own server returns 551 for addresses it should accept, configure it as authoritative for that domain (local delivery domain / accepted domain) or add the correct relay/transport route so it stops treating local recipients as non-local.

If you send through an API like Courier, a 551 surfaces as a bounce in your delivery logs. Correct the recipient data or downstream provider routing/authentication, since 551 is permanent and the message will not be retried successfully against the same server.