Troubleshooting Email Delivery Failures in Exchange Online

When an internal user’s email to an external recipient fails to deliver, Exchange Online will usually return a Non-Delivery Report (NDR) (also called a bounce message) to the sender. This guide provides an easy step-by-step approach to identify common causes of such failures and resolve them. It includes troubleshooting steps for both users and administrators, as well as a reference of common NDR error codes and their meanings.

• • Incorrect or Non-Existent Email Address: A simple typo or an address that doesn’t exist will cause a bounce. Exchange Online will report a bad destination mailbox address error if the address is incorrect. Always double-check that the recipient’s email is spelled correctly and is up-to-date.

• • Recipient’s Mailbox is Unavailable: If the external recipient’s mailbox is full, disabled, or non-operational, the message might not be delivered. A full mailbox or temporarily offline server causes a soft bounce, meaning the delivery failed temporarily. In such cases, you might receive an NDR indicating the mailbox can’t accept the message (e.g., mailbox quota exceeded).

• • External Server or DNS Issues: Sometimes the recipient’s email server isn’t reachable or their domain’s DNS records are misconfigured. Exchange Online could try resending for a period and eventually give up with an NDR like “Message expired” (after 24-48 hours) if the destination never responded. This often points to an issue on the receiving side (server down, incorrect MX records, etc.).

• • Sending Limits or Security Policies Triggered: Office 365 has sending limits and security measures. For example, if an account sends an unusually high volume of emails, it might be temporarily blocked for suspected spam (to protect the service). Also, if your organization or the recipient’s organization has policies (transport rules) restricting who can send to certain addresses (like distribution lists that only accept internal emails), your message can be rejected with an “authorized sender” error.

• • Spam or Filter Rejection: The email could be blocked by spam filters on either side. Exchange Online’s outbound filter might block content deemed spam or malicious, or the recipient’s email system might reject the message due to sender reputation, SPF/DKIM failures, or content. For example, an NDR with error code 5.7.23 indicates the recipient’s server rejected the mail because of an SPF check failure (your organization’s SPF record might be misconfigured). Similarly, the recipient’s server might block your organization’s email domain or IP if it’s on a blocklist.

• • Attachment Size or Type Issues: Sending very large attachments can lead to a bounce if the message exceeds size limits on the recipient’s end. Many email providers reject emails over a certain size. In such cases, you’d see an NDR indicating the message is too large. (For instance, a “552 5.3.4 message size limit exceeded” error). Likewise, certain attachment types might be blocked by security policies.

Understanding the reason behind the failure is key to resolution. The NDR received usually contains a status code and a brief explanation. Next, we’ll cover what steps an email sender (user) can take, followed by administrator-level diagnostics and fixes.

---

Step-by-Step Troubleshooting for Users

• • Step 1: Review the NDR (Bounce Message)

    When you receive a bounce email, read the User Information section. It often states what went wrong in plain language. For example, it might say “The email address you entered couldn’t be found” or “Message size exceeds limit.” Note any error codes (like 5.1.1 or 5.7.1) mentioned.

    Step 2: Verify the Recipient’s Email Address

    One of the first things to check is the recipient’s address. Make sure there are no typos and that the address is current. An NDR with code 5.1.1 or 5.1.10 usually means the address was not recognized by the destination server. If the address is incorrect, fix it and try sending again.

• • Step 3: Check for Attachment or Size Issues

    If your email had a large attachment or many recipients, consider the possibility that it was rejected due to size or distribution. Try sending a simpler email (e.g., just text, no attachments) to the same recipient. If that goes through, the original message may have been too large or triggered a limit. In case of large files, use a cloud sharing link instead of attachment.

• • Step 4: Read the NDR for Guidance

    NDR messages often include a “How to fix it” section with suggestions. For example, if the error was “recipient’s mailbox full,” the suggestion might be to wait until the recipient frees up space. If it says you’re not allowed to send to the recipient, it could be a policy issue (the recipient’s system rejects outside emails) – in that case, you may need to contact the recipient by other means to let them know, or have your administrator reach out to theirs.

