Delivery errors

Question

Hi,

My senders keeps getting repeated delivery error reports from my mail system. One of the trusted senders sent me “If you receive this message, then it  means that something is  wrong. While you are  obviously able to receive mail,  your mail  system has been  regularly reporting  that your account did not  exist, or that you were otherwise permanently unable to receive mail.”

• The first error was reported on 2026-02-26.
• Since then, a total of 5 delivery errors have been received.

Could you please help me so the senders stop getting this error?

Regards,

Answer 1

Hi Haytham Fathy, 

Welcome to Microsoft Q&A Forum! Have a good day and I hope you're doing well!

Based on my research, this type of issue typically occurs when a Non‑Delivery Report (NDR) is generated at a specific stage of the mail transport pipeline, even though delivery may appear successful from the end‑user perspective. 

To properly identify the cause, we’ll need to confirm exactly where the NDR is being generated. 

Could you please help double‑check the following initial items? 

1. Please review the Message Tracking Logs using: 

Get-MessageTrackingLog 

We need to confirm: 

• Whether the affected message shows DELIVER (successfully delivered to the mailbox) 
• Or if there is a FAIL / DSN event 
• The exact server name generating the event

Reference: Use the Exchange Management Shell to search the message tracking logs

Message tracking logs are the authoritative source for determining where in the transport pipeline the NDR was created. 

2. Please ask one of the affected senders to share the complete NDR message, especially: 

• Diagnostic information for administrators 
• The Enhanced SMTP status code (e.g., 5.1.1, 5.2.0, 4.4.7) 
• The FQDN/server name that generated the NDR 

The server listed in the NDR indicates which system generated the error and should be the focus of investigation. 

Reference: DSNs and NDRs in Exchange Server

3. Please confirm that the recipient domain is configured as: Authoritative (if the mailbox resides in your Exchange organization) 

If the domain is misconfigured (e.g., set as Internal Relay when it should be Authoritative), Exchange may return “recipient does not exist” errors even if the mailbox exists. 

You can verify using: 

Get-AcceptedDomain 

Reference: Procedures for accepted domains in Exchange Server

4. Please verify no rule is rejecting or generating NDRs. 

You can check using: 

Get-TransportRule 
Get-TransportRuleAction 

Reference: Use the Exchange Management Shell to view the available actions for mail flow rules

I hope the above information helps us narrow down the possible cause of the issue. You may send the requested information through the private message I shared earlier, so we can review the details more closely and determine the most appropriate troubleshooting approach. 

Any updates would be greatly appreciated. 

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".    

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.  

Answer 2

Delivery error reports like the one described are generated when the sender’s system receives Non‑Delivery Reports (NDRs) from the recipient side. The key to stopping them is to identify and fix the underlying cause indicated in those NDRs.

Use this process:

1. Collect the exact NDR details
   • Ask the trusted sender to forward one of the failure reports in full, including the section often labeled “Diagnostic information for administrators.”
   • Look for:
     • SMTP status code (for example, 550 5.x.x, 4.x.x, etc.).
     • Text such as “user unknown,” “mailbox does not exist,” “recipient deferred,” or references to spam/blacklist systems.
   • These details explain why the system is sometimes reporting that the account does not exist or is permanently unable to receive mail.
2. Check for address or directory issues
   • If the NDR text indicates the recipient address is invalid, ambiguous, or not found (for example, messages similar to 550 5.1.x or “ambiguous address”), verify that the mailbox object and email address are correctly configured in the directory and mail system.
   • In environments using directory synchronization, misconfigured or stale objects in Azure AD or the local directory can cause NDRs such as 420 4.2.0 RESOLVER.ADR.Ambiguous or similar. In such cases, escalation to Microsoft support is required to correct the synchronized recipient object.
3. Verify the mailbox and aliases
   • Confirm that the primary SMTP address and any aliases used by senders still exist and are active.
   • Ensure the mailbox has not been removed, disabled, or renamed in a way that would intermittently cause “does not exist” responses.
4. Review any forwarding or rules on the mailbox
   • If the mailbox has forwarding rules or transport rules that redirect messages to another address, and that target address is invalid, senders can receive NDRs even though some mail appears to arrive.
   • Ask the sender if their NDR mentions a different final recipient or forwarding address; if so, correct or remove that forwarding configuration.
5. Inspect the error pattern and timing
   • Since only some messages fail, compare successful vs. failed messages:
     • Are failures tied to specific sender domains or systems?
     • Are failures associated with large attachments or particular content?
   • If the NDR mentions attachment size or message size limits, reduce attachment size or use cloud sharing and resend.
6. If the NDR references spam/blacklist or blocking
   • If the error text includes terms like “blocked,” “listed in,” or references to spam lists (for example, “spamhaus,” “spamcop”), the sender’s system or IP may be treated as spam.
   • In that case, the sender must work with their own email provider or admin to improve their reputation or request delisting, as recommended for senders whose messages are blocked by filters.
7. Use Microsoft support if the recipient is in Microsoft 365/Exchange Online
   • If the mailbox is hosted in Microsoft 365/Exchange Online and the NDR codes resemble those documented for misconfigured synchronized recipients (for example, 550 5.7.12, 550 4.4.7, 420 4.2.0 with resolver messages), open a support case with Microsoft so they can inspect and correct the recipient object and routing.
8. After fixing the cause, confirm with the sender
   • Once configuration or directory issues are corrected, ask the sender to send several test messages and confirm they no longer receive new NDRs.
   • Old NDRs will not disappear, but no new ones should be generated.

Because the exact SMTP error text is not provided, the next concrete step is to obtain one full NDR from the sender, read the “Diagnostic information for administrators” section, and then apply the corresponding fix (address/directory correction, rule/forwarding fix, or sender‑side reputation/delisting) as outlined above.

---

References:

• Failed delivery messages from the postmaster at outlook.com, microsoft.com, or service.microsoft.com
• "550 5.7.12," "550 4.4.7," or "420 4.2.0" NDR when a user can't receive email messages through EOP in Office 365 Dedicated/ITAR
• Sent email in Outlook.com comes back "delivery failed"
• Sender Support in Outlook.com