Bounce and error codes

550 5.4.1 Recipient address rejected: Access denied

Last updated 2026-08-28

Microsoft 365 refused the address you sent to, and it refused that address before reading the rest of the message. The bounce reads 550 5.4.1 Recipient address rejected: Access denied, and Exchange Online refuses the address, not the sender. Your SPF, DKIM and DMARC records did not cause this, and editing them will not clear it. Someone who runs mail for the receiving domain owns the fix. The last section of this page is the message to send that admin.

The exact bounce, and the AS suffix

Microsoft's support article for this code prints the short form.

A live bounce usually carries a suffix, in this shape.

The bracketed host sits under protection.outlook.com, the domain Microsoft uses for Exchange Online Protection, so the suffix names the service that refused you. The AS(...) number is an internal one, and I found no Microsoft page that documents it, so read the address instead. Outlook wraps the whole thing in a report headed Your message couldn't be delivered.

Microsoft's code table lists a second string under the same number, and that one means something else. The table gives 550 5.4.1 Relay Access Denied as "the mail server that's generating the error doesn't accept mail for the recipient's domain". Microsoft puts that one down to a mail server or DNS set up wrong. If your bounce reads "Relay Access Denied", the work is in the routing or DNS on the far side. The steps below do not apply to it.

Directory-Based Edge Blocking rejected the address

Every Microsoft 365 domain carries a type. Exchange Online reads that type to decide what happens to an address its directory does not hold. Microsoft's accepted-domains page says what an Authoritative domain does with mail for an address the tenant does not list: "Emails for unknown recipients are rejected". The same page says that picking Authoritative "enables Directory-Based Edge Blocking (DBEB), which rejects messages for invalid recipients at the service network perimeter".

Microsoft's DBEB page gives the order the checks run in: "If the address doesn't exist, the service blocks the message before filtering even occurs". The same page prints the bounce that follows, 550 5.4.1 Recipient address rejected: Access denied.

• No filter setting helps. The message never reaches anti-spam or mail flow rules, so a safe-senders entry cannot rescue it and neither can an allow rule.
• Every sender gets the same answer. DBEB reads one field, the recipient address, and it reads that field before the call reaches any check on the sender.

Senders own 3 checks, and no more

1. The spelling. Compare the address in the bounce against the one you meant, letter by letter. Read the domain part twice. Exchange Online rejects user@exampel.com as fast as it rejects a bad mailbox name at the right domain. The bounce text reads the same either way.
2. A stale autocomplete entry. Microsoft gives this step for the nearby codes 5.1.1 and 5.1.10: delete the recipient from the Auto-Complete list, then type the whole address by hand. Outlook offers an address that changed a year ago, and you pick it without looking.
3. Whether the address still exists. People leave, admins delete the mailbox, and someone retires the shared alias. Phone the person, or reach them some other way, and ask what to use now.

If all three check out, one lookup names the service that refused you. Put the domain from the bounced address in place of example.com.

Run as printed, the command answers with a bare dot, because example.com publishes a null MX. Microsoft's page for the nearby code 550 5.1.10 names the two answers a Microsoft 365 tenant gives: <your domain>.mail.protection.outlook.com and <your domain>.subdomain.mx.microsoft. Either one puts the fix inside that tenant. A code that starts with 5 marks the refusal as permanent, so your server will not try again and neither should you. 550 permanent failure covers what that first digit commits your own server to.

Recipient admins: the checks that clear it

If you run mail for the domain in the bounce, you are the one who can end this. Everyone writing to that address gets the same bounce right now, and most of them will not tell you.

Microsoft's article for this code speaks to you rather than the sender: "If you're an email administrator in the recipient's organization, follow these steps until the issue is fixed". Its 6 steps run in this order.