• • Step 5: Try Sending Again or Later

    For transient problems (like a busy server or DNS issue), you might receive a delayed delivery notice first. If the NDR indicates a timeout or “message expired” (4.4.7), it suggests the recipient’s server couldn’t be reached in time. You can simply wait and try to resend later. Temporary glitches often get resolved, allowing a future attempt to succeed.

• • Step 6: Contact Your Administrator if It Persists

    If you’ve verified the address and retried, but the email still bounces (or the NDR suggests something you can’t fix, like “Access denied, bad outbound sender”), it’s time to involve your mail administrator or IT support. Provide them with the exact error message and code from the NDR – this information is crucial for deeper troubleshooting.

Tips for Users:

• • Use Outlook on the Web (OWA) for comparison: If you normally send email via Outlook desktop and suspect a client issue, try sending the email through Outlook on the Web. This helps rule out local configuration problems. (If it works on OWA, your Outlook app might need troubleshooting.)

• • Check Sent Items and Drafts: Ensure the message actually left your outbox. If it’s sitting in Drafts or Outbox, it may not have been sent at all (due to client-side issues). An NDR confirms the message did leave your mailbox but bounced back.

• • Look at NDR Details: In the bounce email, there is often a section “Diagnostic information for administrators” with technical details. While this is intended for IT staff, you can sometimes glean info like which server rejected the email and why. For instance, it may show the external server’s response like “550 5.7.1 SPF check failed” or “550 5.2.2 Mailbox full”. Don’t worry if it’s too technical – pass it to your admin.

• • Spam Content Check: If your email was bounced due to content (though rarely is it explicitly stated), consider if your message might have looked like spam (certain phrases or links). Adjusting the wording or removing suspicious attachments and trying again could help. (Your admin can confirm if your account was blocked for sending spam, which can happen if a mailbox is compromised.)

By following the above steps, many user-side issues can be resolved (especially address errors or message content issues). If not, the administrator will need to investigate further using admin tools.

---

Step-by-Step Troubleshooting for Administrators

Check Microsoft 365 Service Health: Before deep diving, ensure there isn’t a broad email service issue. Go to the Microsoft 365 Admin Center and check Service Health for Exchange Online. If there’s a known service degradation or outage affecting mail flow, Microsoft would be working on it, and that could explain external delivery issues. In such cases, advise users that service is degraded and monitor the health status.

