先看 5.7.26 后面的完整原因
Google 的 SMTP 错误表给同一个 5.7.26 代码列出了多种文本。常见分支包括：
- SPF hard fail：退信指出 MAIL FROM 域使用
-all，但实际发送 IP 没有通过 SPF。 - 未认证邮件：SPF 与 DKIM 都没有通过，Gmail 因缺少最低身份认证而阻止邮件。
- DMARC policy：邮件没有形成与可见
From:域对齐的 SPF 或 DKIM pass，发送域的 DMARC policy 要求处置失败邮件。
只看到“550 5.7.26”就重写全部 DNS，容易把原本正常的发件源一起破坏。故障分支以退信中的完整英文说明、域名、IP 和认证结果为准。
按证据修复
- 确认退信里的
From:域、MAIL FROM 域和发送 IP，区分可见发件身份与回信路径。 - 检查域名是否只有一条 SPF 记录，并确认实际发件平台在 SPF 授权路径内；不要把接收方 IP 加入 SPF。
- 从该平台发出的真实邮件头读取
DKIM-Signature的d=与s=，核对 selector 公钥和签名结果。 - 确认至少一种通过的身份与可见
From:域完成 DMARC 对齐。 - 等待 DNS TTL 后重新发送一封新邮件，使用新邮件头和新退信验证，而不是重复查看旧消息。
公开 DNS 能证明什么
域名体检可以发现缺失或重复 SPF、潜在查询超限、DMARC policy、指定 selector 的 DKIM 公钥，以及明显的公开记录错误。它不能仅凭域名重放某封邮件的 SPF 计算，也不能证明真实邮件的 DKIM 签名、DMARC 对齐、发送 IP 声誉或收件人投诉率。
不要关闭 DMARC 或把 SPF 改成 +all 来绕过退信。这会扩大域名冒用风险，也不满足 Google 的长期发件要求。
修复后仍被拒绝
认证通过只是准入条件。若新邮件头显示 SPF、DKIM 与 DMARC 已按要求通过，但仍出现其他错误码，应继续核对 PTR、TLS、消息格式、投诉率、名单来源和发送突增；不要把身份认证扫描结果当作进箱保证。