(我认为)Outlook X500寻址的大麻烦

我将一个小型客户端从一个托pipe的Exchange服务器(Microsoft Office 365)移到另一个(Intermedia.net)。 从外部发件人到新服务器主机上的用户发送的一些电子邮件无法传送,从OLD服务器popup,没有中继错误。

看起来像使用LegacyExchangeDN或X500寻址时需要清除名称完成caching的典型错误。 但是,根据我的经验,发生在内部发件人。 这是来自外部发件人,他们几乎都是Outlook用户。 对外部用户的拒绝是来自旧服务器,因为受影响的外部发件人邮件仍然在那里传送。 然而,我们的MXlogging已经完全传播,没有任何人不在Outlook上,或者是一个新的发件人,没有通信历史logging,发邮件给我们的问题。 是否有可能/相同的名称完成/清除caching错误? 我将不得不联系全国各地的用户和ITpipe理员,并通过解决此问题来解决这个问题,以便他们的用户可以再次给我们发送电子邮件?

更新:我们在Godaddy上的DNS在MXlogging上有默认的1周TTL。 因此,我们的遗留logging和周五晚上创造的新纪录都有1周的TTL。 我只是把它改成了30分钟,但是我怀疑在原来的星期五晚上换一周之前我们可能会运气不好。 将电子邮件转发到错误的服务器的一个重要方面是来自提供程序通过messagelabs.com(Symantec)服务器的用户。

作为从内部邮件交换服务器迁移到Office365的关键步骤之一,在更新MXlogging的更新期间,应将TTL值从默认值降低到最小时间

“将此值设置为1小时或以分钟(60),秒(3600)等等的等价值为单位”
更改任何域名注册商的名称服务器以设置Office 365

Exchange X500地址(通常称为LegacyExchangeDN )只能在Exchange和Outlook客户端内部使用; 即使另一端也在运行Exchange,他们从不参与SMTP传递; 出于同样的原因,远程Exchange系统的Outlook客户端也不会看到它们。 因此,您的假设是错误的:如果问题影响来自外部系统的传入消息,那么这肯定与X500地址无关。

DNS是最可能的罪魁祸首; 特别是如果您已经发现您的DNS提供商正在使用非常长的TTL。