=========此问题正已解决，属误操作，不是技术问题。==========
 
问题描述：
在生产环境中尝试手工向测试环境中的Exchange服务器发送邮件（Telnet到25端口，命令行发送）时候，输入rcpt to命令时，得到错误反馈：550 5.7.1 Unable to relay for xxx@test.com。
 
测试环境描述参见前文：使用 Hyper-V搭建测试环境。
 
排错过程：
先检查ESM >> 管理组 >> 服务器 >> 协议 >> SMTP >> Default SMTP VS 属性，查看“身份验证”和“中继”设置，都是默认设置，没有问题。

尝试在测试环境中的服务器上手工发送邮件，没有提示错误。再次证明服务器设置没有问题。怀疑是网络设置问题。而从生产环境Telnet到测试环境的25端口，证明网络传输都没有问题。难道问题出在DNS名称解析上？

回想当时出现问题是在生产环境中通过 Telnet FQDN 25发起连接请求的，于是改为 Telnet IP 25，这回成功发送邮件。看来问题真出在名称解析上。问题是，如果名称解析有问题，为何还能够Telnet成功，并进入Telnet会话呢？

=====做事先，得空了再查，先记录下来备忘，待续=========
回来了。

生产环境中的DNS服务器上做了一个转发，，将所有对测试环境的域名访问直接转发到测试环境的DNS服务器上。而测试环境的DNS里所建立的区域是AD集成的。我怀疑问题就是出在DNS记录上。

于是我在测试环境的DNS服务器上建立了单独的A记录和MX记录，解析到相应的Exchange 服务器上，再次到生产环境中Telnet FQDN 25，这次成功。

现在新的问题来了：为何非要手动新建A记录，直接将MX记录指向当初Exchange服务器加入域时自动创建的主机记录，难道不行吗？这两者有何区别呢？看样子要再查查资料了。先写到这里，有空了再查。
 
想了半天，不得其解，能够Telnet到25端口，表示没有DNS和网络传输的问题啊，剩下的就只是Exchange的反馈了。于是决定重演问题。修改现有的MX记录，指向FQDN，这次没有出现问题了。看来是第一次操作过程中某个步骤的误操作了。汗。。。。。