5.4.1: Recipient address rejected: access denied (Microsoft 365)

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code: varies; the enhanced code is the part that identifies the problem.
• Enhanced code 5.4.1: “No answer from host” in the IANA registry (RFC 3463), in the group network and routing status (RFC 3463 §3.5).
• Who uses it: Microsoft (Exchange Online): "Recipient address rejected: Access denied" and "Relay Access Denied".

Microsoft 365 refused the recipient at the edge of its network. Most often the address does not exist in that organization; sometimes the organization's mail setup does not accept mail for the domain at all.

What it means

In the IANA registry, X.4.1 is "no answer from host", a network code that RFC 3463 §3.5 treats as transient only. Microsoft uses 5.4.1 in its own way, for two different rejections (Exchange Online NDR reference):

• 550 5.4.1 Recipient address rejected: Access denied: the recipient does not exist. Exchange Online uses Directory Based Edge Blocking, which rejects mail for addresses that are not in the organization's directory before the message is accepted.
• 5.4.1 Relay Access Denied: the server does not accept mail for the recipient's domain. Microsoft points to a misconfigured mail server or DNS.

Both are permanent. The text after the code tells you which one you have.

Common causes

For "Recipient address rejected":

• A typo in the part before the @.
• The person left and their mailbox was removed.
• The address was never created, or an alias was removed.

For "Relay Access Denied":

• The domain's MX records point to Exchange Online, but the domain is not set up there as an accepted domain.
• The domain moved to another mail host, but its MX records still point to the old one.

How to fix it

If you are the sender:

1. Check the spelling of the address and confirm it with the person through another channel.
2. For "Relay Access Denied", tell the recipient's organization. Only their administrator can fix it.

If you run the receiving organization:

1. For "Recipient address rejected", check that the address is assigned to a mailbox, group or contact in your directory. If it should exist and does not, add it to the right recipient.
2. For "Relay Access Denied", check that the domain is listed and verified as an accepted domain in Microsoft 365, and that its MX records match what Microsoft 365 shows for it.
3. Send a test from an outside account after each change.

What to do with the address

For "Recipient address rejected: Access denied", treat the address as not existing: suppress it, like 550 5.1.10. For "Relay Access Denied", the address may be fine; the whole domain is failing, so hold it and contact the organization before removing anything.

Related codes

• 550 5.1.10: Recipient not found (Microsoft 365)
• 550 5.1.1: The recipient mailbox does not exist
• 5.7.64: TenantAttribution: relay access denied (Microsoft 365)

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.