A significant portion of the support requests that I see at work, in online forums, and from Exchange Server Pro readers involves an email delivery failure and a subsequent non-delivery report (NDR).
NDRs have been a horrible mess for a long time, often containing a whole heap of cryptic diagnostic information and very few plainly written sentences. IT folks can develop the skills over time to read and interpret an NDR, but the average end user doesn’t stand a chance. In a recent column Tony Redmond explored the history of NDRs and how a few of the major email providers generate them today.
As Tony hinted in that article, work is ongoing in Exchange Online (Office 365) to make NDRs clearer and more readable for the average end user, and include more actionable advice to resolve the issue without always needing to contact their own IT help or Office 365 support. And recently the Office 365 Roadmap was updated to include some more information about those efforts.
Over the next several months NDRs generated by Office 365 will be enhanced to make it easier to understand and fix many message delivery problems. To start, they’ll look better, friendlier, less intimidating to end-users. They’ll explain the problem and cause in simple, everyday language, with clear steps the sender can take to try to fix the problem. Enhanced NDRs will include an “at-a-glance” delivery status graphic that summarizes the cause of the problem and where it needs to be fixed (sender side, recipient side, or by Microsoft supportengineers). A “More Info for Email Admins” section will provide an in-depth explanation of the problem and solution, and will include expanded technical details, often with a link to a Web-based article for in-depth information. And while the original message headers, in their mono-spaced typeface and primitively word-wrapped magnificence, will still appear at the bottom of the NDR, we’ll also expose them in a formatted table, making it easier to follow the message’s server to server hop path and more quickly spot problems between hops.
This will be a welcome change. After all, “no one wants their message delivery to fail, but when it does, it shouldn’t always take a degreein computer science to understand why and what to do to fix it.”