邮件为何进入垃圾箱:DNS 之外的真实原因
mail-tester.com 给出高分,SPF、DKIM、DMARC 都通过,查询的封锁名单也没有记录,邮件却仍进入垃圾箱或没有送达。要解决问题,先要理解测试分数能说明什么,以及它没有覆盖什么。
在 2026 年,身份验证只是基础。Google、Yahoo 和 Microsoft 还会考虑发送行为、历史和共享发送 IP 的信誉。本文分析 DNS 看似正确时仍可能进入垃圾箱的原因,以及值得采取的实际检查。
可能持续保留的批量发件人身份
排查先从服务商如何分类发件人开始。Google 的批量发件人身份不只是午夜归零的每日计数。达到历史发送量条件后,身份可能保留。季节活动或一次发给 10,000 用户可能相关,但应按实际发往个人 Gmail 的量和当前定义判断。
小企业有时以为额外要求只针对发送数百万封的公司。判定门槛其实更低,分类应结合真实发送历史。
可以把它理解为达到过的最高水位。一次满足条件后,Google 可能继续按批量发件人处理域名。以后每天只发 50 封,身份也可能不变。仍需遵守适用额外规则,但身份本身不证明旧活动造成当前垃圾箱投递。
子域名不能保证隔离信誉
用 promo.company.com 分开发送营销有助于管理,但不意味着完全保护 company.com。Google 按主域名汇总量,信誉信号也可能涉及组织域名和共享 IP。
promo.company.com 的投诉可能影响主域名评价。重要合同邮件可能因此受影响,但不能自动认定因果关系。应检查共同发送路径和其他收件信号。
独立域名能更明确地分开任务,却不能因共享 IP 或其他关联保证完全隔离。Google Workspace 每用户每月 $6-$30 是原文比较示例,需要核查当前价格。TrekMail的固定套餐可能包含多个域名,但五个域名是否无需额外费用取决于当前限制和用量。
SPF、DKIM、DMARC 的隐蔽验证问题
基础测试通过,仍可能有单独发送路径配置错误。绿色勾选只是被测试路径的快照,不涵盖全部应用和收件方。验证是重要可能原因,但不能预先认定是最主要原因。
SPF:10 个相关查询项的预算
SPF 将实际求值路径中需要 DNS 查询的相关机制与修饰符限制为 10。使用 include:sendgrid.net、include:_spf.google.com 和 include:mailgun.org 时还需计算嵌套,不能只凭这几个 include 就判断超限。到 11 个相关项会产生 PermError,SPF 不再成功;有效且对齐的 DKIM 仍可让 DMARC 通过。转发也可能因连接 IP 改变使 SPF 失败。RFC 7208规定超出预算产生永久错误。供应商值应按最新说明检查。
完整配置步骤见如何正确设置 SPF。
DKIM:密钥长度与正文哈希
Google 要求 DKIM 密钥至少 1024 位,旧的 512 位密钥不满足该条件。选择器错误或轮换不完整可能破坏验证。新选择器应先发布,旧公钥保留供在途邮件验证。签名后追加页脚等修改若影响签名数据,可能让 DKIM 失败,但不是任何修改都会破坏所有规范化模式。
DMARC:域名对齐的陷阱
SPF 和 DKIM 各自成功,DMARC 也可能因为对齐不正确而失败。SPF 的验证信封域名需与 From 对齐,DKIM 的 d= 域名也一样。Relaxed 可按符合条件的组织域名判断,strict 要求完全相同。DMARC 对齐失败可能影响投递,但只需一种成功且对齐的方法即可通过。
例如 Mailchimp 完成验证,但 Return-Path 是 bounce.mailchimp.com,From 是 mycompany.com,SPF 不对齐。如果也没有有效且对齐的 DKIM,DMARC 失败。是否拒收取决于策略与收件方决定。DMARC.org 概述说明了相关原理。
为什么要关注 0.3% 投诉
投诉在 2026 年是重要信号,却不是唯一通用指标。Google 建议低于 0.1%,避免达到 0.3%。适用发件人的相关值可能影响问题缓解资格,不意味着 Google 和 Yahoo 立即把全部邮件送入垃圾箱。应查看每日数据、分母及具体规则。
Yahoo 按收件箱投递而不是总发送量计算。示例:发出 1,000 封,900 封进垃圾箱,100 封进入收件箱。一人举报,得到 1.0%,而不是 0.1%。差异重要,但不证明立即完全封锁。
增加发送量前,应查看可用的投递和投诉信号。域名信誉与发件信誉帮助评估风险,但不能保证送达。
RFC 8058 一键退订要求
从 2024 年六月起,Google 对适用批量发件人的相关推广邮件要求一键退订。页脚链接若仍要求登录偏好中心,不足以满足要求。技术实现包含以下标头:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
搭配正确 List-Unsubscribe、覆盖两个标头的有效 DKIM 和工作正常的 HTTPS POST 端点,支持的客户端可提供原生退订。按钮显示并不保证。POST 应完成相应退订,普通 GET 不应让安全扫描器意外退订。缺少完整实现可能违反要求并增加投诉。
道理很直接:难以退出时,用户可能选择举报。退订尊重其决定,投诉可能影响信誉。Google 的邮件发件指南明确列出适用批量发件人和相关邮件的一键退订条件。
不同服务商的过滤规则
不要把 Google、Microsoft 和 Yahoo 当成相同过滤器。各自评估不同信号,Gmail 成功不保证 Outlook 同样成功。
| 服务商 | 重要信号 | 有用工具 | 注意事项 |
|---|---|---|---|
| Google (Gmail) | 用户行为与验证 | Google Postmaster Tools,视数据可用性而定 | 0.3% 与适用投诉规则相关,内容和互动也可能参与评估。 |
| Microsoft (Outlook) | 包括 IP 信誉 | SNDS (Smart Network Data Services) | 首日 5,000 封可能因历史而受限,421 RP-001 是可能的临时响应,不是必然立即封锁。 |
| Yahoo (AOL/Verizon) | 内容、投诉和其他信号 | Complaint Feedback Loop (CFL) | 处理有效 ARF 反馈,并将相关地址加入适用的停发名单,重复邮件不必然导致完全自动封锁。 |
邮件内容中的风险信号
不只是某些 2010 年建议里的垃圾词。结构、链接和上下文也可能重要,即使文字看起来正常。
| 信号 | 可能含义 |
|---|---|
| Noreply 地址 | 不便回复与联系,但不自动导致推广分类或垃圾邮件。 |
| 公共短链接 bit.ly、tinyurl | 滥用和隐藏目标可能增加检查,不是全部短链接都会封锁。 |
| 纯图片邮件 | 不便阅读与内容分析,但没有统一文字图片比例要求。 |
| 错误 HTML | 可能影响显示和分析,正确标记有帮助但不保证投递。 |
共享发送 IP 的风险
代理机构需要关注 IP 架构,但它不是唯一因素。共享 IP 可能分担其他客户风险,滥用可能引起Spamhaus记录并影响合法邮件。但共享或低价服务不必然信誉差,需核查实际 IP、名单来源与收件响应。
专用 IP 可增加控制,但需要合适的量与维护。SendGrid 每月 $89+ 是原文价格示例,应查当前条件。管理 50 个客户时,要比较实际费用及运维成本。
TrekMail按套餐提供带滥用控制的托管 SMTP 和 BYO SMTP。后者可让自己的 Amazon SES 或 Mailgun 负责发送,邮箱留在 TrekMail。外部 IP 是共享还是专用取决于供应商。它分开运维任务,不保证完全隔离,也不是只有 TrekMail 才允许的模式。
如何实际排查
不要猜测,按以下顺序检查真实发送路径,缩小可能原因范围:
1. 检查标头。向 Gmail 发送并通过菜单查看原文。按可信收件端结果检查 SPF: PASS、DKIM: PASS 和 DMARC: PASS。FAIL 或 SOFTFAIL 值得调查,但有效且对齐的 DKIM 存在时,SPF 失败不意味着必须停止全部发送。
2. 种子测试。GlockApps 可查看选定测试邮箱中的收件箱、垃圾箱或推广分类,不能代表所有真实收件人。推广是正常收件箱分类,不是垃圾邮件;Mail-Tester检查技术与内容信号,不代替完整投递测量。免费选项、价格和可用性需核查,封锁名单查询也只覆盖部分来源。
3. 审核退信日志。5xx 是该次尝试永久错误,550 5.1.1通常表示未知用户,550 5.7.1可能涉及多种策略。4xx 是临时错误,421可能表示限速或其他临时问题。阅读完整响应。
不要配置一次就不再管理送达
在 2026 年,原因很多,包括 DNS。信誉、用户行为、内容和架构共同影响结果。理解每层有助于减少风险,却不保证永久不进垃圾箱。
尊重用户决定。提供简单退出,为适用邮件正确实施 RFC 8058。这可能减少投诉,不保证信誉。
有计划地分流。用合适域名与路径管理营销、事务和商务往来。独立域名可有帮助,但不自动防止共享信誉影响。
掌握发送基础设施。不要仅按用户价格决定架构。一个域名或 100 个客户,都可评估TrekMail的固定套餐与技术选项。核查现行限制及总成本,不能保证邮件不被过滤,也不能保证费用更低。
有关发送基础可继续阅读企业安全邮件。