We recommend that you try the Mail Flow Guided Walkthrough. This content for DSNs is moving
How do I interpret a Delivery Status Notification (DSN) message?

 

Scenario: Whether you are sending or receiving emails, there are times when you need to troubleshoot a bounced message – that is, the message was sent but could not be delivered.  Here’s an introduction on how to interpret these messages.

If the sender is NOT getting a bounce message, return here for more options.

Steps:

  1. Read the friendly part
  2. Get more details
  3. Understand the SMTP error codes
  4. Study the original message headers

Step 1: Read the friendly part

Let’s assume for a second that we have a DSN like this:

Delivery has failed to these recipients or groups:
Joe Smith
Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept email from certain senders, or another restriction may be preventing delivery.
The following organization rejected your message: mail.contoso.com.

This section of the DSN is intended to be user-friendly.  The main purpose is to provide a summary about what went wrong.  In this case, it’s clear that I was sending a message to Joe, and that the message was not rejected by Office 365 or by FOPE, but by an organization advertising itself as mail.contoso.com.

Maybe the error is obvious – perhaps you mistyped the email address, or the recipient is no longer at the organization.  The user-friendly errors should help get you close to solving the problem in a lot of cases.

Step 2: Get more details

If you need to know more about what happened, read further and you’ll find the detailed diagnostic section:

Diagnostic information for administrators:
Generating server: bigfish.com
joepremise@contoso.com
mail.contoso.com #<exchange.contoso.com #5.7.1 smtp;530 5.7.1 Client was not authenticated> #SMTP#

This section is the most important part.  This DSN means that Bigfish.com (which is FOPE) was attempting to connect to mail.contoso.com and received an SMTP error from that server which responded with an error:

 530 5.7.1 Client was not authenticated

This means that mail.contoso.com is ultimately the one who rejected the message, and they are the ones that will need to assist with understanding why the problem occurred.

Step 3: Understanding SMTP error codes

A 5xx or 5.x.x error is permanent, meaning that it is not considered temporary .  An Internet search for this error may be helpful.  As it turns out, the remote mail server was configured to not accept anonymous email from the Internet, usually a configuration mistake on that side. You should work with the remote administrator to correct this configuration .

A 4xx or 4.x.x error is temporary.  Typically these problems occur when the remote side cannot be reached, is having a temporary problem that may be corrected in time, or occasionally, is having a problem accepting email from just your domain (for example, if they are performing anti-spam checks).

More frequently, you will see errors like this:

  • 5.1.1 550 (unknown user) - This means that the email account does not exist at the organization the message was sent to, so check that the address is correct.
  • 5.0.0 550 SPF MAIL FROM check failed (PermError) - This means that the remote server was not able to verify the SPF DNS record for your domain.  You should check your Sender Policy Framework (SPF) records, using a tool like nslookup, SPF Wizard, or Remote Connectivity Analyzer.
  • 451 4.1.8 Cannot resolve your domain {mx101} or Sender address rejected: Domain not found - These errors typically mean that the remote side was attempting to do some verification against your domain and was not satisfied with the result.  In this case, perhaps adding an A record for margiestravel.com will convince the mail servers to accept the message, but ultimately, you may need to contact them to understand why they are rejecting the message.

 

Step 4: Study the original message headers

In addition, the original message is often attached to the message. Because many users will forward these messages to the help desk, the original headers are placed in the message body (since attachments aren’t typically forwarded unless the client is configured to do so).

For steps on collecting message headers, click on the appropriate client version below:

Here's an example message header: 

Original message headers:

Received: from mail36-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Wed, 3 Aug 2011 15:03:33 +0000
Received: from mail36-tx2 (localhost.localdomain [127.0.0.1]) by mail36-tx2-R.bigfish.com (Postfix) with ESMTP id CD1047E84D3 for <joepremise@contoso.com.FOPE.CONNECTOR.OVERRIDE>; Wed, 3 Aug 2011 15:03:33 +0000 (UTC)
X-SpamScore: -5
X-BigFish: PS-5(zz1861Mc85dhzz1202hzzz2fh2a8h668h839h34h65h)
X-Spam-TCS-SCL: 4:0
X-Forefront-Antispam-Report: CIP:157.55.61.146;KIP:(null);UIP:(null);IPV:SKI;H:CH1PRD0302HT003.namprd03.prod.outlook.com;R:internal;EFV:INT
Received-SPF: pass (mail36-tx2: domain of contoso.onmicrosoft.com designates 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=Scott@ contoso.onmicrosoft.com; helo=CH1PRD0302HT003.namprd03.prod.outlook.com ;.outlook.com ;
Received: from mail36-tx2 (localhost.localdomain [127.0.0.1]) by mail36-tx2 (MessageSwitch) id 1312383812531599_7509; Wed,  3 Aug 2011 15:03:32 +0000(UTC)
Received: from TX2EHSMHS046.bigfish.com (unknown [10.9.14.247]) by mail36-tx2.bigfish.com (Postfix) with ESMTP id 7878E15F804B for <joepremise@exchange.contoso.com>; Wed,  3 Aug 2011 15:03:32 +0000 (UTC)
Received: from CH1PRD0302HT003.namprd03.prod.outlook.com (157.55.61.146) by TX2EHSMHS046.bigfish.com (10.9.99.146) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 3 Aug 2011 15:03:31 +0000
Received: from CH1PRD0302MB127.namprd03.prod.outlook.com ([169.254.7.54]) by CH1PRD0302HT003.namprd03.prod.outlook.com ([10.28.28.161]) with mapi id 14.01.0225.063; Wed, 3 Aug 2011 15:03:30 +0000
Content-Type: multipart/mixed;
 boundary="_000_B94CB51B8825B84382E64D7B4BE1555533ACCC50CH1PRD0302MB127_"
From: Scott <Scott@contoso.onmicrosoft.com>
To: "Joe Smith" <joesmith@contoso.com>
Subject: Windows Phone is awesome!

A few additional things to look at that may be helpful:

  • To address: This can be helpful if the address was mistyped or was incorrect.
  • Received headers:  These can tell you what the path was for the message, and more specifically which last hop generated the DSN (assuming it isn’t easy to tell from the “generating server”).  Since the DSN was generated inside of FOPE, this won’t be too helpful except if Microsoft support needs it.
  • Received-SPF:  This can tell you if FOPE thinks that the SPF record permits the originating IP address to send the message.  If this is anything other than pass, you should check your SPF record in DNS.

Common problems

Here we'll add links to helpful Knowledge Base articles or other documentation that pertains to this scenario. 

  • If you are having trouble sending mail to certain domains, you may want to verify that you have the recommended DNS record types for sending mail.  Specifically, you want an A record for the domain (example: @.contoso.com - this record should generally point to the same address as your www record), an MX record, and SPF record that designates Outlook.com as a sender.  For more information see Domains in Office 365.
  • If you have recently signed up for Office 365, make sure that your MX record is in one of these forms: contoso-com.mail.eo.outlook.com ,or contoso-com.mail.protection.outlook.com.  You can obtain the correct entry by logging into the portal and clicking "Domains".  It is very important to use the entry you are given and not create multiple DNS records or use a different value.  If you are a Small Business customer, you should simply change your Name Server (NS) records as instructed.