What causes the '550 5.4.1 Recipient address rejected: Access denied' email error and how can I fix it?
Published 22 Apr 2025
Updated 23 Oct 2026
13 min read
Summarize with
Updated on 23 Oct 2026: We clarified Microsoft 365 recipient checks, accepted-domain routing, and when to retest a failed delivery.
The 550 5.4.1 Recipient address rejected: Access denied error means the receiving mail system refused the recipient before delivery. It is a permanent SMTP rejection, not a soft delay. For the exact Microsoft 365 response, check the recipient address and tenant directory first. Investigate sender authentication or reputation when the full diagnostic identifies a sender problem; failures across unrelated domains alone do not prove one.
It is not proof that you are on a blocklist (blacklist), and it is not automatically caused by sending too many messages at once. In Microsoft 365, this exact wording most often means directory-based edge blocking (DBEB) could not find the recipient in Exchange Online. Other receiving systems can use similar text for routing or access rules, so read the complete delivery status notification before assigning a cause.
- Primary meaning: The receiving server refused delivery for that recipient or domain.
- Best first step: Group the bounces by recipient domain and read the full bounce text.
- Microsoft 365 check: Confirm the address exists and is visible to Exchange Online directory-based edge blocking.
- Fix path: Verify the recipient, accepted-domain state, and routing, then check sender signals when the evidence supports it.
What the error means
The key word is rejected. Your server connected to the recipient system and usually received the refusal after issuing RCPT TO, before it sent DATA or the message body. The 550 reply indicates permanent failure. The enhanced code 5.4.1 alone does not identify the root cause because receiving systems apply it differently. The phrase Access denied and the remote host show which diagnostic branch to follow.
Do not keep retrying
A 550 is a permanent failure for that delivery attempt. Stop automatic retries and suppress the failed address, or pause the affected segment while a directory or routing fault is investigated. Send one controlled retest after correcting a confirmed address error or after the recipient administrator confirms a fix.
A single bounce is usually a local recipient problem. A sudden spike across one corporate domain can indicate a tenant directory or routing problem. The same response across many unrelated recipient domains calls for a wider check of address quality, sending infrastructure, and the complete provider-specific diagnostics. That is why the full bounce matters, not only the short SMTP line.
|
|
|
|---|---|---|
Invalid mailbox or alias | One address fails | Confirm the exact current address with the recipient |
Recipient directory fault | Known recipients in one domain fail | Check recipient objects and accepted-domain state |
MX or routing fault | Failures after a mail migration | Compare the rejecting host with the intended mail route |
Sender-policy rejection | The diagnostic explicitly identifies a sender restriction | Review the named policy or blocklist evidence |
Authentication rejection | The diagnostic explicitly identifies authentication failure | Inspect a fresh test message and sender DNS |
Match the full diagnostic to the cause; failure scope alone does not establish it.
Common causes
The exact Microsoft 365 response has a specific leading cause: Exchange Online directory-based edge blocking does not recognize the recipient. Similar SMTP text can come from other receiving systems, so the pattern still matters. Start by asking whether the bounces cluster around one recipient domain, one mailbox provider, one campaign, one sending IP, or one segment of addresses.
Recipient-side causes
- Address: The mailbox or alias no longer exists, even if the user once opted in or the primary mailbox still works.
- Directory: Microsoft 365 directory-based edge blocking can reject mail when a recipient is not known in Exchange Online or has not synced yet.
- Routing: The recipient domain has MX, accepted-domain, connector, or tenant configuration trouble.
- Policy on other systems: Similar access-denied wording can refer to sender restrictions. Microsoft DBEB rejects unknown recipients before mail flow rules run.
Sender-side signals to verify
- Authentication: Check SPF, DKIM, and DMARC when the diagnostic identifies an authentication failure.
- Reputation: A blocklist or blacklist listing matters when the receiving policy or cross-domain pattern points to the sender.
- Volume: A fast increase in send rate deserves review when several unrelated domains start rejecting mail.
- List quality: Old or imported contacts create invalid-recipient bounces and damage future acceptance.
Closed-loop confirmation helps, but it does not guarantee the address still exists or that the recipient's tenant still accepts mail for it. People leave jobs, companies migrate mail systems, aliases are removed, and security teams change inbound rules. Compare hard-bounce rates with your normal baseline and the affected recipient domains; a percentage alone does not identify a DBEB fault.
How to diagnose it
The fastest useful diagnostic is the full delivery status notification. A short log line hides the remote host, recipient domain, SMTP command or response stage, enhanced code, and provider-specific strings. If the bounce mentions Microsoft, accepted domains, directory-based edge blocking, or an AS code, that detail changes the next action.
Illustrative NDR details to collecttext
Remote server returned: 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) Sender: sender@example.org Recipient: user@example.com Remote host: example-com.mail.protection.outlook.com Sending IP: 192.0.2.10 (example) SMTP stage: RCPT TO (if recorded) Original message ID: <original-message-id> Timestamp: <UTC time of failed attempt>
If the diagnostic points to sender authentication, inspect a fresh test message sent through the same sending path with the Suped email tester. This checks the test message's SPF, DKIM, and DMARC results. A receiver that rejected RCPT TO did not receive the message headers or body, so it could not evaluate that message's DKIM signature or DMARC result.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Next, group the failures. If one corporate domain rejects every recipient, ask that recipient's mail admin to verify the addresses and inbound routing. If many Microsoft-hosted addresses fail, compare the affected list source and recipient age before assuming a sender reputation problem. If unrelated domains reject the same campaign and their diagnostics name sender policy, investigate authentication, reputation, and sudden volume changes. If only one address fails, suppress it as a hard bounce unless the recipient confirms the exact mailbox is active.
- Collect: Save the full DSN, remote host, recipient, timestamp, and sending IP.
- Group: Sort bounces by recipient domain, provider family, campaign, and source.
- Verify: Confirm the exact mailbox or alias through a legitimate business channel. In Outlook, remove a stale autocomplete suggestion and type the confirmed full address manually.
- Inspect: When the pattern points to the sender, review SPF, DKIM, DMARC, reverse DNS, HELO/EHLO hostname, and blocklist evidence.
- Reduce: Pause affected segments until the root cause is clear.
How to fix it
The fix depends on whether the rejection is recipient-side, sender-side, or mixed. Do not start by changing sender DNS blindly. First separate invalid-recipient and tenant-directory bounces from routing or policy bounces, then fix the smallest proven cause.
Fix order
- Recipient: Confirm the address, domain, accepted-domain state, and directory visibility with the receiving admin.
- Routing: Check MX records, connectors, hybrid synchronization, and the remote host named in the bounce.
- Authentication: If sender evidence exists, fix SPF, DKIM signing, DMARC domain matching, and visible From consistency.
- Reputation: Remove bad addresses, reduce complaints, and review blocklist or blacklist evidence before resuming affected volume.
Suped's DMARC reporting product helps investigate confirmed sender authentication failures. Use its DMARC aggregate reports to identify the sending source, compare SPF and DKIM results, and follow the issue-specific fix steps. Correlate that evidence with the remote host and recipient-domain groups from the bounce log before changing DNS.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
If you need a wider authentication check, run a domain health check and compare it with your live DMARC aggregate data. Ongoing DMARC monitoring matters because a new sender, broken DKIM selector, or SPF lookup issue can appear after a campaign has already started.
What this error means in Microsoft 365
Microsoft documents this exact NDR as directory-based edge blocking in Exchange Online rejecting an address it considers invalid. The rejection happens at the Microsoft 365 network perimeter before later anti-malware, anti-spam, and mail flow rule processing. For this exact response, often accompanied by AS(201806281), start with recipient validity and directory state. The Microsoft NDR page lists the recipient-admin checks for this response.
Microsoft 365 Exchange admin center message trace for a 550 5.4.1 Recipient address rejected failure.
If you control the recipient tenant, check accepted domains, DBEB, and whether the exact recipient address exists on a mail-enabled object in Exchange Online. Check connectors for hybrid or third-party routing. A missing message trace result does not rule out a perimeter rejection. Because DBEB blocks the message before filtering, there is no quarantined copy to release. If you are the sender, give the recipient admin the full NDR and the original message ID. Microsoft's DBEB documentation explains this rejection before filtering.
When this error appears after a migration, the recipient side should confirm that MX records, accepted domains, connectors, and directory sync are complete. When it appears after a sender-side platform change, confirm the new sender is authenticated and authorized in DNS, but do not treat that timing alone as proof that sender authentication caused a Microsoft DBEB rejection.
Recipient-admin fixes in Microsoft 365
If you administer the Microsoft 365 tenant receiving the mail, first determine whether one address or the whole domain is affected. One failing mailbox points to address spelling, a missing recipient object, proxy address trouble, or hybrid sync. Every address in the domain failing points to accepted-domain configuration, MX routing, connectors, or incomplete migration state.
Microsoft 365 recipient checklist
- Check the address and scope: Confirm the exact SMTP address or alias on the Exchange Online recipient object, then test another known recipient in the same domain.
- Check the accepted domain: For domain-wide failures, verify its type and routing. Use the resynchronization procedure below only after confirming that the intended recipients are present.
- Fix hybrid recipients: Resolve directory-sync errors first. For a valid synced on-premises mailbox that still fails, change its SMTP proxy address temporarily in the on-premises directory, sync, then restore the original address and sync again.
- Check special recipients: Confirm that on-premises mail-enabled public folders have synced. For an on-premises dynamic distribution group, create an Exchange Online mail contact with its external email address.
- Allow update time: After an on-premises mailbox change, Microsoft documents up to 24 hours for DBEB to update. Check that synchronization succeeded before waiting.
Do not ask the sender to change SPF, DKIM, or DMARC for a Microsoft 365 recipient directory problem. Sender authentication still needs to be clean, but the rejection will continue until Exchange Online knows the recipient or the accepted-domain state is corrected.
For a sudden domain-wide failure, check Health > Service health in the Microsoft 365 admin center for an Exchange Online incident. Microsoft service health guidance explains where to check. If valid recipients still fail after successful synchronization and the documented update window, open a Microsoft support case with the full NDR and completed checks.
When to use Authoritative or Internal relay
An accepted domain's type controls how Exchange Online handles an address it cannot find. Choose the type to match your recipient directory and mail routing.
|
|
|
|---|---|---|
Authoritative | Exchange Online has directory entries for every intended recipient. | DBEB rejects addresses missing from the directory. |
Internal relay | The domain is shared with another mail system and some recipients are not in the cloud directory. | Mail for unknown recipients is relayed to your other mail system through a correctly configured connector. |
Choose the accepted-domain type for the intended mail route.
Microsoft's accepted-domain guidance explains the routing requirements. Leaving a cloud-only domain on Internal relay disables its normal DBEB invalid-recipient rejection and does not repair a missing mailbox or alias.
For a domain-wide directory fault, Microsoft's 550 5.4.1 repair steps describe switching Authoritative to Internal relay and back to Authoritative to resync the domain. Confirm that all intended recipients have replicated before returning to Authoritative. Keep Internal relay only when your routing design requires it.
Reputation, blocklists, and volume
For the exact Microsoft directory-based edge blocking response, reputation and volume are secondary checks. Review them when the full diagnostic names sender policy. Failures across unrelated domains also occur when a stale list contains many invalid recipients. A sudden send to older contacts can still expose invalid addresses, so list source and recipient age belong in the investigation.
When the pattern points to the sender, check blocklist and blacklist status for the sending domain, return-path domain, and sending IPs. A listing does not establish the cause of a 550 5.4.1 rejection by itself. Suped's blocklist monitoring can track listing changes alongside the sender and recipient-domain groups in your bounce data.
Practical recovery pattern
- Suppress: Suppress confirmed invalid addresses. During a verified tenant fault, pause affected traffic and restore delivery after the recipient admin confirms repair.
- Segment: Restart with recent engagers before sending to older contacts.
- Authenticate: Make every active sender pass DKIM and produce passing DMARC results.
- Watch: Monitor bounce rate by recipient domain, not only as a campaign total.
Do not use a single good test score as the end of the investigation. A test message proves the message can authenticate in one controlled path. It does not prove a recipient tenant accepts your domain, that every list address still exists, or that your sending pattern looks acceptable at volume.
Related SMTP errors and Microsoft AS codes
When comparing bounce text, use the full diagnostic. Microsoft's 550 5.4.1 bounce usually concerns an unknown recipient, while 550 5.7.1 generally indicates a permission or security-policy rejection. Microsoft's SMTP error reference lists the different causes.
A 501 5.5.4 Invalid domain name response concerns SMTP command arguments. Check the command named in the log and the hostname or domain syntax supplied with it.
For a plain-language explanation of the wording, compare it with Access denied meaning. For the specific AS(201806281) suffix, see the Microsoft AS code article for recipient-directory checks. Keep the suffix and rejecting host in the NDR you send to the recipient admin.
Views from the trenches
Best practices
Capture the complete bounce before changing DNS or suppressing a whole recipient domain.
Group failures by provider and campaign so one bad cohort does not mask a routing issue.
Use hard-bounce suppression quickly, then restore addresses only after direct confirmation.
Common pitfalls
Treating a good test score as proof that every recipient domain should accept the mail.
Assuming closed-loop signup proves a recipient mailbox or alias still exists months later.
Retrying hard 550 failures repeatedly instead of pausing and investigating the pattern.
Expert tips
Ask recipient admins to check the directory using the full NDR, timestamp, and sender IP.
Treat high levels as an address-quality or tenant-directory event until data proves otherwise.
Compare the exact Microsoft suffix and rejecting remote host before choosing a recovery plan.
Marketer view
Marketer from Email Geeks says the first question is which recipient domains are returning the error and whether those addresses still exist.
2024-10-30 - Email Geeks
Marketer view
Marketer from Email Geeks says Microsoft directory-based edge blocking has produced similar access denied bounces in past incidents.
2024-10-30 - Email Geeks
