550 5.4.1 Recipient Address Rejected Access Denied

Do not index

550 5.4.1 Recipient address rejected: Access denied from Microsoft 365 means Directory-Based Edge Blocking rejected the address because it isn't a valid object in the recipient tenant, not because the message was spam-blocked.

A password reset, invoice, or sales follow-up can fail this way even when the sender's other mail is delivering normally. The useful next move is to establish how widely the rejection occurs, preserve the complete bounce, and put the fix with the person who controls the missing address or mail-routing configuration.

Table of Contents

What This 550 Bounce Means Separate acceptance from inbox placement How to Read the Sample Bounce Message Read the server fields together One Mailbox or Every Address at the Domain Use confirmed recipients to establish scope Assign the owner without discarding valid contacts What We Check First on This Bounce Start with evidence, not configuration changes Check the affected population before choosing a fix Accepted Domain and Directory Sync Failures Recognize settings the sender can't change Have the tenant administrator validate the mail-flow design What to Send the Recipient IT Team Copy this checklist into the support request Ask a question IT can answer Common Mistakes That Prolong the Bounce Stop applying reputation fixes to an address failure Don't make security changes without evidence Decide Who Should Fix the Next Attempt When to bring in an expert Does this rejection count toward the hard-bounce rate?Can DMARC aggregate reports show this failure?Why did this address work last year?

What This 550 Bounce Means

Say a sales follow-up goes to a Microsoft 365 address and immediately comes back with 550 5.4.1 Recipient address rejected: Access denied. The recipient hasn't ignored it, and the sender hasn't established that it landed in spam. Exchange Online refused delivery.

Microsoft's guidance for this exact rejection identifies Directory-Based Edge Blocking, or DBEB, as the mechanism that checks whether an address belongs to a valid directory object for an authoritative accepted domain. If Exchange Online can't resolve the recipient, it rejects the message at the edge.

Separate acceptance from inbox placement

A directory rejection isn't an inbox-placement result. The receiving service hasn't accepted the message for a valid mailbox, so subject-line changes and spam-folder checks don't address the failure.

That distinction matters when evaluating what email deliverability actually covers. Acceptance, routing, and inbox placement require different evidence and different remedies.

Typical explanations include:

A mistyped address. The intended person exists, but the submitted address doesn't match a valid mailbox or alias.

A departed employee. An address retained in the sender's CRM no longer exists in the receiving directory.

A changed mail environment. A migration or routing change leaves Exchange Online without the recipient information it needs.

Repeated automated sends won't create a missing directory object. They generate more failures, consume queue capacity, and distract support teams from the actual fix. The sender should preserve the evidence and pause automated attempts to the affected address while its validity is checked.

How to Read the Sample Bounce Message

A complete non-delivery report (NDR) shows which address failed and preserves the response returned during delivery. The example below is illustrative. Bracketed values are placeholders; the hostname follows a Microsoft protection-host pattern.

Failed recipient: recipient@example.com
Generating server: [host].mail.protection.outlook.com
Diagnostic information:
550 5.4.1 Recipient address rejected: Access denied
Remote Server returned:
'550 5.4.1 Recipient address rejected: Access denied'
Timestamp: [date and time, including time zone]
Sending IP: [sending IP from the original report]
Message-ID: [original message identifier]

Read the server fields together

The remote-server response records what the system refusing delivery returned. The generating server identifies the system that created the NDR, which may differ from the rejecting system. A Microsoft protection hostname identifies the receiving service involved, but does not, by itself, establish the cause.

The failed recipient shows the exact address Microsoft tried to resolve. The timestamp and time zone let an administrator search the right window. The Message-ID, including its original formatting, can help correlate the message with available logs.

The sending IP helps identify the route used for this message, especially if several applications send from the same address. If the diagnostic includes an AS(...) identifier, preserve it exactly. It is diagnostic text, not a public support-ticket number.

A cropped error line can hide the details needed to trace the rejection. Recipient-side message trace may not show a normal accepted-message record when rejection occurs at the edge, so keep the original NDR intact and compare its full wording with Microsoft's Exchange Online NDR reference.

One Mailbox or Every Address at the Domain

How far the 550 5.4.1 bounce spreads

Scope	Usual cause	Who fixes it	Sender next step
One address at the domain	Typo, departed employee, or missing proxy address	Recipient confirms the mailbox, or the sender corrects the address	Suppress that address and stop automated retries
Every address at one Microsoft 365 domain	Authoritative-domain configuration, directory sync, or MX without a correct accepted domain	Recipient IT	Send the full bounce and don't change sender authentication
Many unrelated domains	Sender relay, outbound connector, or DNS resolution	Sender or the sending platform	Trace the outbound path before list cleanup
Hybrid mailbox changed recently	On-premises object not yet visible to DBEB	Recipient directory-sync administrator	Allow the documented propagation window, then make a controlled retry

Use confirmed recipients to establish scope

For an example domain, example.com, a failure for one former employee while current coworkers receive mail points toward an address-specific problem. It doesn't justify suppressing everyone at the company. Conversely, failures for all confirmed-valid recipients suggest a broader accepted-domain, synchronization, or routing issue.

