SMTP reply code
550 5.7.1 — delivery not authorized, message refused
A 550 5.7.1 reply means the receiving server refused the message on policy or security grounds. It is about the sender, not the recipient. The recipient address is usually fine, and removing it from your list fixes nothing.
The facts
| Field | Value |
|---|---|
| Reply code | 550 |
| Enhanced status code | 5.7.1 |
| Class | 5 — permanent failure |
| Subject | 7 — security or policy status |
| Detail | 1 — delivery not authorized, message refused |
| Bounce type | Hard |
| Should the sender retry? | No |
| Representative wording | 550 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using Blocklist 1 |
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 |
reason | ip_blocked |
ipBlocked | true |
retryable | true — the mailbox was never tested |
| Charged | No. The receiving server refused us; nothing was established about the address, so there is nothing to bill for. |
Subject 7 is the sender’s half of the code space
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.
Subject 7 is security or policy status, and it is the part of the space that describes decisions about the *sender*. Detail 1 is "delivery not authorized, message refused". Everything in 5.7.x is a statement about authorisation, authentication or reputation — 5.7.23, for example, is SPF validation failing.
Which is why the most common mistake with this code is expensive: a bounce processor that suppresses every 5xx will permanently delete a perfectly good contact because the sender had a reputation problem for an hour. A 5.7.x should never suppress an address.
What produces it
The sending IP is on a blocklist. SPF, DKIM or DMARC did not pass and the receiving domain’s policy says reject. The message was routed to a server that does not relay for that domain. The recipient is a group or mailbox configured to accept mail only from specific senders. Or the sending server tried to relay through a host it is not authorised to use.
Microsoft’s own documentation is blunt about the sender-side ones: for a source IP on its blocklist the bounce carries a delisting address, and for a permissions problem it says the fix belongs to the recipient’s administrator rather than to you.
What each provider actually says
Quoted from each provider's own published documentation, with the date it was read. Not paraphrased into a claim about what a provider "always" returns.
“The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent.”
“Typically, this error indicates a security setting in your organization or the recipient's organization is preventing your message from reaching the recipient.”
“5.7.1 Service unavailable; Client host [xxx.xxx.xxx.xxx] blocked using Blocklist 1; To request removal from this list please forward this message to [email protected]”
What to do
If you sent the message
- Do not remove the address. This code says nothing about whether the mailbox exists.
- Read the reply text — it usually names the specific cause, and often the delisting route.
- If it names a blocklist, follow that list’s delisting process and fix whatever produced the listing first.
- If it is a permissions problem, only the recipient’s email administrator can change it.
If you own the receiving domain
- Check the recipient’s delivery restrictions — "accept messages only from authenticated senders" produces this for every external sender.
- Confirm your connectors and accepted domains are configured for the routing you expect.
- If legitimate senders are hitting it, make sure your own SPF record lists every source that sends on your behalf.
If you are a developer
- Route
5.7.xto a sender-side incident queue, never to address suppression. - Alert on the *rate* of these rather than on individual events: one is noise, a spike is an outage.
- Keep the raw reply text. It is the only thing that names the blocklist or the failed check.
- A verification result with
reason: "ip_blocked"andretryable: truemeans the same thing — ask again, do not record it as a bad address.
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.