550 5.4.1 Recipient address rejected: Access denied: what it means and who can fix it
This bounce comes from the recipient's Exchange Online tenant, not your SPF or DKIM. What 550 5.4.1 means, who can fix it, and what to send their admin.
On this page
A bounce that reads 550 5.4.1 Recipient address rejected: Access denied comes from the recipient's Microsoft 365 (Exchange Online) tenant and means that tenant did not accept the address you sent to. Microsoft's article on this NDR (opens in a new tab) describes it as an automated notification shown when the recipient's email address is invalid, generated when directory-based edge blocking in Exchange Online blocks the message. Microsoft addresses the fix steps to the email administrator in the recipient's organisation, not to the sender, so leave your SPF, DKIM and DMARC records alone for this one. What you can do is confirm the address and, if it is correct, hand the recipient's admin the information below.
What 550 5.4.1 means
550 is an SMTP reply code. RFC 5321 (opens in a new tab) lists it as "Requested action not taken: mailbox unavailable" with the examples mailbox not found, no access, or command rejected for policy reasons, and puts every 5yz reply in the permanent negative completion class, where the client should not repeat the exact request. 5.4.1 is a status code of the kind RFC 3463 (opens in a new tab) defines, structured as class, subject and detail: the first number says whether delivery succeeded, and the 5 class is a permanent failure that resending in the current form is unlikely to resolve; the middle number names the probable source; and the last number the precise condition. In that document, X.4.1 sits under network and routing status as "No answer from host". The text after the code is what to read for this bounce: Microsoft's NDR article (opens in a new tab) gives the meaning Exchange Online attaches to it, a recipient email address that is invalid.
Check your domain now
See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.
Why Exchange Online says Access denied
Directory-Based Edge Blocking (DBEB) (opens in a new tab) is the Exchange Online feature that rejects messages for invalid recipients at the edge of the service. A message to a valid address goes on through anti-malware, anti-spam and mail flow rules; a message to an address that does not exist is blocked before any of that filtering runs, and the sender gets a non-delivery report that reads 550 5.4.1 Recipient address rejected: Access denied. For a domain whose recipients are all in Exchange Online, DBEB is already in effect; in hybrid environments it only works when the domain's MX record points at Microsoft 365, so that mail reaches the service first.
What switches DBEB on is the accepted domain type. Microsoft's accepted domains page (opens in a new tab) describes two types. Authoritative delivers mail to addresses listed for recipients in Microsoft 365 and rejects mail for unknown recipients; setting it enables DBEB. Internal relay delivers to known recipients and relays mail for unknown ones to the organisation's own email servers. So the address you sent to is either not in that tenant's directory, or it exists somewhere the directory does not yet know about.
550 5.4.1 vs 550 5.7.1
Both codes start with 550; the text after the code is what differs. For 5.4.1, Microsoft's NDR article (opens in a new tab) names an invalid recipient address blocked by directory-based edge blocking, with the fix steps addressed to the recipient's administrator. For 5.7.1, Microsoft's article on that code (opens in a new tab) describes a security setting in your organisation or the recipient's that prevents the message from reaching the recipient, and notes that you typically cannot fix it yourself.
| 550 5.4.1 Recipient address rejected: Access denied | 550 5.7.1 | |
|---|---|---|
| Meaning Microsoft gives | the recipient's email address is invalid | a security setting in your organisation or the recipient's prevents delivery |
| What blocks it | directory-based edge blocking in Exchange Online | a security setting on either side |
| Who Microsoft addresses the fix to | the email administrator in the recipient's organisation | the recipient or the recipient's email admin |
The 550 5.7.1 guide explains how to read the text after that code from Gmail or Microsoft 365 and whether you or the recipient's admin must act.
If you are the sender
First, check the address by another channel. Google's bounce guide (opens in a new tab) lists the common typos worth ruling out: spelling errors, stray quotation marks, dots at the end of the address, and spaces before or after it. If the address turns out to be wrong, fix it and send again; no other action is needed.
If the address is right, Microsoft's NDR article (opens in a new tab) addresses its fix steps to the email administrator in the recipient's organisation. Send that admin, by another route, the full bounce text, the time you sent the message and the exact address you used. Do not change your DNS records for this code, and do not keep resending the same message: RFC 5321 (opens in a new tab) puts 5yz replies in the permanent negative completion class, where the client should not repeat the exact request. Once the admin confirms the address is in the directory, send the message again.
If you are the recipient's admin
Microsoft's NDR article (opens in a new tab) gives the steps to work through until the issue is fixed:
- Check the spelling of the recipient's email address in the NDR.
- Determine whether the issue affects only one recipient or everyone in the domain.
- If it affects all recipients in the domain, resync it: in the Exchange admin center, select Mail flow, then Accepted domains, select the affected domain, and switch its type from Authoritative to Internal relay, then back to Authoritative.
- If it is limited to one recipient with an on-premises mailbox in a hybrid environment and you use directory sync, reset the SMTP proxy address of that mailbox by changing it to a temporary address and then back, and allow up to 24 hours for DBEB to update.
- If the recipient is an on-premises mail-enabled public folder in a hybrid environment, verify the folder is synced to Exchange Online.
- If the recipient is an on-premises dynamic distribution group in a hybrid environment, create a mail contact in Exchange Online with the same external address; Microsoft notes that kind of group cannot be synced to Exchange Online.
Microsoft also recommends, when setting up an Exchange environment, temporarily setting the accepted domain type to Internal Relay, and changing it to Authoritative after all intended recipients are in Exchange Online and fully replicated, which blocks mail to addresses that are not there.
Check your own records anyway
Nothing on this page asks you to touch SPF, DKIM or DMARC for this bounce. While the recipient's admin works, though, it is a reasonable moment to confirm your own domain is in order for the next message. The free DemiSignal check reads the public DNS records of the domain you enter, with no account, changes nothing and sends no email. A DNS finding shows how your domain is set up; it does not show where a particular message landed.
Sources
- Microsoft Learn: fix NDR error 550 5.4.1 in Exchange Online (opens in a new tab)
- Microsoft Learn: use Directory-Based Edge Blocking to reject messages sent to invalid recipients (opens in a new tab)
- Microsoft Learn: manage accepted domains in Exchange Online (opens in a new tab)
- RFC 5321: Simple Mail Transfer Protocol (opens in a new tab)
- RFC 3463: Enhanced Mail System Status Codes (opens in a new tab)
- Microsoft Learn: fix NDR error 550 5.7.1 in Exchange Online (opens in a new tab)
- Google: fix bounced or rejected emails (opens in a new tab)
Tools for this
-
SPF, DKIM and DMARC check
Check the email records a domain publishes today and see what to fix first.
Frequently asked questions
Was my message blocked as spam?
No. Microsoft documents this NDR as directory-based edge blocking rejecting the message because the recipient address is invalid, and that happens before the anti-spam and anti-malware filters run.
Can the message be resent?
Yes, once the address is right. A 550 reply is a permanent negative completion that the client should not repeat as sent; after the recipient's admin fixes the address or you correct a typo, send the message again.
Why does my own SPF, DKIM or DMARC not matter here?
Because Microsoft documents this code as directory-based edge blocking rejecting an invalid recipient address, and addresses every fix step to the email administrator in the recipient's organisation. Nothing in those steps involves the sender's DNS.
Check your domain now
See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.