SMTP reply code
550 5.4.1 — recipient address rejected, access denied
A 550 5.4.1 reply usually means the receiving system refused the recipient — commonly because the address is not in its directory, or because a policy blocks the sender. It is permanent as sent, but the reply text decides what it is really telling you.
The facts
| Field | Value |
|---|---|
| Reply code | 550 |
| Enhanced status code | 5.4.1 |
| Class | 5 — permanent failure |
| Subject | 4 — network and routing status |
| Detail | 1 — no answer from host |
| Bounce type | Hard |
| Should the sender retry? | No |
| Representative wording | 550 5.4.1 Recipient address rejected: Access denied |
The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.
What VerifyInbox returns
| Field | Value |
|---|---|
emailStatus | unknown when the reply text names an access denial, a block or a blocklist — the common case for this code; undeliverable when the text names the mailbox instead |
reason | ip_blocked in the first case, mailbox_not_found in the second |
retryable | true in the first case, false in the second |
| Charged | No in the first case — a retryable result is never charged, because the mailbox was not tested. Yes in the second. |
The code says one thing, the servers use it for another
This is the clearest example in the whole family of why the reply text matters more than the digits. In the IANA registry, X.4.1 is registered as "No answer from host" — it belongs to the network and routing subject, which covers connectivity and delivery paths rather than policy.
What you will actually find in a bounce is 550 5.4.1 carrying a sentence about the recipient being rejected or access being denied. That is a policy decision expressed in a routing code. Nothing is wrong with the server doing this — the enhanced codes are a hint, not a contract — but it does mean a bounce processor that branches purely on 5.4.1 will file a recipient-policy rejection under "network problem" and retry it forever.
The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.
What it is usually telling you
Two quite different situations produce it. Either the recipient is not in the receiving organisation’s directory — functionally the same as 550 5.1.1, just phrased as a refusal instead of a lookup failure — or the receiving system has decided not to accept mail from you for that recipient, which is a 5.7.x situation wearing the wrong number.
The practical test is the wording. "Recipient address rejected" with no other detail points at the directory. Anything naming access, permission, relaying or a blocklist points at you, and deleting the address would be the wrong correction entirely.
What to do
If you sent the message
- Read the full reply text before touching the address. The digits do not distinguish "no such recipient" from "we do not accept your mail".
- If it names the recipient, confirm the address and suppress it if it is wrong.
- If it names access, permission or a blocklist, leave the address alone — the problem is on your sending side and removing a working contact will not fix it.
If you own the receiving domain
- Check whether the recipient exists in your directory at all — this is often an unlicensed or unsynchronised account rather than a deliberate policy.
- Review delivery restrictions on the mailbox or group: a rule that only accepts internal senders produces exactly this for everyone outside.
- If your gateway is rewriting the reply, consider returning a
5.1.1for a missing recipient so senders can process it correctly.
If you are a developer
- Do not branch on the enhanced code alone for this one. Match the reply text for block, blocklist, access-denied and relay wording first.
- Classify a text-confirmed sender block as a sender-side incident, not as a bad address — otherwise one reputation problem silently deletes a whole segment.
- Suppress only when the text points at the recipient.
To find out whether an address will return this before you send to it, run it through the free email verifier
Related codes
Related terms
Sources
- RFC 5321 — Simple Mail Transfer Protocol
- RFC 3463 — Enhanced Mail System Status Codes
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes
- IANA — SMTP Enhanced Status Codes registry
Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.