Microsoft's support guidance explicitly separates individual-recipient failures from domain-wide failures and notes that hybrid directory changes can take up to 24 hours to propagate fully through DBEB. After that documented window, a controlled retry is more useful than hourly automated attempts.

The scope is a triage signal, not proof by itself. A missing alias can affect one person whose primary mailbox works. A domain-wide migration issue can affect only the addresses present in a particular campaign, making an incomplete sample look like a collection of unrelated bad contacts.

Assign the owner without discarding valid contacts

The cost of picking the wrong owner is practical:

Misassigned to sender IT. Administrators rewrite authentication while the recipient object remains absent.

Misassigned to list operations. A team removes live contacts because a recipient tenant is temporarily misconfigured.

Misassigned to recipient IT. A sender with outbound relay failures asks unrelated organizations to repair working mail systems.

A licensing review is separate from recipient resolution. If the recipient administrator is also assessing mailbox capabilities, RDE Technologies' guide to when to upgrade from Plan 1 provides context for that decision, but a plan upgrade isn't a remedy for a missing SMTP address.

Confirm the affected population before cleaning a list or escalating. Existing delivery logs and recipient confirmation are better evidence than sending a fresh campaign to test a suspected outage.

What We Check First on This Bounce

Start with evidence, not configuration changes

Read the complete enhanced status text. Confirm that the response says Recipient address rejected: Access denied. A different response requires a different investigation; skipping this check can trigger unnecessary DNS edits or reputation work.

Confirm the exact address through another channel. Ask whether the mailbox or alias is live, whether the spelling is correct, and whether the person recently left. A phone call or support conversation can resolve an address mistake without involving infrastructure teams.

Check where the domain receives mail. Inspect its MX destination and note whether it points to Microsoft 365. MX identifies the receiving route, not whether the specific mailbox exists, so a correct destination doesn't establish recipient validity.

Check the affected population before choosing a fix

Compare failures within the same domain. Review existing delivery events from the same period, including successful sends. Use the scope table to decide whether the next owner is list operations, recipient IT, or the sending platform; don't create extra traffic just to establish that a domain is failing.

Inspect the contact's history. Check when the address entered the list, its source, and its last successful delivery. Email verification can help flag questionable addresses before another send, but it doesn't replace confirmation from the recipient or guarantee that a Microsoft directory object exists.

Investigate the outbound path when unrelated domains fail. Review the sender's outbound connector, relay configuration, DNS resolution, and provider logs or message trace. A cross-domain pattern warrants sender-side investigation rather than automatically treating every rejection as a bad contact.

For list operations, useful segments include confirmed invalid, recipient configuration under investigation, and sender routing incident. These categories prevent a single suppression rule from deleting valid contacts or repeatedly activating dead ones.

Don't warm the sending domain or cut campaign volume solely because this exact directory rejection appeared. Those actions may be appropriate for a separate reputation problem, but they won't repair a recipient object. Ignoring the distinction delays password resets, invoices, and replies while teams change settings that weren't responsible.

Accepted Domain and Directory Sync Failures

A Microsoft 365 tenant can accept mail for a domain while failing to resolve a particular address. The distinction matters: changing the domain's mail-flow configuration affects delivery across the domain, while correcting a missing directory object affects the recipient that cannot be resolved.

Status text	Typical tenant state	Meaning	Who acts
`550 5.4.1 Recipient address rejected: Access denied`	Authoritative accepted domain with DBEB	Address isn't a valid directory object	Recipient admin, or the sender if the address is wrong
`550 5.4.1 Relay Access Denied`	Server or DNS routing doesn't accept the domain	Relay or routing refusal, not a missing mailbox	Recipient mail-routing admin, or sender if many domains fail
`550 5.1.1 RESOLVER.ADR.RecipNotFound; Not found`	Can occur with Internal relay	Recipient can't be resolved inside the organization	Recipient admin

Recognize settings the sender can't change

An authoritative accepted domain tells Exchange Online that its recipient directory is the authority for that domain. An Internal relay domain supports a different mail-flow arrangement, such as routing some recipients to another mail system. Switching a domain to Internal relay changes where Exchange looks for recipients, so it can break working mail.

A domain's MX can point to Microsoft while the tenant's recipient configuration remains incomplete. Migration or directory synchronization problems can also leave valid recipients absent from the cloud directory. In either case, the sender reaches Microsoft, but Exchange cannot deliver to the intended address.

Have the tenant administrator validate the mail-flow design

Recipient IT should check:

Accepted-domain type. Confirm that it matches the organization's hosting and routing arrangement.

SMTP proxy addresses. Verify the exact rejected address, not just the user's display name or primary mailbox.

Groups and public folders. Check that mail-enabled objects and their required addresses are represented correctly.

Migration and synchronization state. Investigate failed or incomplete object updates rather than assuming the directory is current.

