故障现象描述
近期，某中型企业IT运维团队收到大量用户反馈，反映内部员工无法正常发送邮件，外部客户也声称未收到来自企业的回复邮件。登录Exchange管理中心（ECP）查看监控日志，发现"Submission"和"Transport"队列中存在数千封待处理邮件，且多封邮件在重试多次后返回"550 5.7.1 Unable to relay"或超时错误。部分邮件甚至直接停留在"Retry"状态长达数小时未动。
初步诊断与范围界定
面对此类批量故障，首先需要确定影响范围是全局性还是区域性，以及故障节点位于内网传输环节还是外网出口环节。
1. 检查队列状态
通过Exchange Management Shell (EMS) 执行以下命令，查看当前积压邮件的数量及详细信息：
Get-Queue | Where-Object {$_.MessageCount -gt 0} | Select-Object Identity, MessageCount, Status, NextHopDomain
若观察到多个队列显示为Retry状态，且NextHopDomain指向外部域名或特定智能主机，则表明问题出在出站传输环节。若DeliveryType为SmtpDelivery，需重点检查SMTP连接配置。
2. 验证基础连通性
排除网络层面问题。在邮件服务器上执行：
Test-ServiceHealth：确保所有关键Exchange服务（如Microsoft Exchange Transport）运行正常。Telnet 目标SMTP服务器 25或Test-SmtpConnectivity：验证能否与下一跳服务器建立TCP连接。
如果Telnet测试超时，可能是防火墙规则变更、ISP端口封锁或目标服务器不可达；如果立即拒绝，则可能是认证失败或IP被拉黑。
常见根因分析
根据实际案例统计，邮件队列堆积通常由以下三大类原因引起：
1. DNS解析故障或MX记录异常
Exchange服务器依赖DNS查询来定位收件人域名的MX记录。如果内部DNS服务器响应缓慢或缓存污染，会导致邮件路由延迟甚至失败。
排查方法：使用Resolve-DnsName或nslookup查询主要收件域名的MX记录，确认返回值是否正确且响应时间在合理范围内（通常小于1秒）。
2. 反垃圾邮件策略或白名单缺失
企业通常部署了硬件防火墙、云反垃圾网关（如Proofpoint, Cloudmark）或Exchange自身的反垃圾功能。若发件人IP不在接收方的白名单中，或者触发了严格的反垃圾规则，邮件会被暂时扣留或丢弃。
排查方法：检查Exchange日志（位于C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub下的Receive和ProtocolLog文件夹），搜索包含"550"或"Rejected"的错误代码，查看具体的拒绝原因。
3. 连接器配置错误或证书失效
如果是通过智能主机（Smart Host）发送外部邮件，连接器配置中的身份验证信息过期、SSL证书信任链断裂或端口限制，都会导致连接中断。
排查方法：检查Get-SendConnector的输出，确认AddressSpaces、SmartHosts及AuthenticationCredential设置是否正确。同时验证智能主机证书是否仍在有效期内且受信任。
解决方案与恢复步骤
第一步：纠正根本原因
根据上述排查结果采取行动：
- DNS问题：刷新DNS缓存（
ipconfig /flushdns），或配置Exchange优先使用内部权威DNS服务器。 - 反垃圾拦截：联系接收方管理员或将企业公网IP加入对方白名单；或在本地Exchange中调整反垃圾策略，适当放宽对可信域名的检查级别。
- 连接器修复：重新配置智能主机的认证凭据，或更换有效的SSL证书。对于基于TLS的连接，确保启用了
-TlsSenderCertificateNameMatch参数以匹配证书CN。
第二步：清理积压队列
在根本问题解决后，需要手动触发积压邮件的重试，避免等待自然重试周期（通常长达24-48小时）：
1. 重试特定队列：
Resume-Queue -Identity "ServerName\QueueGuid"
2. 重试所有暂停的队列：
Get-Queue -Server "ServerName" -Status Failed, Suspended, Retry | Resume-Queue
3. 强制丢弃无效邮件（谨慎操作）：
若发现部分邮件地址已永久失效（Hard Bounce），可将其移出队列以防止无限重试消耗资源：
Remove-Message -Filter {FromAddress -eq "invalid@example.com"} -WithNDR $false
第三步：验证与监控
恢复后，发送一封测试邮件至内部和外部常用邮箱，确认路由正常。建议部署实时监控告警，当队列长度超过阈值（如100封）时，通过短信或邮件通知管理员，以便在问题扩大前介入处理。
预防措施建议
- 定期审查连接器配置：每季度检查一次智能主机证书的有效性和认证凭据的时效性。
- 实施双通道冗余：配置多个Send Connector或备用智能主机，实现负载均衡和故障切换。
- 监控DNS健康度：确保DNS服务器的可用性和响应速度，必要时配置多路DNS解析。
- 日志归档与分析：保留足够的传输日志，利用脚本定期分析错误模式，提前发现潜在趋势。
总结：Exchange邮件队列堆积往往不是单一故障点造成的，而是网络、配置、策略共同作用的结果。通过结构化的排查流程——从队列状态到DNS解析，再到连接器配置，可以快速定位并解决绝大多数发送失败问题，确保企业通信渠道的畅通。