MailPlus 日志报 5.7.1 rejected by SPF（invalid ARC result）：先分清你是发送端还是接收端
痛点场景
两种情形都可能把你带到这条日志面前：
- 客户反馈：发给你们公司的邮件被退回了，退信里带着
5.7.1 rejected by SPF policy； - 自查发现：自己公司发出去的邮件被对方拒收，MailPlus Server 的 审核 > 日志 里躺着这条记录，末尾还跟着一串
invalid ARC result。
同一个日志代码，对应的是两种完全不同的排查方向。处理这条日志的第一步不是改配置，而是分清你的 MailPlus 在这封邮件里是发送服务器还是接收服务器。
诊断：SPF 记录里没有这台投信服务器
按官方知识库的口径，这条日志的含义很直接：发送服务器的 IP 地址未列在 SPF 记录中，因此无权代表关联域发送电子邮件，这封邮件无法投递。
SPF 记录登记在发件域名的 DNS 里，声明哪些 IP 地址有权代表这个域发信。连接 IP 与声明对不上，这封"代表某域发来"的邮件就属于越权投递。
日志末尾的 invalid ARC result 是另一个提示：ARC 是邮件在中继转发链上传递认证结果的机制，这一项无效意味着这封邮件经过中继后，原始的 SPF 认证结果已经无法被验证为可信。通俗讲：不光直接投递的 IP 对不上，连"上家说它检查过了"的凭证也不成立。这样的组合，钓鱼与伪造发件人的嫌疑权重更高。
第零步：先核对发件人真伪
官方解决方案的第一句是：先检查电子邮件是否来自虚假地址。
如果发件域可疑、发件人查无此人，这条拒收就是校验机制正常工作，不需要任何"修复"。只有在确认发件人合法且值得信赖之后，才进入下面按角色分的排查步骤。
角色一：MailPlus 是发送服务器——补自己的 SPF 记录
如果被拒的邮件是你们自己发出去的（比如客户邮箱、订单通知经由 MailPlus 投递），排查对象是自己域名的 DNS：
- 检查你们发件域的 SPF 记录；
- 核对实际投信服务器的 IP 地址是否包含在记录里——常见漏洞出在：换了投信出口 IP、增加了中继服务、多台设备分担发信，却没同步更新 DNS；
- 确认发送服务器的 IP 地址确实未包含在 SPF 记录中后，把它添加进记录。
DNS 生效需要传播时间，改完记录后别急着下结论，隔一段时间再用退信测试验证。这一步是治本：SPF 记录补齐之前，不只是某一个收件方，任何严格执行 SPF 校验的服务器都可能拒收你们的邮件，客户收不到信、验证码进垃圾箱这类问题都会随之而来。
角色二：MailPlus 是接收服务器——两条本方措施
如果是别人发给你们被拒，且确认对方可信，官方给出两条措施：
- 加允许列表：进入 MailPlus Server > 邮件投递 > 安全性 > 封锁/允许列表，将发送服务器的 IP 地址添加到允许列表，来自该 IP 的投递不再被 SPF 检查拦下；
- 暂时关闭 SPF 验证：在 MailPlus Server > 安全性 > 验证 中，暂时关闭启用 SPF 验证选项。
两条的适用场景不同：允许列表是精确放行，只影响指定 IP，优先使用；关闭 SPF 验证是全局开关，生效期间所有伪造发件人的邮件都少了一道拦截，只能作为短时过渡手段，事后务必重新开启。
处置顺序小结
- 核对发件人真伪，陌生来源不处理；
- 判断角色：自己发出去的，查自己域的 SPF 记录并补 IP（治本）；
- 别人发进来的，先用允许列表精确放行，请对方同步修正其 SPF 记录；
- 全局关 SPF 验证仅作过渡，设定恢复时间点。
诚鑫致达科技处理这类拒信工单的第一问永远是"这封信是谁发给谁"——角色分清了，SPF 问题才不会在发送端和接收端之间来回踢皮球。