Microsoft documents a procedure that switches an accepted domain from Authoritative to Internal relay and back to resynchronize configuration. Only the tenant administrator should consider it, after checking the intended hybrid routing and connector behavior. A sender should not request a domain-type change as a general fix.

For broader organizational context, Kogifi's overview of AI Copilots in the Microsoft 365 ecosystem discusses applications within Microsoft 365. Copilot capabilities do not determine whether Exchange accepts a domain or resolves a recipient.

Once recipient IT confirms the object and configuration are correct, send a controlled test. If it bounces again, diagnose the new response on its own terms.

What to Send the Recipient IT Team

Write a short, factual handoff with the five items below. It lets the recipient administrator identify the failed attempt and determine whether the problem affects one address or the domain.

Copy this checklist into the support request

Full bounce: Attach the complete non-delivery report as text or its original message file.

Exact recipient address: Copy the address as submitted so IT can check the recipient record.

Date, time, and time zone: Include these to identify the relevant investigation window.

Sending service or sending IP: Identify the outbound source used for the attempt.

Message-ID: Include the original value for correlation with available mail logs.

Ask a question IT can answer

Ask IT to confirm whether the exact address is a valid recipient, whether it is listed as an SMTP proxy address, and whether a migration or directory change could affect it. State whether other confirmed recipients at the same domain succeeded or failed during the same period.

Avoid requesting whitelisting or changes to spam filtering. Those actions do not confirm that the destination address exists. If one mailbox is affected, the recipient or sender may need to correct that address. If every address at the domain fails, the recipient's Microsoft 365 administrator should investigate the tenant configuration.

If the recipient confirms the employee has left, correct or remove the contact. If IT confirms the mailbox exists and a controlled retry returns the same response, ask them to review the recipient record and relevant directory configuration.

Until the address accepts mail, messages such as password resets, invoices, and pipeline updates will remain undelivered.

Common Mistakes That Prolong the Bounce

A deleted mailbox will not be restored by rewriting SPF records. Match the fix to the object that failed, or the bounce will continue while teams change unrelated settings.

Stop applying reputation fixes to an address failure

Buying warmup or rewriting content. Neither creates a valid recipient. The message still has nowhere to go.

Leaving departed employees in automated journeys. The platform will keep attempting an address that cannot accept mail. Use email bounce management to handle permanent recipient failures without stopping messages to valid contacts.

Using a broad suppression rule to mask routing failures. A rule that suppresses more than the confirmed invalid address can hide a sender-routing incident. Review the affected events before changing suppression logic.

A hard-bounce percentage can flag a problem, but it cannot identify who owns the fix. Separate invalid-address events from recipient-tenant incidents and sender-routing failures before changing lists or infrastructure.

Don't make security changes without evidence

Asking the recipient to mark the sender as safe. That preference does not create a valid directory recipient, and it distracts from confirming the mailbox.

Changing authentication because the response says “Access denied.” SPF, DKIM, and DMARC matter for legitimate mail, but this wording alone does not show that authentication failed. An unnecessary DNS change can create another delivery problem.

Retrying unchanged messages automatically. Repeated attempts add failed events without changing the destination. Resume after the address is corrected or the recipient confirms its repair.

Email authentication setup and support address authentication problems, not whether a recipient exists. Keep those investigations separate so an address failure does not trigger unrelated infrastructure changes.

Decide Who Should Fix the Next Attempt

The bounce record can help separate a contact problem from a platform-wide incident. In Klaviyo or HubSpot, check the event type attached to the bounce, then compare it with the full NDR and the affected recipients. The platform's label helps with reporting; it does not, by itself, identify who can fix the rejection.

When to bring in an expert

Escalate when Microsoft 365 rejects confirmed-valid addresses across unrelated domains, when a migration is approaching, or when teams cannot establish who owns the bounce. Those cases call for a review of routing, evidence collection, and incident ownership, rather than another address correction.

MailAdept offers a free deliverability audit for teams that need help assessing broader routing or deliverability issues. Inbox placement, open rates, performance, and freedom from spam filtering are not guaranteed.

Does this rejection count toward the hard-bounce rate?

Check how your sending platform records the event. Keep the NDR with the bounce record so list operations can distinguish an invalid contact from a recipient-configuration incident.

Can DMARC aggregate reports show this failure?

DMARC aggregate reports cover authentication and policy evaluation, not the full details of an SMTP recipient rejection. For a DBEB refusal, use the NDR and sending-service delivery logs. Use authentication reports to investigate authentication issues separately.

Why did this address work last year?

Past delivery only confirms that the address worked at that time. The employee may have left, an alias may have been removed, or the organization may have changed its mail environment. Ask recipient IT to confirm whether the address is still configured as a valid recipient.

What the evidence shows	Who should take the next step
One address fails; other addresses at the domain work	The sender should verify the address; recipient IT can confirm whether the mailbox or alias exists.
Every address at the domain fails	Recipient IT should check the Microsoft 365 tenant's accepted-domain and directory configuration.
Failures affect unrelated domains	The sender should investigate its outbound route and escalate if the cause remains unclear.

Resume sending after the responsible team confirms the correction, then check the result of a controlled attempt.