# Fix 550 5.4.1 Recipient Address Rejected > The 550 5.4.1 error means Exchange Online rejected the recipient as invalid. Here's how to fix DBEB, accepted domains, and SPF/DKIM/DMARC issues. **The 550 5.4.1 "Recipient Address Rejected: Access Denied" error means the recipient's Exchange Online server refused your message because it could not validate the destination address — most often because Directory-Based Edge Blocking (DBEB) flagged the address as unknown, or because your sending domain failed authentication checks.** Check the recipient address first, then verify your [SPF](/tools/spf), [DKIM](/tools/dkim), and [DMARC](/tools/dmarc) records pass cleanly. ## What the 550 5.4.1 error actually means The full NDR typically reads: > `550 5.4.1 Recipient address rejected: Access denied. AS(201806281)` This is an Exchange Online Protection (EOP) response. The `AS(201806281)` suffix is a Microsoft internal diagnostic tag — not a separate error code — and confirms the rejection happened at the EOP perimeter before the message ever reached a mailbox. **Two distinct problems produce this NDR:** 1. **Invalid or unresolvable recipient** — EOP's Directory-Based Edge Blocking (DBEB) is enabled by default on Authoritative domains. If the destination address does not exist as a valid object in Entra ID (formerly Azure Active Directory), DBEB drops the message at the network edge. 2. **Sender authentication failure** — The recipient's mail flow rules, anti-spam policies, or connector restrictions rejected the message because your domain lacks valid [SPF](/tools/spf), [DKIM](/tools/dkim), or [DMARC](/tools/dmarc) records, or because your sending IP is on a blocklist. Unlike a soft bounce, this is a permanent `5xx` rejection — the message will not be retried. ## Step-by-step fix for the 550 5.4.1 error ### Step 1: Confirm the recipient address exists Start here. A typo, a deleted mailbox, or an address that was never provisioned all trigger the same NDR. Verify the address directly with the recipient or their Microsoft 365 admin. In Exchange Online, go to **Exchange admin center > Recipients > Mailboxes** and confirm the address appears. If the recipient is in a hybrid environment (Exchange on-premises + Microsoft 365), the mailbox must be synced to Entra ID via Azure AD Connect. A sync lag or missed object will cause DBEB to treat the address as invalid even though the mailbox exists on-premises. ### Step 2: Check the MX record and accepted domains If the recipient's domain is registered in Microsoft 365 as an Authoritative accepted domain, the MX record must point to Exchange Online Protection. The correct MX value follows the format: `-com.mail.protection.outlook.com` (priority 0) ![Verify the recipient domain's MX and accepted domains](/images/figures/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied-fig1.webp) *Correct MX and SPF records for a Microsoft 365 domain — both must be in place for EOP to route and authenticate mail.* Use the [MX lookup tool](/tools/mx) to confirm the record is published and resolving. If the MX points somewhere unexpected, Exchange Online may not be receiving the domain's mail at all, which means DBEB will reject any message as undeliverable. To resync DBEB after fixing a domain or address, open the **Exchange admin center**, go to **Mail flow > Accepted domains**, select the affected domain, temporarily switch it from **Authoritative** to **Internal relay**, save, then switch it back to **Authoritative** and save again. This forces EOP to re-query the directory. ### Step 3: Audit your sender authentication If the recipient address genuinely exists and the MX is correct, the rejection is likely a sender-side authentication failure. Run a full check with the [Email Security Score](/tools/email-security-score) tool to surface missing or broken records at a glance. **SPF:** Your DNS must include a TXT record that authorizes your sending infrastructure. For Microsoft 365 as the sender, the minimum valid record is: ``` v=spf1 include:spf.protection.outlook.com -all ``` Use the [SPF checker](/tools/spf) to confirm the record is present and that you are not exceeding the 10 DNS-lookup limit. **DKIM:** Enable DKIM signing in the **Exchange admin center > Email authentication** (or **Defender portal > Email & collaboration > Policies & rules > Email authentication settings**). Once enabled, two CNAME records need to be published in your DNS pointing to `selector1._domainkey..onmicrosoft.com` and `selector2._domainkey..onmicrosoft.com`. Verify with the [DKIM checker](/tools/dkim). **DMARC:** Publish at minimum a monitoring record so receiving servers can see your policy intent: ``` v=DMARC1; p=none; rua=mailto:reports@yourdomain.com ``` Review incoming [DMARC reports](/resources-post/how-to-understand-dmarc-reports) to identify any unauthenticated streams, then progressively tighten to `p=quarantine` and `p=reject`. See [DMARC reject vs quarantine](/resources-post/dmarc-reject-vs-quarantine-whats-the-difference) for a guide on timing the transition safely. ### Step 4: Check blocklists If authentication is clean but rejections continue, your sending IP or domain may be on a blocklist that the recipient's organization references. Use the [blocklist checker](/tools/blocklist-checker) to scan major blocklists. If listed, follow the blocklist operator's delisting process — Microsoft 365's anti-spam policies can reference third-party reputation data in addition to Microsoft's own lists. ### Step 5: Contact the recipient's admin After ruling out the above, the issue may be a deliberate tenant-level restriction: mail flow rules that restrict inbound senders, a safe senders list that your domain is not on, or a connector that only accepts mail from specific IP ranges. Ask the recipient's Microsoft 365 admin to: - Confirm your domain is not blocked under **Exchange admin center > Mail flow > Rules**. - Add your domain to their allowed senders list if their policy requires allowlisting external domains. - Check their **Connection filter policy** in Microsoft Defender to see if your IP is blocked. --- ## Common issues with the 550 5.4.1 error ### Why is DBEB rejecting a valid mailbox? Directory-Based Edge Blocking queries Entra ID in real time. If a mailbox was recently created, migrated from on-premises, or had its proxy addresses changed, the new address may not have propagated to EOP yet. Propagation typically completes within one hour, but can take longer. In the meantime, the DBEB toggle (Authoritative → Internal relay → Authoritative in **Mail flow > Accepted domains**) forces an immediate re-query. In hybrid deployments, DBEB also rejects mail sent to on-premises mail-enabled public folders, because public folders are not synced to Entra ID by default. The fix is to enable **Exchange Mail Public Folders** in Azure AD Connect's optional features, or to switch the accepted domain to Internal relay so EOP passes the message on-premises rather than resolving recipients itself. ### Why does the error happen only with certain senders? When the NDR only arrives from specific senders — not all external mail — the problem is almost always sender authentication or reputation. The recipient's Microsoft 365 tenant may have a mail flow rule or anti-spam policy that requires SPF/DKIM pass from senders in a particular IP range, or that blocks domains with a `p=none` DMARC policy. Check the [Email Security Score](/tools/email-security-score) for the sending domain and confirm SPF, DKIM, and DMARC are all publishing correctly. ### Why does 550 5.4.1 appear after a domain migration? When a domain is moved from one Microsoft 365 tenant to another — or migrated from a third-party provider — the accepted domain entry and mailbox objects must both be in the new tenant before EOP will accept mail. If the MX record is updated before the mailboxes are provisioned, every inbound message hits DBEB and bounces. Complete the mailbox migration and run the DBEB toggle before updating the MX record, or set the domain to Internal relay temporarily during the cutover window. ### What if the recipient's admin can't find the block? Microsoft 365 logs delivery events in **Exchange admin center > Mail flow > Message trace**. The recipient's admin can run a message trace filtered to the sender's domain and the rejection time to see exactly which rule, policy, or DBEB check triggered the NDR. The diagnostic output includes the specific EOP rule name, which makes root-cause identification straightforward. --- ## Frequently asked questions ### Is 550 5.4.1 always a Microsoft 365 / Exchange error? No, but it is most commonly associated with Exchange Online Protection. Other platforms use similar `5.4.x` codes with "access denied" language, but when the NDR includes `AS(201806281)` or a hostname ending in `.protection.outlook.com` or `.eop-*.prod.protection.outlook.com`, the rejection is definitively from EOP. Other MTAs may use `550 5.4.1` to indicate connector authorization failures or relay restrictions — the diagnosis differs depending on the receiving server. ### Does fixing SPF alone resolve the 550 5.4.1 error? It depends on which check triggered the rejection. If DBEB is the cause, fixing SPF has no effect — DBEB validates the recipient, not the sender. If the rejection is an authentication-based policy on the recipient tenant, SPF may help, but DKIM and DMARC alignment together are more reliable. Check [what DMARC, DKIM, and SPF each do](/resources-post/in-depth-guide-to-understanding-and-implementing-dmarc-and-dkim) to understand which record addresses which failure mode. ### Will the sender know their message was rejected? Yes. A `550` permanent failure generates an NDR (non-delivery report) that is returned to the sender's outbox. The NDR includes the specific error text, the rejecting server's hostname, and — in Exchange Online — the diagnostic code (such as `AS(201806281)`). The recipient never receives the message and does not receive a notification. ### How long does it take for a DBEB fix to take effect? After toggling the accepted domain type (Authoritative → Internal relay → Authoritative) in the Exchange admin center, EOP re-queries Entra ID within minutes. For hybrid sync issues via Azure AD Connect, the default sync cycle is 30 minutes; you can force an immediate sync with `Start-ADSyncSyncCycle -PolicyType Delta` in PowerShell. New addresses provisioned in Microsoft 365 directly (cloud-only) are generally recognized by EOP within an hour. ### Does this error affect email deliverability scores? Repeated 550 rejections from your sending domain can degrade your [domain reputation](/tools/domain-reputation) over time, particularly if you are sending bulk or transactional mail. High bounce rates signal to mailbox providers that your list hygiene or authentication is poor. Address the root cause quickly, and monitor your [Email Security Score](/tools/email-security-score) to confirm your sending configuration stays clean. ## Related reading - [How to understand DMARC reports](/resources-post/how-to-understand-dmarc-reports) - [DMARC reject vs quarantine: what's the difference](/resources-post/dmarc-reject-vs-quarantine-whats-the-difference) - [How to fix the 550 5.1.1 server temporarily unavailable error](/resources-post/how-to-fix-550-5-1-1-server-temporarily-unavailable) - [In-depth guide to DMARC and DKIM](/resources-post/in-depth-guide-to-understanding-and-implementing-dmarc-and-dkim) - [How to flush DNS cache](/resources-post/how-to-flush-dns-a-comprehensive-guide-for-clearing-dns-cache-on-multiple-operating-systems)