Error 550 for unknown reason

This question is answered This question is answered

Hello - I recently cancelled my Office ProPlus service in order to upgrade to E3.  Oddly, people who send email to my .me account are now receiving a failure to deliver notice from my OfficePP address. An example is below.  Any ideas on how to stop this?  I am still receiving the emails but the senders think I am not.

 

Thanks,

 

Tom

 

Generating server: ihealth.onmicrosoft.com

tdelay@ihealth.onmicrosoft.com
#< #5.1.1 smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found> #SMTP#

Original message headers:

Received: from mail161-tx2-R.bigfish.com (65.55.88.116) by
 CH1PRD0410HT002.namprd04.prod.outlook.com (10.255.147.37) with Microsoft SMTP
 Server (TLS) id 14.16.152.4; Mon, 7 May 2012 03:03:19 +0000
Received: from mail161-tx2 (localhost [127.0.0.1])           by
 mail161-tx2-R.bigfish.com (Postfix) with ESMTP id A07D1160371   for
 <tdelay@ihealth.onmicrosoft.com>; Mon,  7 May 2012 03:03:06 +0000 (UTC)
X-SpamScore: 0
X-BigFish: ps0(zzc85fhzz1202hzz8275bh8275dhz2dh54h48h668h839hd25h)
X-Forefront-Antispam-Report: CIP:17.148.16.104;KIP:(null);UIP:(null);IPV:NLI;H:asmtpout029.mac.com;RD:asmtpout029.mac.com;EFVD:NLI
Received: from mail161-tx2 (localhost.localdomain [127.0.0.1]) by mail161-tx2
 (MessageSwitch) id 1336359783605200_15532; Mon,  7 May 2012 03:03:03 +0000
 (UTC)
Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.244])        by
 mail161-tx2.bigfish.com (Postfix) with ESMTP id 83136260070       for
 <tdelay@ihealth.onmicrosoft.com>; Mon,  7 May 2012 03:03:03 +0000 (UTC)
Received: from asmtpout029.mac.com (17.148.16.104) by TX2EHSMHS017.bigfish.com
 (10.9.99.117) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 May 2012
 03:03:03 +0000
MIME-Version: 1.0
Content-Type: multipart/related;
            boundary="Boundary_(ID_oW+hLb1cBf9YJsoTYDaJcQ)";
            type="multipart/alternative"
Received: from nk11r10mm-smtpout002.mac.com ([10.150.69.2]) by
 asmtp029.mac.com (Oracle Communications Messaging Server 7u4-23.01
 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id
 <0M3M00LNVTSQLJA0@asmtp029.mac.com> for tdelay@ihealth.onmicrosoft.com (ORCPT
 tdelay2@me.com); Sun, 06 May 2012 20:03:15 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure
 engine=2.50.10432:5.6.7580,1.0.260,0.0.0000
 definitions=2012-05-07_02:2012-05-04,2012-05-07,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000
 definitions=main-1205060382
Received: from nk11r10mm-mail013a.mac.com ([10.150.91.145]) by
 smtpout002.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep
 26 2008; 64bit)) with ESMTP id <0M3M00L2WTT8J020@smtpout002.mac.com> for
 tdelay@ihealth.onmicrosoft.com (ORCPT tdelay2@me.com); Mon, 07 May 2012
 03:03:08 +0000 (GMT)
Received: from st11b01mm-smtpin201.mac.com ([17.172.48.32]) by ms02014.mac.com
 (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built
 Jan  3 2012)) with ESMTP id <0M3M00MVMTT88490@ms02014.mac.com> for
 tdelay@ihealth.onmicrosoft.com (ORCPT tdelay2@me.com); Mon, 07 May 2012
 03:03:08 +0000 (GMT)