1. 1. Use the Exchange Online Troubleshooter: Microsoft 365 provides an automated Email Delivery Troubleshooter for admins. In the Microsoft 365 Admin Center, navigate to the Troubleshooting or Support section and look for “Troubleshoot Email Delivery”. Enter the sender’s and recipient’s email addresses and run the tests. This diagnostic can catch common problems and misconfigurations and suggest fixes automatically.
   2. Run a Message Trace: The message trace tool is one of the most powerful ways to investigate mail flow. In the Exchange Admin Center (under Mail flow > Message trace), run a trace for the specific message or sender/recipient around the time of the issue. Look for the problematic message in the results:
      – If the trace shows the message was “Delivered” to the external party, then technically Exchange Online handed it off successfully. A delivered status means the issue might be on the recipient’s side (perhaps delivered to their spam folder or dropped by their server).
      – If the trace shows “Failed” or “Pending/Deferred”, examine the details. By selecting the message, you can see an explanation of what happened and a suggested “How to fix it” in many cases. The trace detail will include the SMTP status code and error text that the system encountered.
      – If no trace result is found, ensure you search the correct timeframe and that the email was sent as reported. (Trace by default covers the last 48 hours, but you can extend the range or run an extended trace for up to 90 days of history, though older traces come as a downloadable CSV.)
   3. Interpret the Error and NDR Code: Using the information from the message trace or the NDR (which the user hopefully provided), identify the error code and message. Refer to the Common NDR Error Codes section in this guide for quick insight. For a deep dive, Microsoft’s documentation lists many specific SMTP codes and their causes in Exchange Online. For example:
      – Bad address (5.1.1): Likely user error – verify if the address exists.
      – Relay or DNS failure (5.4.1, 4.4.7): Could be an external domain issue – you might need to check DNS or contact the recipient’s admin.
      – Spam-related or blocked (5.1.8, 5.7.50x): The sending account might be compromised or was sending bulk mail. If so, Microsoft may have temporarily blocked the account from external sending. You should scan the user’s system for malware, reset their password (in case of compromise), and then use the Exchange admin center or Microsoft 365 security portal to remove any sending block on the account. Microsoft might require you to contact support to re-enable a banned sender.
      – Not authorized (5.7.1, 5.7.133-134): This indicates the recipient’s side is rejecting the mail due to policy (maybe the recipient is a group that only accepts internal emails). In such cases, the solution lies with the recipient’s email administrator to allow external senders. As the sending admin, you may need to inform your user that the recipient must adjust their settings or provide an alternate contact method.
      Use Microsoft’s NDR diagnostic tool if needed: In the Microsoft 365 Admin Center, there’s a feature to input the NDR code for more info. It can give tailored guidance on that specific error (for instance, it might direct you to a knowledge article like “Fix error code 5.4.1” with detailed steps).
   4. Verify Your Organization’s Mail Settings: If many users experience external delivery issues, check if there’s any configuration on your side:
      – Outbound Connectors: In Exchange Online, no connector is needed for general external sending (it uses Microsoft’s default route). However, if you have a Hybrid setup or use a third-party email gateway, an improperly configured Send Connector or partner connector could cause external delivery to fail. Validate connectors using the built-in tool or PowerShell. A misconfigured connector can result in “Relay Access Denied” errors or mail loops.
      – Transport Rules: Review your mail flow rules to ensure none are unintentionally blocking or redirecting external emails. For instance, a rule that restricts external forwarding or adds headers shouldn’t stop delivery outright (unless misconfigured).
      – DNS Records: Confirm that your organization’s DNS settings (MX, SPF, DKIM) are correct. While these primarily affect inbound mail and recipient-side processing, an incorrect SPF record can lead to external servers rejecting your messages (SPF hard fail). Make sure SPF includes all your sending IPs (Microsoft 365 and any other mail sources). An up-to-date SPF/DKIM/DMARC setup improves your chances of delivery and prevents rejections due to authentication failures.
   5. Check Sender’s Account Status: If the NDR or trace suggests the sender was blocked (for example, 5.1.8 Access denied, bad outbound sender or any 5.7.50x spam errors), go to the Security & Compliance Center (or Exchange admin security settings) and check for alerts about that mailbox. Microsoft 365 might have flagged the account for sending outbound spam. Remove any user from blocked senders list if present, after ensuring the account is secure. Also verify the user hasn’t hit any legitimate sending limits (e.g., trial tenants have low external recipient limits).
   6. Test and Follow Up: After any fixes (correcting addresses, adjusting configurations, unblocking accounts, etc.), have the user resend the email. Monitor the message trace again or ask the user to confirm if the email goes through. If the problem persists with a specific external domain despite everything on your side being normal, consider reaching out to the recipient’s mail administrator – their server may be rejecting your mails (the reason should be in the NDR). You can also attempt to send a test message from a different internal account to the same recipient to see if it’s a sender-specific issue or affects all senders in your org.
   7. Utilize Support Resources if Needed: If you’ve exhausted your troubleshooting and can’t identify the cause, you may open a support case with Microsoft. Provide them with message trace results and NDR details. Microsoft can help if it’s an issue on the Exchange Online side or give insight if your domain/IP is on any of their internal block lists beyond your control.

Common NDR Error Codes and What They Mean

When an email bounces, the NDR will include an SMTP status code (also known as an enhanced delivery status code). Below is a list of some common NDR codes in Exchange Online and their typical meaning:

