4

I moved a small client from one hosted Exchange server (Microsoft Office 365) to another (Intermedia.net). Some emails from External senders to the users on the new server host are undeliverable, bouncing off the OLD server w/ no relay errors.

It seems like the typical error that you get with LegacyExchangeDN or X500 addressing that requires the clearing of the name completion cache. However in my experience that occurs for internal senders. This is from external senders, who pretty much all are Outlook users. The rejection to external users is coming from the old server as affected external senders emails are still delivered there. However our MX records have fully propagated and no one who is not on Outlook, or is a new sender and has no correspondence history, has a problem emailing us. Is it possible/likely, the same name completion/clear cache error? I'm going to have to reach out to users and IT admins around the country and walk them through resolving this issue so their users can email us again?

UPDATE: Our DNS on Godaddy had a default 1 Week TTL on MX records. SO both our legacy record and the new record I created on Friday evening had a 1 week TTL. I just changed it to 30 minutes, but I suspect we might be out of luck until 1 week from the original Friday evening change? One of the big spots forwarding email to the wrong server is from users whose providers go through messagelabs.com (Symantec) servers.

9
  • 2
    The rejection to external users is coming from the old server as affected external senders emails are still delivered there - I'm not understanding that statement. You're saying that some of the emails being sent from external users is going to the old Exchange Server? If so, then that seems like a DNS problem.
    – joeqwerty
    Nov 25, 2014 at 21:14
  • It's not. If you check mxtoolbox or any of a number of other dns checks, it all points to the proper place and did so about 5 days ago. Also if any user with no correspondence history emails us, even from the same outfit as affected senders, we get the email. I'm pretty certain it's about Outlook addressing, but it does seem bizarre. Nov 25, 2014 at 21:19
  • OK, but why would their email be going to the old server? The LegacyExchangeDN (if it were used by external Outlook clients) shouldn't be externally resolve-able. One way to test this might be to pick an affected recipient, add the LegacyExchangeDN and ask an affected sender to send them an email.
    – joeqwerty
    Nov 25, 2014 at 21:22
  • 3
    One thing you can't control is how long the external mail server bothers to cache the MX record for the domain. It might use the DNS TTL value, but it might not. For an affected sender I would contact their IT department and ask them what the MX lookup returns for the domain and if they are still caching the old value or not, whether locally or perhaps on whatever DNS server or forwarder they are using.
    – TheCleaner
    Nov 25, 2014 at 21:41
  • 2
    @JoshuaMarshall I've been trying to contact the affected sender's IT departments. It's like whack-a-mole. ... and now you know why mail admins kill. Nov 25, 2014 at 23:32

2 Answers 2

2

As one of the crucial step for migration from on-prem mail exchange server to Office365, the TTL value should be lowered to a minimal time from the default value during the update change of the MX record

"Set this value to 1 hour or to the equivalent in minutes (60), seconds (3600), etc."
Change nameservers at any domain registrar to set up Office 365

1

Exchange X500 addresses (commonly known as LegacyExchangeDN) are only ever used internally by Exchange and Outlook clients; they are never involved in SMTP delivery, even if the other end is also running Exchange; for the same reason, they are never seen by Outlook clients of remote Exchange systems. Thus your assumption is wrong: if the problem affects incoming messages from external systems, then it's definitely not related to X500 addresses.

DNS is the most likely culprit; especially if, as you already discovered, your DNS provider is using a very long TTL.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .