What causes a 550 5.4.1 bounce error and how should it be handled?
Updated on 5 Oct 2026: We clarified recipient-directory and routing failures, with corrected suppression and retesting steps.
A 550 5.4.1 bounce records a permanent SMTP failure for that delivery attempt. When the full reply is Recipient address rejected: Access denied from a Microsoft 365 or Exchange Online host, Microsoft identifies Directory-Based Edge Blocking (DBEB) as the source. The receiving directory did not recognize the recipient as valid.
Check the spelling and current validity of the recipient first. Other common causes are a missing proxy address or directory object in a hybrid tenant, an accepted-domain configuration problem, or an incomplete domain migration. If the reply says Relay Access Denied, check MX records and mail routing instead. If unrelated recipient domains return different rejections, also check authentication and sender reputation.
Common bounce text
550 5.4.1 Recipient address rejected: Access denied. [mail.protection.outlook.com 2026-05-25T00:00:00.000Z]
What 550 5.4.1 means
The first number controls SMTP handling. 550 is a permanent failure. The IANA enhanced-status registry defines X.4.1 as "No answer from host", a network condition intended for temporary failures. Microsoft uses 5.4.1 with the Access denied wording for a DBEB recipient-directory rejection, so read the complete reply and receiving hostname instead of diagnosing the numeric subcode alone.
Microsoft documents this exact wording for Exchange Online recipients. The Microsoft NDR page says DBEB generates the NDR when the recipient address is invalid in the receiving directory. A different response string can indicate a different cause, even when the numbers match.
|
|
|
|---|---|---|
550 | Permanent SMTP failure | Do not retry unchanged |
5.4.1 | Provider context required | Read text and hostname |
Recipient address rejected: Access denied | Microsoft DBEB directory rejection | Verify recipient or escalate |
Relay Access Denied | Server does not accept the recipient domain | Check MX records and routing |
How to read the bounce code before taking action.
Do not trust the platform label alone
Some sending platforms classify this as a soft bounce because their parser groups it with other delivery failures. Use the SMTP class first. A 5.x.x reply is permanent for that delivery attempt, so stop automatic retries. Suppress a DBEB-rejected recipient pending address verification or administrator repair; a routing rejection does not establish that the mailbox is invalid.
Why only some recipients bounce
A partial bounce pattern at the same domain does not rule out a recipient-side cause. Modern mail systems can reject one address and accept another at the edge. For the exact Microsoft DBEB reply, the directory check rejects an unrecognized address before spam filtering and mail flow rules, as Microsoft's DBEB documentation explains.
For example, one recipient still exists while another has been deprovisioned or has an alias missing from the directory. The domain's MX host can accept valid users while DBEB rejects addresses missing from the directory.
- Directory check: The receiving edge checks whether the recipient exists before accepting the message.
- Tenant directory: A Microsoft 365 tenant can reject an address that has not synchronized into Exchange Online.
- Mailbox change: Acquisitions, closures, and domain moves leave old contacts behind in sending lists.
- Mixed routing: A domain can route different users through different internal paths during a migration.
A 550 5.4.1 flowchart showing directory and policy checks before acceptance or rejection.
The causes to check first
Start with the explanation that fits the full bounce text and delivery pattern, then work outward. A single recipient at a domain bouncing with 550 5.4.1 is usually not the same problem as every recipient at that domain bouncing after a DNS or accepted-domain change.
|
|
|
|---|---|---|
Bad recipient | One user fails | Verify, then suppress invalid address |
DBEB sync or provisioning | Expected or newly created users fail | Check mailbox, alias, and directory sync |
Accepted domain | Whole domain fails | Verify domain type |
Domain migration | Old or hybrid users fail | Clean directory and routing |
MX or routing mismatch | Relay Access Denied | Check destination MX and connectors |
Sender issue | Different rejections across unrelated domains | Check authentication and reputation |
Common causes and the first handling decision.
Recipient-side pattern
- Scope: Failures cluster around specific recipient domains, tenants, or addresses.
- Evidence: Some users at the same domain accept mail while others return the exact DBEB reply.
- Response: Suppress rejected addresses and ask the recipient admin to confirm directory state.
Sender-side pattern
- Scope: Failures rise across unrelated domains or after a new sending source starts.
- Evidence: Authentication, DNS, or reputation checks show a clear fault and the rejection text supports that diagnosis.
- Response: Fix authentication, routing, or suppression logic before the next send.
When 550 5.4.1 says 'Relay Access Denied'
This wording points to a different cause. Microsoft's SMTP error reference distinguishes Relay Access Denied from the DBEB recipient rejection: the responding server does not accept mail for the recipient's domain. A wrong MX record or mail-server configuration can send a valid recipient's mail to the wrong destination.
- Check the recipient domain's MX records against the mail provider's assigned destination, especially after a migration or DNS change.
- Confirm the recipient domain is present in the intended Microsoft 365 tenant and has the correct accepted-domain type.
- Review connectors and hybrid routing so mail reaches the system hosting the recipient. If the sender uses a fixed relay, check that route too.
- Hold affected sending while the administrator repairs routing, then send one controlled test. Do not mark every mailbox invalid based on this response alone.
How to handle the bounce
For an individual recipient returning the exact DBEB reply, suppress the address and do not retry the same campaign. Repeated attempts against an unchanged permanent rejection waste sending capacity. For a domain-wide routing failure, pause the affected sends while the route is repaired instead of deleting every contact. If you use Outlook, remove any stale Auto-Complete suggestion and retype the full confirmed address before retesting.
- Capture: Save the full non-delivery report (NDR), UTC timestamp, sender address, envelope recipient, sending IP, responding hostname, and mail stream. Include the SMTP command that failed if logs provide it, such as RCPT TO for the recipient check.
- Classify: Treat 5.x.x as permanent for that delivery attempt, even if the sending platform says soft bounce.
- Segment: Group by recipient domain, MX host, complete bounce string, campaign, and sending source. In a message with multiple recipients, handle only the addresses actually rejected.
- Suppress: Keep a recipient returning the exact 550 5.4.1 DBEB rejection out of active sends. Restore it only after a corrected address or confirmed administrator repair, followed by a successful controlled delivery test.
- Retest: After the recipient or routing configuration is corrected, send one message to the affected address through the original sending source. Confirm delivery before resuming bulk mail.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Use Suped's email tester to check authentication on a message sent to its test inbox. It does not confirm that a different recipient's mailbox exists or that DBEB will accept it.
If the affected domain is important, send the recipient admin the exact bounce text, UTC time, sender domain, envelope sender, sending IP, responding hostname, and one or two rejected envelope recipients. Ask them to check the recipient directory and any available message trace. DBEB rejects mail before the transport pipeline, so an absent trace does not rule out the rejection; this is explained in Microsoft's message trace answer.
Fixes for recipient administrators
The sender cannot repair DBEB. If the address should be valid, the recipient administrator needs to compare the NDR with the Exchange Online directory and accepted-domain configuration. Microsoft's NDR steps separate single-recipient failures from domain-wide failures.
- Confirm scope: Check the exact rejected SMTP address and whether one expected recipient or every recipient in the domain returns the NDR. Verify the mailbox is provisioned and the bounced alias is present; successful outbound sending alone does not prove inbound readiness.
- Repair a hybrid user: Confirm that the on-premises mailbox and SMTP proxy address synchronized to Microsoft Entra ID and Exchange Online. Microsoft advises changing the proxy to a temporary address and then restoring it to trigger an update.
- Allow replication time: After a hybrid proxy-address change, allow up to 24 hours for DBEB to fully update before the controlled retest. This is not a general retry window for every hard bounce.
- Review the accepted domain: Use Authoritative when all valid recipients are represented in Microsoft 365. Use Internal relay when unresolved recipients must route to another mail system through a configured connector. For a domain-wide failure on a correctly authoritative domain, Microsoft's NDR procedure says to switch it to Internal relay and back to Authoritative to resync it.
- Check special recipients: Verify that hybrid mail-enabled public folders are synchronized. For an on-premises dynamic distribution group, follow Microsoft's documented mail-contact workaround in Exchange Online.
Accepted-domain changes affect mail routing
Only the recipient's Exchange administrator should change the domain type. Confirm where every recipient is hosted and whether the required connector exists before using Internal relay, then verify mail flow after the change.
Sender-side checks worth doing
When other bounce strings accompany the DBEB reply, verify the sender setup as a separate investigation. The goal is to identify sender faults that explain those other rejections or a pattern across unrelated recipient domains.
Start with a domain health check to inspect published DMARC, SPF, and DKIM records. DNS records alone do not prove that a message passes authentication. Check a real message or reported authentication results for the sending source, then fix any faults separately from the recipient-directory rejection.
Authentication does not replace bounce handling
A valid DMARC setup does not make an unrecognized recipient valid. Suped's DMARC reporting and email authentication platform helps you review reported SPF and DKIM results by sending source. Compare those results with bounce logs rather than treating a DBEB failure as proof of an authentication problem.
For teams that need a repeatable workflow, use Suped's DMARC monitoring to review sending sources and authentication failures, and blocklist monitoring to investigate separate reputation issues. A clean blocklist (blacklist) result does not validate the recipient. Keep bounce classification and recipient suppression in the sending platform.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When to escalate to the recipient admin
Escalate when the recipient expects the message and confirms the address is current, especially after mailbox recreation or a migration. The exact DBEB reply warrants a directory check even if unrelated sender issues also exist. Escalation is usually not useful for cold or stale addresses where the contact has no recent engagement and the company has changed ownership or domain names.
Escalate
- Known contact: The recipient recently opted in, replied, bought, or asked for the message.
- Confirmed address: The recipient confirms the exact rejected mailbox or alias should receive mail, or the failure began after a directory or routing change.
- Business need: Delivery matters enough that the recipient admin has a reason to investigate.
Suppress
- Stale record: The address has no recent engagement or belongs to a closed business unit.
- Permanent NDR: The recipient returns the exact 550 5.4.1 DBEB failure and no correction is confirmed.
- No owner: There is no confirmed contact who can validate the mailbox.
Keep the suppression record and repair evidence together. If a recipient asks to be re-added through another channel, confirm the exact current address and complete a controlled delivery test before sending bulk mail again.
How list quality fits in
Check list quality after the technical facts are clear. A spike in 550 5.4.1 bounces often appears after company acquisitions, closures, rebrands, or domain migrations. Those events do not make the sender's DNS wrong, but they do make old contact records unreliable.
Separate the list into recently engaged contacts and stale records, then keep stale records out of bulk sends until the address is confirmed current. That protects the active audience and keeps one bad segment from distorting the health of the mail stream.
- Lookback: Prioritize recent replies, form submissions, purchases, or logins. Opens and automated clicks alone do not confirm a human response or a working mailbox.
- Source: Split customer records, prospect records, partner records, and imported records before deciding policy.
- Freshness: Require confirmation of the current address and a successful delivery test before reinstating recipients that already returned a permanent DBEB rejection.
- Pattern: If old domains have the highest rejection rate, prioritize cleanup over repeated sending.
Views from the trenches
Best practices
Stop automatic retries after a 5.x.x reply; retest only when its cause is corrected.
Segment bounces by recipient domain and MX host before changing sender-side settings.
Keep the full NDR text, UTC timestamp, sender IP, and rejected recipient for escalation.
Common pitfalls
Trusting a CRM soft-bounce label over SMTP class causes repeat sends to dead mailboxes.
Treating every 5.4.1 response as a dead mailbox misses domain routing and DNS failures.
A clean blocklist (blacklist) result cannot confirm that the recipient directory is correct.
Expert tips
Suppress a DBEB-rejected recipient, then retest only after its address or directory is fixed.
Compare delivered and bounced recipients at one domain to identify directory lookup failures.
Check directory sync and accepted-domain state before changing any sender-side settings.
Marketer view
Marketer from Email Geeks says 550 5.4.1 with Access denied usually points to a block at the receiving Outlook-hosted domain.
2024-03-04 - Email Geeks
Expert view
Expert from Email Geeks says the code is a hard SMTP failure, even when a sending platform labels the event as a soft bounce.
2024-03-04 - Email Geeks
When to restore a suppressed recipient
Permanent does not always mean the person behind the mailbox is gone. It means this SMTP delivery failed and should not be retried unchanged. Keep a DBEB-rejected address suppressed until its spelling or recipient-directory entry is corrected, then confirm delivery with one test before restoring bulk sends. Engagement alone does not repair a directory rejection.
