开发信总进垃圾箱？先查这三项邮件认证，再找服务商

做外贸的老板，几乎都遇到过同一个困惑：开发信在发件箱里显示”已发送”，客户却一直没回；再一问，对方说”根本没收到”，或者邮件进了垃圾箱。很多人第一反应是换文案、换邮箱、换话术，但真正的问题可能根本不在这几层。

这篇文章不谈文案、不谈话术，只讲一件事：当开发信进不了收件箱时，怎么判断是不是邮件认证的问题，以及该向邮箱服务商问哪些对的问题。
你会拿着这份清单去问人，而不是被人问住。

先分清邮件走到哪一步了

一封开发信从你点下”发送”，到客户回复，中间隔了五段路：

1. 发出——你的系统显示发送成功；
2. 对方服务器接收——对方邮件服务器收到并确认；认证失败时，也可能在这一步被直接拒收或限制投递；
3. 进入收件箱——被归入收件箱而不是垃圾箱；
4. 真实阅读——收件人真的点开看了；
5. 产生回复——对方愿意回你。

邮件认证可能影响对方服务器是否接收邮件，以及接收后如何处理；它不是只在收件箱与垃圾箱之间起作用。通过认证也不保证客户阅读或回复。

所以先把预期摆正：认证解决的是”身份可信”的问题，不是”对方一定想看”的问题。

三项认证，各回答一个”是不是”

SPF、DKIM、DMARC 是邮件认证最常用的三项，国外主流邮箱（Gmail、Outlook
等）都会核对这些结果。Mailchimp
官方的邮件认证协议科普把它们的配合比作”数字身份证系统”（页面发布
2026-04-08），用大白话拆开就是：

SPF（发件方政策框架）——“这封邮件是不是从我授权的服务器发出来的？”
你作为域名的主人，可以先声明”我的域名授权哪些服务器发信”。接收方收到邮件后，核对实际发信服务器来源是否在这份授权名单里。不在名单里的来源，就可能被判为可疑。注意：SPF
核查的身份通常是信封发件域（实际发送所用的域），并不单独认证用户在界面上看到的发件人地址（From
域）。这相当于给域名设了一张”嘉宾名单”，防的是有人冒充你的域名发信。

DKIM（域密钥识别邮件）——“这封信的内容有没有被人动过，签名是不是真的？”
发信系统会给邮件加一个数字签名，接收方用公开在 DNS
里的公钥验一遍：签名有效、且签的确实是这封信的内容，说明签名所覆盖的那部分内容在传输途中没有被改动。注意，DKIM
核验的是签名覆盖的内容，不是整封邮件的所有内容、所有字段都逐项验证过、都未改变；签名有效也不代表发件方在邮件里的所有陈述都可信。相当于数字”封条”。

DMARC——“收件人看到的发件人，能不能对上已通过的认证身份？”
前两项各管一段，DMARC 把它们串起来：它检查收件人看到的 From
域，能否与至少一种已通过的认证身份对齐。SPF 或 DKIM
至少一项通过并满足对齐要求，即可通过
DMARC；某一项失败或不对齐，不代表整封邮件必然 DMARC
失败，如果另一项已通过且对齐，仍可通过。不能获得任一条有效对齐认证时，域名公布的策略为接收方如何处理提供依据，最终处理还取决于接收方。DMARC 判定规则见 RFC
9989。这一步把”用户看到的发件域名”和”实际认证通过的域名”做比对，称为域对齐——有时签名和授权都通过了，但收件人看到的发件人域名却是另一个，DMARC
专门堵这个漏洞。

一个容易理解错的点：DMARC
通过，不是”SPF 和 DKIM
必须同时通过”。举个例子：某个发信渠道的 SPF 检查失败，但 DKIM
通过，且签名域与 From 域满足现行对齐模式，这封邮件仍然可以通过
DMARC。反过来，某一项通过了但域不对齐，也不代表整封邮件一定失败——要看另一项是否通过且对齐。SPF
过了但域不对齐，或 DKIM
过了但对齐不满足现行模式（宽松或严格）要求，都不算 DMARC
通过。跟服务商核对的时候，别被一句”都通过了”带过去，要问清楚是哪一项、哪个域、按哪种模式对齐。

认证不等于加密，更不等于允许你发

还有两件事，认证本身说明不了：

• 认证不等于加密。认证证明的是”这是不是你发的、内容有没有被改”，不等于邮件全程传输是加密的。两者是不同的事。
• 认证不等于营销许可。认证通过只说明”这封信确实来自你”，不说明收件人同意你发信。对方有没有订阅、愿不愿意收，是另一套规则（比如欧美市场的许可与退订要求）。

另外，Mailchimp
原文对认证效果的表述用的是”更有可能进入收件箱”（improved
deliverability，更可能送达收件箱而非垃圾箱），不是”保证送达”。认证能降低一部分风险，但不保证进收件箱。
谁告诉你”配了这三项就一定进客户收件箱”，谁就是在夸张。

开发信进垃圾箱，认证只是原因之一

认证不通过，是”发送基础”的问题；但垃圾箱判定还受别的东西影响：名单质量（对方认不认识你、是不是首次接触陌生域名）、内容特征、发送频率、历史投诉和退订率，以及接收方自己的过滤规则。排查要分层：

• 认证排查，回答”我的发送基础干不干净”；
• 名单与内容排查，回答”我发给了谁、写了什么”。

两层问题要分开查，可以先按发信渠道核对发送基础，再结合名单与内容判断；这不是规定所有故障都必须按同一套顺序串行排查——具体哪一层先查，取决于实际现象：某个渠道一直发不出去，先看这个渠道的认证；普遍能送达但打开、回复很差，重点在名单与内容。别把所有锅都甩给
SPF/DKIM/DMARC，也别把文案改十遍，结果发现是认证根本没配。

