SMTP error 550 5.4.1: no answer from host, read correctly

SMTP error 550 5.4.1 has an RFC 3463 meaning of "no answer from host" - a routing-layer

failure where the sending or relaying system could not get a response from the next hop in the

delivery path. In practice, the string most people encounter carrying this code is Microsoft

365's 550 5.4.1 Recipient address rejected: Access denied, which is not a routing failure at

all - it is Exchange Online's deliberate response for several unrelated access conditions,

reusing a code whose textbook definition does not match its real-world usage here.

Fault: depends entirely on the system. On a genuine routing failure, fault sits with network

path or relay configuration. On Microsoft 365's reuse of the code, fault is usually a tenant

policy or a genuinely nonexistent recipient, deliberately disguised as "access denied" to avoid

confirming which.

Why it happens

• Genuine RFC-sense routing failure. A relay or forwarding system could not reach the next

MTA in the chain - the destination host is down, unreachable, or the relay's own outbound path

is broken.

• Microsoft 365's directory-harvesting protection. Exchange Online deliberately returns the

identical 550 5.4.1 Access denied string whether the mailbox does not exist or the sender is

genuinely blocked by a transport rule, so that probing for valid addresses gains no information.

• A transport rule or mail flow rule rejecting the message based on sender, content, or

connector policy, surfaced through this same code on some tenant configurations.

• An intra-organisation routing failure on a multi-domain or hybrid Exchange setup, where

internal routing between on-premises and cloud mailboxes cannot complete.

The transcript

$ swaks --to someone@tenant.onmicrosoft.com --server tenant-com.mail.protection.outlook.com \
        --from sender@yourdomain.com
-> MAIL FROM:<sender@yourdomain.com>
<- 250 2.1.0 Sender OK
-> RCPT TO:<someone@tenant.onmicrosoft.com>
<- 550 5.4.1 Recipient address rejected: Access denied. AS(####) [AM0PR01MB....namprd...]

The bracketed code on the end (here AS(####)) is a Microsoft-internal rule identifier - it

rarely resolves to a public, documented meaning, but its presence confirms this is Exchange

Online's own policy engine speaking, not a generic routing failure.

How the big three word it

Diagnose it

$ dig +short MX tenant.onmicrosoft.com
tenant-com.mail.protection.outlook.com.

$ swaks --to someone-else@tenant.onmicrosoft.com --server tenant-com.mail.protection.outlook.com
<- 250 2.1.5 Recipient OK

Testing a second, known-good recipient at the same tenant is the fastest way to tell the two

real-world cases apart: if a different recipient at the same domain is accepted cleanly, the

first address was most likely wrong or the policy block was specific to that sender-recipient

pair, not a routing problem with the tenant itself.

The fix, in order

1. Double-check the recipient address for typos first - Microsoft's intentionally ambiguous

wording means a nonexistent mailbox and a policy block look identical.

1. Test a second known-good recipient at the same domain to isolate whether the tenant itself

is reachable.

1. If you administer the tenant, check mail flow/transport rules and connector configuration

for anything that would reject this specific sender or pattern.

1. If this is a genuine routing failure (non-Microsoft system), check the relay's outbound

connectivity to the next-hop MX and confirm DNS for the destination domain resolves correctly.

1. Contact the recipient through another channel to confirm whether the address is current,

since Microsoft's wording will not confirm or deny it for you.

What not to do

• Do not assume "Access denied" means you are IP-blocked. On Microsoft 365 it is also the

wording for a simple typo in the address, deliberately indistinguishable from a real block.

• Do not suppress the address immediately. Confirm with the recipient through another

channel first, since this exact string covers both a dead address and a configuration issue

that has nothing to do with the address's validity.

• Do not treat every `550 5.4.1` the same regardless of which system sent it. The RFC meaning

and Microsoft's real-world usage diverge enough that the fix depends on which produced it.

• Do not retry the message hoping a routing glitch clears, since in the Microsoft 365 case

this is a permanent 5xx policy decision, not a transient routing hiccup.

MailPilot records the exact reply string per attempt, which matters here specifically because

550 5.4.1 means something different depending on the receiving system - a distinction that is

lost the moment a tool collapses every 5.4.1 into one generic "bounced" label.