案例背景：突然中断的外部邮件发送
某中型制造企业近期反馈，其内部员工无法向外部合作伙伴发送邮件。初步检查发现，内部邮件系统（基于Exchange或Zimbra架构）在尝试连接外部SMTP服务器进行投递时，频繁收到“550 5.7.1 Client does not have permissions to send as this sender”或简写为“550 Relay Access Denied”的错误代码。然而，公司内部互通邮件完全正常，且无大规模病毒爆发迹象。
作为外包技术支持团队，我们接到工单后立即介入。此类问题通常不是单一配置错误，而是网络环境、安全策略与ISP限制共同作用的结果。通过复盘整个排查过程，我们可以提炼出一套标准化的故障诊断与修复流程。
第一步：精准定位故障节点
在开始修复前，必须确认故障发生在哪个环节。通过查看邮件服务器的事件日志（Event Log）和传输队列（Transport Queue），我们发现所有发往外网域名的邮件均处于"Retry"状态，且返回码均为5xx系列。
- 内部测试：使用Outlook或其他客户端登录Webmail，向同一个内部账户发送邮件，显示成功。结论：邮件服务器核心服务（MTA/MDA）运行正常。
- 外部测试：在服务器上执行
telnet smtp.gmail.com 25，连接超时或被主动拒绝。结论：问题出在网络出口或SMTP端口通信上。
第二步：排查常见三大原因
1. ISP对25端口的封锁
这是目前中小企业最常见的原因。为了遏制垃圾邮件泛滥，绝大多数云服务商（如AWS、阿里云、腾讯云）和宽带运营商（ISP）默认封锁了出站TCP 25端口。
验证方法：尝试连接465端口（SMTPS）或587端口（Submission）。如果25端口不通，但465/587通顺，则极有可能是端口封锁。
解决方案：联系ISP申请解封25端口（通常需要提供企业资质证明），或者更推荐的做法是修改邮件服务器配置，使用ISP提供的中继服务器或通过587端口结合TLS加密进行邮件发送。
2. 防火墙与安全组策略拦截
企业边界防火墙或云端安全组可能配置了严格的出站规则，仅允许特定IP访问互联网。如果邮件服务器的出口IP不在白名单内，或者防火墙日志显示DROP/DENY状态，则会导致中继失败。
操作建议：检查防火墙的NAT规则，确保邮件服务器的公网IP地址正确映射。同时，检查是否有IPS（入侵防御系统）将正常的SMTP握手流量误判为扫描行为而阻断。
3. 反向DNS（PTR记录）缺失或错误
现代反垃圾邮件机制非常依赖PTR记录。当外部服务器收到来自IP X.X.X.X 的连接请求时，会查询该IP的PTR记录。如果PTR记录指向的域名与该IP解析出的A记录不一致，或者PTR记录缺失，大量主流邮箱服务商（如Gmail、Yahoo、Outlook）会直接拒绝接收，视为潜在垃圾源。
第三步：实施修复与优化
1. 配置备用端口与加密连接
鉴于25端口封锁的普遍性，建议优先调整邮件服务器出站设置：
- 将默认发信端口从25更改为587。
- 强制启用TLS/STARTTLS加密传输，这不仅符合现代安全规范，也能绕过部分仅对明文SMTP进行严格检测的设备。
- 若必须使用25端口，需在邮件服务器配置中启用认证机制（SMTP AUTH），尽管这不能完全解决中继被拒问题，但能增加可信度。
2. 修正反向DNS解析
登录您的服务器托管控制台或ISP管理后台，为服务器的公网IP地址设置PTR记录。 PTR记录的域名应与服务器的主机名（Hostname）一致。例如，如果主机名是 mail.example.com，则IP X.X.X.X 的PTR记录应解析回 mail.example.com。
3. 完善DNS解析记录
为了确保邮件送达率，务必检查并配置以下DNS记录：
- MX记录：指向您的邮件服务器IP或域名。
- SPF记录：在域名的TXT记录中添加SPF值，例如
v=spf1 mx ip4:X.X.X.X ~all，授权该IP地址代表域名发送邮件。 - DKIM签名：虽然不直接解决中继被拒，但DKIM能证明邮件未被篡改，提升信誉度。
第四步：验证与监控
完成上述配置后，重启邮件相关服务（如Postfix, Exchange Transport Service）。使用在线工具（如MXToolbox）对该IP地址进行黑名单检查和SMTP诊断测试。发送一封测试邮件至Gmail和Outlook账号，观察是否进入垃圾箱或被拒收。
专家提示：如果问题依旧存在，考虑使用第三方的邮件中继服务（SendGrid, Amazon SES, 阿里邮件推送等）。这些服务拥有极高的IP信誉度和专门优化的发送通道，能显著降低自建邮件服务器的运维负担和被封禁的风险。
总结
企业邮件SMTP中继被拒是一个典型的多因素故障。从IT外包服务的角度来看，不能仅停留在“重启服务”层面，而应从网络出口策略、DNS声誉管理以及合规加密三个维度进行系统性排查。通过标准化上述步骤，可大幅缩短故障恢复时间，保障企业业务连续性。