三步排查：盘点渠道 → 取信头 →
找服务商

按照这个顺序做，不需要你自己碰 DNS，也不需要懂技术细节。

第一步：盘点实际发信渠道。

把所有用你域名发信的渠道列成一张表：企业邮箱（外贸邮箱）来自哪家服务商、发开发信用哪个平台、CRM
或售后系统会不会自动发信、有没有员工在用别的工具绑定公司域名。每一项都要能回答”这是谁在替我的域名发信”。Mailchimp
官方在认证最佳实践里强调的第一条就是”全面审计正在用你域名发信的系统”，因为名单漏一个，后面就可能出现”这家平台发不出去”的怪事。

第二步：每个实际渠道分别发一封测试邮件，取回认证结果。

每个实际发信渠道分别发送测试邮件：企业邮箱、EDM 平台、CRM
自动信等各发一封到你自己的另一个收件邮箱（或让服务商配合各测一封到
Gmail、Outlook），然后在收件端打开”查看原始邮件 / 显示原始内容”（Show
Original），逐封查看认证结果。正常会看到类似这样的字段（脱敏示意，来源：本文假设演示，用于展示字段长相，不是真实邮件）：

Authentication-Results: mx.receiver-example.com;
  spf=pass (发信来源在授权名单内) smtp.mailfrom=sales@demo-corp.com;
  dkim=pass (签名域 header.d=demo-corp.com);
  dmarc=pass (p=NONE, From 域与认证域对齐) header.from=demo-corp.com

要记下来的不止是三个结果，还有每个结果对应的域：SPF
的信封发件域、DKIM 的签名域、DMARC 的 From
域，并且按渠道分开记录。哪一项
fail，是把对应结果交给服务商核实的入口；不要把任何一项 fail
直接当成”这封邮件进了垃圾箱”的已证实原因——垃圾箱判定还受名单、内容、频率和接收方过滤规则影响。

第三步：带着结果找服务商核实。

把截图或原信头发给你的邮箱服务商（企业邮箱供应商、EDM
平台客服都行），让他们解释：为什么
fail？是记录没配、配错了，还是域名不对齐？谁来改、什么时候能改完？你不需要自己动手，但你要拿到一句明确的话：问题在哪、责任在哪、下一步是什么。

带着这些结果去问服务商

以下是老板可以直接照着发的问题，都是服务商能回答、也必须能回答的：

• SPF：我这套配置里，授权发信的服务器是不是都列进去了？有没有多条
  SPF 记录冲突？ （SPF 有只能执行 10 次 DNS 查询的上限，Mailchimp
  官方明确提到过这条限制；服务商应该知道怎么合并、怎么控制查询次数。）
• DKIM：签名用的是哪个域名？与收件人看到的发件域名是否满足现行对齐要求？
• DMARC：当前是宽松还是严格对齐？按现行模式，实际认证域与 From
  域是否满足要求？策略是 p=none（只监控）、p=quarantine（隔离）还是
  p=reject（拒绝）？报告谁能看、多久出一次？
• 批量发送：我目前的发信量级，Gmail
  和其他主流邮箱对我有没有额外的门槛？
  ——注意，批量发送的配置要求，和单封邮件的认证判定是两套东西。Google
  官方《邮件发送者指南》对”向 Gmail
  大量群发的发件方”另有认证门槛（只适用于达到触发量的群发方，并非所有企业都要执行），具体阈值以
  Google 现行指南为准，让服务商按你的实际量级给你答案。

为什么不要一步到位开最严策略

DMARC 策略从松到严有三个档：先只监控（p=none）→
再隔离可疑邮件（quarantine）→ 确认无误后才拒绝（reject），这是
Mailchimp
官方建议的渐进顺序，原因是：如果你的某个发信渠道其实还没配好，一上来就开”拒绝”，先被拦掉的可能是你自己的合法邮件——客户还没说什么，你的报价单先进了黑洞。

Mailchimp
的建议是：大多数组织需要先积累几周到几个月的监控数据，确认所有正当发信渠道都能通过认证，才敢切到完全拒绝。所以别听谁劝你”明天就把策略开到最严格”，那不是负责任的做法，至少要先让监控数据说话。特别提醒：单个渠道一封测试邮件通过，不等于所有渠道都稳定，不要因此直接把策略一步切到
reject。

三类常见坑，提前避开

1. 加了个新工具就忘了更新。Mailchimp
   建议每季度过一遍你的发信名单，新增平台、换服务商、改域名，都要重新测一遍认证；否则”之前是好的”只是”之前”。
2. 把认证当保险箱。配好了认证，不代表开发信就一定能进客户收件箱，更不代表客户会回。认证只是把”发送基础”这层问题解决掉。
3. 自己去客户 DNS
   抄通用记录来改自己的域名。每家服务商的记录值、对齐要求都不一样，网上的”万能配置”对不上你的实际渠道，抄错比不配还麻烦。正确动作是把你测到的
   fail 结果交给服务商，让他们按你的域名和渠道出配置。

本周只做一件小事

不用等大动作：今天起，把你所有发信渠道列一张表；然后每个实际发信渠道各发一封测试邮件，把原信头里
SPF、DKIM、DMARC 三个结果和对应域分别抄下来；最后把 fail
的项发给服务商，问一句”为什么、谁改、什么时候改完”。

你能判断”认证问题”和”名单与内容问题”的区别，就不会再在错误的一层反复试错。邮件发送基础、名单质量、文案吸引力，是三件不同的事——先分清楚问题在哪一层，再决定花力气改哪一层。这一点，比任何”送达率秘籍”都实在。