Received: from relay.ihostexchange.net ([66.46.182.52]) by
 st11b01mm-smtpin201.mac.com (Oracle Communications Messaging Server
 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id
 <0M3M002VZTT7UG90@st11b01mm-smtpin201.mac.com> for tdelay2@me.com (ORCPT
 tdelay2@me.com); Mon, 07 May 2012 03:03:08 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
 engine=2.50.10432:5.6.7580,1.0.260,0.0.0000
 definitions=2012-05-07_02:2012-05-04,2012-05-07,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000
 definitions=main-1205060384
Received: from VMBX132.ihostexchange.net ([192.168.40.22]) by
 HUB102.ihostexchange.net ([66.46.182.52]) with mapi; Sun, 06 May 2012
 23:03:07 -0400
From: Tdelay <tdelay@ihealthanalytics.com>
To: "tdelay2@me.com" <tdelay2@me.com>
Date: Sun, 6 May 2012 23:03:04 -0400
Subject: test
Thread-topic: test
Thread-index: Ac0r/eqavjQ6yj1xT2+42wHHjQTAKw==
Message-ID: <814A4FD22D19694F8EEB20BFB5B6D39338F1F8966B@VMBX132.ihostexchange.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Return-Path: tdelay@ihealthanalytics.com

Verified Answer
  • Hi Tdelay,

    I understand that the NDR (Non Delivery Report) 550 5.1.1 RESOLVER.ADR.ExRecipNotFound was received when users trying to send email to your Office 365 account. You just upgraded to Office 365 E3.
     
    The issue occurs if the end users using cache information to send email. To troubleshoot the issue, users need to clear the autocomplete cache. http://support.microsoft.com/kb/287623
    The RESOLVER.ADR is a dead giveaway for these errors. The issue may occur if the user changes the real address of a contact or another organizational user. This can occur due to something like the above (where the admin deletes an address and re-adds them as a contact), or more commonly through a wholesale change of the organization's email addresses (such as a .PST migration from on-premise or hosted to O365). However, the autocomplete caches in the users' mail clients are still pointing to the old X.500 addresses, which need to be cleared out.
     
    If the issue persists, this also occurs if the domain that is configured for coexistence is not set correctly as a shared domain in Office 365.
     
    To troubleshoot the issue, I suggest checking if the domain is configured as shared. You may refer the steps below to check if the domain is a shared domain. If not, please configure the domain as a shared domain. To do this, follow these steps:
     
    1. Sign in to the Office 365 portal (https://portal.microsoftonline.com/) as a global administrator or a service administrator.
    2. Click Admin, and then under Exchange Online, click Manage.
    3. In the Exchange Control Panel (ECP), click Mail Control, and then click Domains & Protection.
    4. Select the domain that is configured for mail coexistence, and then click Details.
    5. Select Shared, and then click Save.
     
    For the detailed information, you can refer the article about Users in the on-premises environment are not receiving mail from Office 365 users.
    http://support.microsoft.com/kb/2510049
     
    Thanks,
    Monica Tong

All Replies
  • Hi Tdelay,

    I understand that the NDR (Non Delivery Report) 550 5.1.1 RESOLVER.ADR.ExRecipNotFound was received when users trying to send email to your Office 365 account. You just upgraded to Office 365 E3.
     
    The issue occurs if the end users using cache information to send email. To troubleshoot the issue, users need to clear the autocomplete cache. http://support.microsoft.com/kb/287623
    The RESOLVER.ADR is a dead giveaway for these errors. The issue may occur if the user changes the real address of a contact or another organizational user. This can occur due to something like the above (where the admin deletes an address and re-adds them as a contact), or more commonly through a wholesale change of the organization's email addresses (such as a .PST migration from on-premise or hosted to O365). However, the autocomplete caches in the users' mail clients are still pointing to the old X.500 addresses, which need to be cleared out.
     
    If the issue persists, this also occurs if the domain that is configured for coexistence is not set correctly as a shared domain in Office 365.
     
    To troubleshoot the issue, I suggest checking if the domain is configured as shared. You may refer the steps below to check if the domain is a shared domain. If not, please configure the domain as a shared domain. To do this, follow these steps:
     
    1. Sign in to the Office 365 portal (https://portal.microsoftonline.com/) as a global administrator or a service administrator.
    2. Click Admin, and then under Exchange Online, click Manage.
    3. In the Exchange Control Panel (ECP), click Mail Control, and then click Domains & Protection.
    4. Select the domain that is configured for mail coexistence, and then click Details.
    5. Select Shared, and then click Save.
     
    For the detailed information, you can refer the article about Users in the on-premises environment are not receiving mail from Office 365 users.
    http://support.microsoft.com/kb/2510049
     
    Thanks,
    Monica Tong

  • Hi Tdelay,

    I would like to follow up with the question you posted previously. Is the issue resolved?

    Thanks,
    Monica Tong