在我们的日志中，我们发现如下：
Router: No messages transferred to fakedomain.com (host mx.fakedomain.com) via SMTP: The server is not responding. The server may be down or you may be experiencing network problems. Contact your system administrator if this problem persists. 其次是：
Router: Transferring mail to domain fakedomain.com (host mx.fakedomain.com [111.111.111.111]) via SMTP Router: Message 12345678 transferred to mx.fakedomain.COM for [email protected] via SMTP Router: Transferred 1 messages to fakedomain.com (host mx.fakedomain.com) via SMTP
我们的信息通常会出来，但是我们看到了同样的问题。 我相信我的configuration有问题，可能是超时，或类似的东西，但我一直没有find正确的。
这看起来像是我在另一个环境中遇到的问题：要找出原因，可以尝试以下操作：
在服务器上打开cmd键入以下命令
nslookup set type=mx fakedomain.com
并看看结果：我敢打赌，会有超时/其他奇怪的行为。 Domino使用此方法确定目标域的mxlogging。 如果这个查询需要很长的时间，它会显示发布的错误，然后再试一次…然后获取caching的值，一切都很好。
如果mx-查找速度够快，则将该名称parsing为IP地址可能是个问题。
尝试以下命令来validation：
nslookup mx.fakedomain.com
这应该给你的mx-logging的IP地址。 这个查询速度有多快？ 这个DNS查询也可以用一个简单的ping mx.fakedomain.com 。 在一个案例中，我有每一个第一次和第二次ping失败，但成功ping成功…然后同样的错误将在控制台上。
我想这是一个networking问题，与你的多米诺骨牌configuration无关。 修复networking，多米诺骨牌将被修复。
您可以尝试在服务器上的notes.ini中修改MailTimeout 。
语法：MailTimeout =天数
例如：MailTimeout = 3
但请注意，这不是解决您的networking问题的解决scheme。 这只会帮助邮件不会直接发回给用户。 如果你把一个星期作为超时，这可能会混淆用户，因为电子邮件将在多天后被反弹回来。 所以你应该放在这里的最大值应该是3在我眼里。
我find了一个解决scheme：
打开服务器上的cmd键入以下命令：
set timeout = 55
这对我有效。