What causes the 550 5.4.1 Recipient address rejected: Access denied AS(201806281) bounce error on O365 accounts?
Matthew Whittaker
Co-founder & CTO, Suped
Published 28 Apr 2025
Updated 23 May 2026
8 min read
Summarize with
The short answer: 550 5.4.1 Recipient address rejected: Access denied AS(201806281) on O365 accounts is most commonly caused by Exchange Online rejecting the recipient at the edge because the address is not valid in the recipient tenant, or because Exchange Online has stale or incomplete recipient directory data. Microsoft says this NDR is generated when directory-based edge blocking rejects mail because the recipient address is invalid on its Microsoft NDR page.
The confusing part is that the same bounce also appears when a third-party gateway receives the rejection from Microsoft 365 and passes it back to the sender. That makes it look like the gateway rejected the message, when the final rejection happened during relay into Exchange Online. I treat the AS(201806281) portion as a Microsoft diagnostic marker, not as a separate root cause.
- Most common cause: The recipient address does not exist in Exchange Online, or it exists on-premises but has not synced cleanly to Microsoft 365.
- Common hybrid cause: A hybrid Exchange tenant has an accepted domain, proxy address, public folder, or dynamic group mismatch.
- Common sender mistake: The sender assumes a domain-wide block when only one address or a small recipient set is failing.
- Less common cause: A spam or policy rejection is being returned with generic wording, especially when the pattern affects a sender IP or many recipients at one domain.
What the error means
The SMTP reply has two layers. 550 is a permanent failure, so the sender should not keep retrying forever. 5.4.1 is an enhanced status code that Microsoft uses here for this access denied recipient rejection. In practical O365 work, the text matters more than the generic code family: Recipient address rejected points at recipient validation, not a normal mailbox-full problem.
Typical NDR excerpttext
550 5.4.1 Recipient address rejected: Access denied. AS(201806281) Remote server returned: 550 5.4.1
|
|
|
|---|---|---|
550 | Permanent reject | Stop repeated retries |
5.4.1 | Routing or address issue | Recipient validity |
Access denied | Rejected by policy | Tenant routing |
AS marker | Microsoft diagnostic tag | Full NDR headers |
How I read the parts of the bounce
Do not diagnose it as a sender authentication failure first
SPF, DKIM, and DMARC problems can cause Microsoft delivery trouble, but this specific wording usually starts with recipient validation. I still check authentication when the failures are domain-wide, sudden, or clustered by sending IP, but I do not put DMARC first for a single-recipient 550 5.4.1 bounce.
Why it appears on O365 accounts
O365, now Microsoft 365, often has Exchange Online Protection in front of the mailbox environment. When directory-based edge blocking is active, the edge layer checks whether the recipient exists before accepting the message. If the address is missing, stale, or not visible to Exchange Online, the message is rejected before mailbox delivery.
This gets messy in hybrid environments. A recipient can exist on-premises, but Exchange Online still rejects the address if the proxy address has not synced, the accepted domain state is wrong, or the object type cannot be represented cleanly in the cloud directory. That is why this bounce can look intermittent: one person at a domain accepts mail while another person at the same domain fails.
Flowchart showing a message rejected during the Exchange Online recipient check.
Sender-side view
- Visible symptom: The sender sees a hard bounce with access denied language.
- Log pattern: Some recipients at the same domain still receive mail.
- Best action: Validate the address and suppress after repeated hard failures.
- Escalation path: Send the full NDR to the recipient's mail administrator.
Recipient admin view
- Visible symptom: Exchange Online blocks a recipient before mailbox delivery.
- Likely area: Accepted domains, recipient sync, or hybrid object mapping.
- Best action: Confirm the address exists in Exchange Online.
- Escalation path: Resync or repair the recipient object and accepted domain state.
How to triage it without guessing
I start with scope. If one address fails and other addresses at the same Microsoft 365 tenant receive mail from the same sending IP and domain, I treat the failing address as invalid or unsynced until proven otherwise. If every address at the domain fails, I move toward domain routing, policy, authentication, or reputation.
For a live sending test, the email tester is useful because it shows the actual authentication and sending-path result for a real message. It does not prove the recipient exists, but it removes a lot of sender-side uncertainty before you escalate the NDR.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After that, I compare failures against successful deliveries. The important question is not whether the destination is Microsoft 365. The important question is whether the same sending system can deliver to other recipients behind the same destination domain during the same time window.
- Collect the full NDR: Keep the remote server, timestamp, recipient, and message trace details.
- Compare sibling recipients: Test another known-good address at the same domain, without blasting a list.
- Check recent success: Look for delivered mail to the same domain on the same IP and envelope sender.
- Separate policy clues: Spam wording, rate-limit language, or many affected recipients changes the diagnosis.
- Escalate cleanly: Ask the recipient admin to verify the address object in Exchange Online.
|
|
|
|---|---|---|
One user | Invalid address | Validate and suppress |
Some users | Hybrid sync gap | Send NDR evidence |
All users | Domain or policy | Audit sending path |
Many domains | Sender reputation | Check blocklists |
Fast triage matrix
What senders should do
Because this is a permanent reject, I do not keep hammering the same address. A practical rule is one immediate hard bounce, one confirmed repeat from a later campaign or transactional attempt, then suppression unless the recipient or customer confirms the address is valid. That protects list quality and prevents a local recipient problem from turning into a broader sender reputation problem.
Suppression threshold for this bounce
A simple policy for handling repeated O365 550 5.4.1 recipient rejects.
First bounce
1
Pause and verify spelling before another attempt.
Repeat bounce
2
Treat the address as high risk and require evidence.
Confirmed pattern
3+
Suppress until the recipient admin confirms a fix.
Sibling success
Domain
Do not suppress the whole domain if other users deliver.
The strongest sender-side move is evidence, not volume. Keep the NDR, show that other recipients at the same domain are delivering, and ask the recipient admin to check the specific address. If you need broader context on related bounces, 550 5.4.1 handling covers the general workflow, and access denied meaning covers the wording itself.
Sender-side checklist
- Do validate: Check spelling, role alias changes, CRM imports, and recent form submissions.
- Do compare: Look for successful delivery to the same tenant during the same hour.
- Do suppress: Stop sending to the exact address after repeated hard rejects.
- Do not overreact: Do not block the whole recipient domain when sibling recipients are delivering.
What recipient admins should fix
If you administer the recipient tenant, this is where the real fix usually happens. Confirm the address exists in Exchange Online, then confirm Exchange Online sees the same primary SMTP address and aliases that the sender is using. In hybrid tenants, the on-premises object and the cloud object have to match closely enough for the edge layer to accept the message.
Microsoft 365 Exchange admin center accepted domains screen.
- Check the address: Confirm the exact recipient and aliases exist in Exchange Online.
- Check the domain type: Review whether the accepted domain is Authoritative or Internal relay.
- Refresh directory data: For a hybrid mailbox, change the SMTP proxy value, sync, then restore it.
- Check special objects: Mail-enabled public folders and dynamic groups need specific handling.
- Allow propagation: Directory-based edge blocking updates after directory changes, not instantly.
The cleanest recipient-side proof
The clean proof is a successful inbound test to the exact recipient after the directory fix. A successful test to a different address at the same domain proves the sender path works, but it does not prove the failed recipient object is fixed.
When authentication or reputation matters
I still check sender authentication when the bounce pattern grows beyond one address. If all recipients at a Microsoft 365 domain fail, or many Microsoft-hosted domains start returning access denied wording at the same time, recipient validation is no longer the only reasonable explanation. Then I check SPF, DKIM, DMARC, sending IP reputation, and blocklist (blacklist) status.
Suped is the best overall DMARC platform for this workflow because it gives one place to monitor DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and blocklist monitoring. In this specific O365 bounce case, Suped helps decide whether the sender has a real authentication or reputation issue, or whether the evidence points back to the recipient tenant.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
A quick domain health check is enough for a first pass across DNS and authentication. Ongoing DMARC monitoring is better when you need source-by-source reporting. If the delivery pattern looks reputational, blocklist monitoring helps catch domain and IP listings before they spread across campaigns.
Treat as recipient-side
- Single address: One recipient fails while other users at the domain deliver.
- Stable sending path: Same IP and envelope sender deliver elsewhere.
- NDR wording: The bounce points at recipient rejection, not spam scoring.
- Best owner: The recipient admin who can inspect Exchange Online objects.
Treat as sender-side
- Domain-wide failures: Every recipient at the destination fails.
- Many destinations: Multiple Microsoft-hosted domains reject at once.
- Auth failures: SPF, DKIM, or DMARC results show repeated failures.
- Best owner: The sender team that controls DNS and sending systems.
Views from the trenches
Best practices
Compare failed recipients with successful recipients at the same domain before escalating.
Keep NDR headers, timestamps, and remote server details for recipient-side investigation.
Use suppression rules for repeat hard bounces without removing the full recipient domain.
Check Microsoft 365 directory state before treating this as a sender reputation issue.
Common pitfalls
Assuming every access denied bounce is a blocklist or blacklist problem wastes time.
Retrying the same failed address repeatedly can damage sender quality signals.
Ignoring hybrid Exchange sync gaps leaves valid on-premises users rejected at the edge.
Escalating without the full NDR forces the recipient admin to guess from a vague code.
Expert tips
A gateway can pass through Microsoft's rejection, so inspect the remote server path.
Three-strike suppression is practical when the address validity remains uncertain.
Sibling delivery success is strong evidence against a complete domain-level block.
Recipient admins should test the exact address after fixing directory sync issues.
Marketer from Email Geeks says this bounce often looks intermittent because some recipients at the same Microsoft 365 domain continue to accept mail.
2023-05-09 - Email Geeks
Expert from Email Geeks says the error should not be treated as a normal user unknown response without checking the surrounding delivery pattern.
2023-05-09 - Email Geeks
The practical answer
The cause of 550 5.4.1 Recipient address rejected: Access denied AS(201806281) on O365 accounts is usually Exchange Online rejecting an invalid, missing, or unsynced recipient through directory-based edge blocking. Hybrid Exchange directory issues and accepted domain state are the most common reasons a recipient who looks valid to a human still fails at the Microsoft 365 edge.
For senders, the fix is careful triage: validate the address, compare sibling deliveries, suppress repeated hard failures, and pass the full NDR to the recipient admin. For recipient admins, the fix is in Exchange Online: verify the recipient object, repair sync or domain state, then retest the exact address. If the pattern becomes domain-wide or multi-domain, bring authentication and blocklist or blacklist checks into the investigation.