NDR Code	Description	Meaning / Possible Cause
550 5.1.1	Bad destination mailbox address	The recipient’s email address is invalid or not found. Often caused by typos or an address that no longer exists on the destination server. The sender should verify the address and try again.
550 5.1.10	Recipient not found	Similar to 5.1.1 – the specified recipient’s address (particularly the domain) doesn’t exist in the recipient’s system. This can happen if the email was correct before but the external account was removed or changed. Double-check the address spelling and existence.
550 5.1.8	Access denied, bad outbound sender	Exchange Online blocked the sender’s account from sending externally. This typically happens if the account was detected sending spam (possibly due to a compromised account). Admin intervention is required to secure and unblock the account.
550 5.2.2	Submission quota exceeded	The sender has exceeded sending limits. Office 365 throttles users who send an unusually large number of messages or recipients in a short time. This is often a sign of a compromised account or an automated sending gone awry. The user should reduce sending volume and an admin may need to confirm the account’s security.
450 4.4.7	Message expired (Deferred)	The message stayed in queue too long and timed out without reaching the recipient’s server. This is usually due to issues on the receiving side (server down, network issues, or misconfigured DNS). The sender can retry later; the admin should check that the target domain is reachable (DNS MX record, etc.).
550 5.4.1	Relay access denied / Domain not found	The sending server wasn’t allowed to relay the message, or the recipient domain isn’t accepting mail. In Office 365, this can happen in hybrid setups or if the recipient’s domain has no valid mail exchanger. It may indicate a configuration issue either in connectors or on the recipient’s side (e.g., an MX record problem).
550 5.7.1	Delivery not authorized, message refused	General unauthorized – The sender is not allowed to send to the recipient. Common causes: the recipient might be a distribution list or address restricted to internal senders, or a transport rule is blocking the message. For example, if you send to an external mailing list that only accepts members, you’ll get this error. Only the recipient’s admin can change this, or the sender must obtain permission.
550 5.7.1 (variant)	Unable to relay	Relay attempt failed – This occurs when a server tries to forward a message to another server and is not permitted. In a pure Exchange Online scenario, end-users shouldn’t normally see this unless an application or device is misconfigured. In hybrid scenarios, it can mean the on-premises server is not allowed to route outbound via Office 365 without authentication.
530 5.7.57	Client not authenticated	The sending client/server did not authenticate where expected. This often appears when using SMTP submission (smtp.office365.com) from a device or app that didn’t properly authenticate. For user-sent mail via Exchange Online, this should not occur unless a connector is set incorrectly. The solution is to configure authentication or use the proper SMTP settings.
550 5.7.23	SPF validation failed	The recipient’s email system rejected the message because it failed the SPF check. In other words, the sender’s domain isn’t authorized in DNS to send mail from the originating server. The admin should verify the SPF record for the sending domain includes all legitimate sending services and IPs.
550 5.7.501 (or 502/503)	Access denied, spam abuse – banned sender	Office 365 has banned the sender due to suspected spam. The account was likely sending out bulk or malicious emails. An admin needs to confirm the account is secure (change password, scan for malware) and then contact Microsoft support to re-enable sending.
550 5.7.506	Access Denied, Bad HELO	The sending server introduced itself with an invalid HELO (typically by identifying as the recipient’s server). This is often seen as a spam characteristic. If your organization runs its own SMTP server or device, ensure its HELO/EHLO is properly configured to use its own domain name.
550 5.7.508	Rejected by recipient (IP blocked)	The recipient’s organization blocked the sending IP address. This means your mail might be on a blocklist or the recipient explicitly blacklisted your domain/IP. The sender or admin would need to contact the recipient to get unblocked or request removal from blocklists.
552 5.3.4	Message size limit exceeded	The email was too large for one of the mail systems. This error is often returned by the recipient’s server if the message size (including attachments) is over their limit. The solution is to reduce the size (compress files or use cloud sharing) and resend.

 

Note: The first digit of the status code indicates the type of failure. 4.x.x codes (e.g., 4.4.7) are temporary failures (the service will usually keep trying for some time), whereas 5.x.x codes (e.g., 5.1.1, 5.7.1) are permanent failures that require changes before reattempting. The examples above are some of the most encountered codes for internal-to-external mail issues. For a full list, see Microsoft’s documentation or use the admin center’s NDR diagnostic tool.

---

Tools and Best Practices for Preventing Delivery Issues

Maintaining smooth email delivery in Exchange Online involves proactive monitoring and configuration. Both users and admins can take preventive steps:

• • Keep Address Books Updated: Users should update contacts when people change addresses. Auto-complete (Outlook cache) can retain outdated addresses; removing old entries avoids misdirected emails.

• • Monitor Sending Limits: Educate users about sending limits (for example, Office 365 may limit an account to send to a large number of external recipients per day). Sudden need to email thousands of people can trigger throttling. Use distribution lists or third-party mailing services for bulk email to avoid hitting these limits.

• • Enable Authentication Protocols: Admins should ensure SPF, DKIM, and DMARC are properly set for the domain. These help recipient servers trust your emails and reduce bounces due to authentication failures. An SPF misconfiguration can lead to many bounces (5.7.23 errors) until fixed.

• • Regularly Check Blocked Senders: In the Exchange Admin Center, keep an eye on restricted users (accounts automatically blocked for sending spam). Microsoft 365 will list these in the Security portal. If an account is compromised, follow procedure to secure it and remove the block. This prevents a situation where a user is unaware their account was blocked (they’d get 5.1.8 NDRs until unblocked).

• • Use Message Encryption or Alternatives for Large Files: Instead of sending very large attachments, users can use OneDrive or SharePoint links. This avoids bouncing on size grounds and is more reliable. Also, if sending sensitive content, using Office 365 Message Encryption or a secure link can sometimes avoid content-based rejections by external filters.

• • Test DNS Changes: If you change your DNS records (like MX or SPF), test email flow. Admins can use tools like the Microsoft Remote Connectivity Analyzer to send test emails or verify DNS and mail flow between your org and the outside world. This can catch issues (e.g., missing MX or incorrect SPF) before they impact users.

• • Stay Informed on Service Status: Admins should subscribe to Office 365 Service Health alerts. In the Admin Center, the Service Health dashboard provides up-to-date info on any email service problems. Microsoft also posts alerts in the Message Center for configuration changes or known issues that could affect mail flow. Being aware early can save time troubleshooting something that is a broader cloud issue.

• • Educate Users on NDRs: Make sure end-users know that when they get a bounce message, they should read it and share it with IT if needed. NDRs are helpful – they often contain the reason for failure and sometimes even how to resolve it. Users should not ignore these or just repeatedly resend without addressing the error.

• • Maintain Good Sending Reputation: Avoid practices that can get your domain flagged as spam (like users sending phishing or too much marketing email from their regular accounts). If your organization needs to send bulk emails (newsletters, etc.), consider using dedicated services or distinct IP pools. A good reputation means external servers won’t block you as often, resulting in fewer bounces (less “550 5.7.508 rejected by recipient” situations).

---

Additional Resources and Support

If you need more help, here are resources and next steps:

• • Microsoft Learn Documentation: The official docs for Exchange Online mail flow and https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online provide extensive information.

• • Microsoft Support and Recovery Assistant (SaRA): Microsoft offers a Support and Recovery Assistant tool that end-users can run for Outlook and email issues. While it’s more often used for client issues (like not receiving emails in Outlook), it’s a good first step for a user to self-diagnose common problems.

• • Office 365 Community and Q&A: You can ask questions on Microsoft Q&A forums or the Tech Community for Exchange. Often, other admins have encountered similar issues (for example, specific NDR codes in hybrid setups) and can offer guidance.

• • Contacting Microsoft Support: For persistent or unclear issues, don’t hesitate to reach out to Microsoft 365 Support. Provide them with the NDR details, message trace results, and what troubleshooting you have done so far. They have deeper tools to investigate mail flow logs and can determine if the issue lies within Exchange Online or advise on external causes.

• • Staying Updated: Keep an eye on the Message Center in your M365 Admin portal for any updates related to mail flow, spam filtering changes, or new features that could affect how emails are delivered. Microsoft regularly updates Exchange Online, and new security features (like enhanced spam protections or stricter compliance rules) can sometimes lead to delivery questions – announcements in Message Center will prepare you for these.

By systematically following the steps in this guide, most internal-to-external email delivery problems can be identified and resolved. Remember to use the tools available (like message trace and NDR diagnostics) and leverage the error information provided. With careful verification of settings and attentive monitoring, you can ensure reliable email delivery for your organization’s users.