1. Spelling, from the bounce. Ask the sender to forward the NDR, because the address is in there.
2. Scope. Send a test to another address on the same domain. One failure with the rest working points at a single bad address, and every address failing points at the domain.
3. Domain-wide failure: resync the domain. In the Exchange admin center, open Mail flow > Accepted domains, pick that domain, switch the type from Authoritative to Internal relay, save, then switch it back.
4. Hybrid mailbox on-premises. Reset the SMTP proxy address: change it to something else, change it back, and give it up to 24 hours.
5. Mail-enabled public folder. Check that it synced to Exchange Online. Microsoft points at the Sync-ModernMailPublicFolder script when it has not.
6. Dynamic distribution group on-premises. Those groups never sync to Exchange Online, so DBEB blocks them. Microsoft's workaround is a mail contact in Exchange Online with the same external address.

Internal relay needs a connector behind it. Microsoft is blunt about that on the 5.1.10 page: "Failing to do so will break mail flow to your on-premises recipients". An accepted domain set to Internal relay with no connector behind it stops the bounces and stops the delivery too. Nobody reports mail that never arrives, so that failure runs longer than the bounce did.

Authoritative domains reject unknown recipients, which is the whole point of the setting. An address nobody ever created bounces, even when the company thought that mail to anything at the domain would land somewhere. Customers write to info@, sales@ or an old alias. Each of those has to exist as a recipient object, or as an alias on a mailbox that does. Microsoft defines Internal relay as delivery to known recipients plus a relay "to your own email server if the recipients aren't known". Exchange Online then hands the unknown addresses to a server you run rather than to a mailbox in the tenant.

Message trace may have no row for the message, because the service refused it before filtering ran. Microsoft does not document what message trace shows for a DBEB rejection. Its own steps for this code start from the bounce the sender received, so ask for that first.

Migrations to Microsoft 365 are the usual cause

During a migration, somebody switches the accepted domain to Authoritative too early. Mail to every user who has not synced yet bounces with 5.4.1. The DBEB page states the order. "Until all of your valid recipients have been added to Exchange Online and replicated through the system, you should leave the accepted domain configured as Internal relay". Switch the domain to Authoritative after that. From the inside the migration looks finished, because the people who already synced are getting their mail. The users who have not synced see a quiet mailbox and no error, since the bounce goes to the sender.

Hybrid setups reopen the same hole later. A mailbox that lives on-premises needs a matching mail user or mail contact in Exchange Online, and the 5.1.10 page says the same. Without one of those objects, DBEB does not see the mailbox, so mail for it stops at the edge.

Send the recipient's admin this

You have done what a sender can do, and one message is left to send. The people who can fix this have not seen the bounce. A phone call that says "your email is broken" gives them nothing to act on. Paste this to whoever runs mail for the receiving domain, with the address filled in.

Name DBEB in the first line. An admin who reads "Access denied" on its own goes hunting for a block rule that nobody ever wrote.

Your DNS records are not involved

A new DMARC record does not create the recipient address, and nothing else you publish in DNS does either. DBEB reads the recipient address, and it runs before any check on SPF or DKIM.

Rejections that do come from broken records read differently. 550 5.7.515 names the required authentication level in its own text, and 550 5.7.23 names SPF.

Microsoft reuses 5.4.1 for a missing recipient

RFC 3463 assigns X.4.1 to "No answer from host". In the RFC, those digits mean the sending server got nothing back from the machine it connected to. Microsoft ignores that reading and gives the digits to an address that does not exist.

Read Microsoft's wording and set the RFC meaning of the digits aside. That matters most when you line up bounces from several systems. Microsoft returns 550 5.1.10 Recipient not found when an SMTP address lookup finds nobody, and 5.1.1 Bad destination mailbox address when the mailbox itself is wrong. Postfix refuses an unknown local user with a line that opens on the same words, Recipient address rejected:, and ends with User unknown in local recipient table. A bounce carrying that phrase came from a Postfix server, so nothing here about accepted domains applies to it. Write to the admin who runs that server instead. Why an email bounces back covers reading any bounce, whichever system sent it.

The fix above stands on its own. Tomorrow the reports start naming every other host still sending as you, and our digest turns them into one email with a verdict per sender, across 5 domains on Pro. Get the weekly digest, free for your first domain.