香港邮件送达率：SPF、DKIM 与 DMARC 实操

先说结论： 那些"莫名其妙就消失"的邮件，几乎都是没通过一致性校验（alignment）的邮件。当第三方平台开始以你的域名发送订单确认或发票时，它必须先在 SPF 里获得授权，并且要用与你的域名对齐的 DKIM 签名——把工具接进收件箱，不等于把它接进了你的 DNS，而这道缝隙正是商业邮件"人间蒸发"最常见的原因。

为什么订单邮件突然就不来了？

设想一家香港的消费品牌——一家中型家居生活零售商，二三十到五六十名员工，通过自建官网和几个电商平台卖货——把客服系统换成了一套新的第三方支持平台。上线过程很顺利：工单分流正常，客服团队也喜欢新的收件箱界面，运营团队里没有人把这当成一个"邮件项目"，因为在他们看来，这就是一次客服系统升级。

一周之内，投诉开始出现。有客户打电话来问订单确认邮件在哪里；另一位说发票一直没收到，已经要求重发两次；一家物流合作方提到，发货通知邮件进了他们的垃圾邮件箱。乍看之下这不像同一个事故，更像几件互不相关的小麻烦，运营经理最初几天也是这么处理的：这边当成过滤器抽风，那边当成客户手误。

但这既不是巧合，也不是垃圾邮件过滤器的随机行为。新平台在发送订单确认、发票、物流通知这类事务性邮件时，发件地址用的是品牌自己的域名——因为只有这样，邮件在客户看来才是"正牌"的。要让这件事站得住脚，这个平台就必须被你的域名"授权"，就像任何发件方都需要被授权一样：要么写进 SPF，要么用 DKIM 签名，理想情况下两者都要，而且更重要的是，这种授权必须与客户实际看到的那个域名"对齐"（aligned）。换客服平台的时候没有人动过 DNS，因为在大多数人眼里，上线一个客服系统看起来根本不像是一次 DNS 变更。而这篇文章要讲的，恰恰就是这道缝隙：新增了一个发件方，却从没有把它加进域名的身份验证配置里。

这篇文章写给正对着一堆"你们的发票发了吗"的留言、而客服平台供应商又说"我们这边一切正常"的运营或电商经理——从平台的角度看，它确实没问题，邮件确确实实发出去了。至于发出去之后发生了什么，那是一个 DNS 问题，而 DNS 恰恰是没有人认领的那部分。

三条记录，和真正起决定作用的那个词：对齐

几乎所有关于 SPF、DKIM、DMARC 的介绍都停留在"这是你需要的三样东西"，逐一解释是什么，却跳过了真正决定你的订单确认邮件能不能送达的那部分。那部分就是"对齐"（alignment）。哪怕三条记录单独看都配置正确，只要对齐没做对，邮件照样会失败。

SPF（发件人策略框架） 是你域名下的一条 DNS TXT 记录，列出哪些邮件服务器有权以你的名义发信。它核对的对象很具体：信封发件人（envelope sender），有时也叫 Return-Path 或 MAIL FROM 地址——这是邮件投递过程中使用的一个技术字段。这一点值得说清楚，因为几乎所有科普文章都会漏掉它：SPF 核对的，并不是客户在收件箱里看到的那个地址。 它核对的是客户根本看不到的一个后台地址。一封邮件完全可以顺利通过 SPF 校验，而客户看到的发件人域名，其实是 SPF 压根没提到过的另一个域名。

DKIM（域名密钥识别邮件） 是附加在外发邮件上的加密签名，用来核对的公钥发布在你的 DNS 里一个特定位置——由一个"选择器"（selector）加上你的域名组成，所以用选择器 s1 在 yourbrand.com 上做的签名，会去查 s1._domainkey.yourbrand.com 这条 DNS 记录。签名证明了邮件在传输过程中没有被篡改，也证明了持有对应私钥的一方确实发送了这封邮件。关键在于，DKIM 签名"归功"给谁——签名里的 d= 值——完全取决于签名方选择以谁的名义签名，它同样不需要和可见的发件人地址一致。第三方平台完全可以用自己的域名给自己发的邮件签上一个技术上完全有效的 DKIM 签名，这个签名和你的品牌毫无关系。

这就是为什么上面两项各自都对，邮件却依然会失败。DMARC（基于域名的消息认证、报告和一致性） 正是用来堵上这道缝隙的记录。DMARC 本身不引入新的验证方式——它拿 SPF 和 DKIM 的验证结果，再多做一步核对：真正通过验证的那个域名（SPF 的 Return-Path 域名，或者 DKIM 的 d= 域名），是不是和客户实际看到的发件人地址域名一致，或者足够接近？这一步叫做标识符对齐（identifier alignment），DMARC 记录可以用两种方式要求它。宽松对齐（relaxed alignment，通常是默认值）只要求组织域名这一层级一致，所以 mail.yourbrand.com 可以和 yourbrand.com 对齐。严格对齐（strict alignment）则要求双方的完整域名完全相同。只要 SPF 通过且对齐，或者 DKIM 通过且对齐，邮件就能通过 DMARC——两者满足其一即可，但至少要有一项是真正"对齐"的，而不只是"验证通过"。

说得直白一点：你的品牌完全可能同时拥有教科书式的 SPF 和 DKIM 配置，两者技术上都无懈可击，却依然彻底通不过 DMARC——因为真正通过每一项检查的域名，是平台的域名，不是你的域名。这正是上面那个场景里发生的失败方式，也值得再强调一遍，因为几乎所有仓促的科普都会漏掉这一点：这三条记录本身不是目的，让平台的发信行为对齐到客户看见的那个域名才是目的，记录只是手段。

新增一个第三方发件方，具体是怎么把邮件"发丢"的？

先看看新平台上线之前的 DNS 状态。如果 Microsoft 365 或 Google Workspace 在最初部署时配置得当，通常意味着已经有一条能正常工作的 SPF 记录，主发信域名上启用了 DKIM，而如果当初负责部署的人足够细心，很可能还已经发布了 DMARC 记录——甚至已经处于强制生效的策略下，因为这如今越来越是一种审慎的默认做法，而不是例外。日常员工邮件顺利通过验证，没有人会再去想这件事。

接着客服平台上线，被配置成以品牌名义发送订单确认和发票——因为一封看起来来自某个通用平台域名的邮件，转化率和可信度都不如一封看起来直接来自品牌本身的邮件。平台的外发邮件服务器从未被加进品牌的 SPF 记录。平台或许会给自己的邮件签上 DKIM，但用的是自己的 d= 域名，不是品牌的域名——因为品牌从来没有为这个平台生成并交付过一对 DKIM 密钥供它签名。客户看到的发件人写着 orders@yourbrand.com。无论是 SPF 还是 DKIM，都没有产生一个能对齐到 yourbrand.com 的验证结果。DMARC 失败。

接下来发生什么，完全取决于品牌 DNS 里早已存在的那条 DMARC 策略——这正是为什么一个从没听说过 DMARC 这个词的运营经理，反而会成为收拾这场烂摊子的人。如果域名发布的是 p=reject，收件服务器会直接拒收这封邮件：发件方那边看不到任何形式的退信提示，订单确认邮件在客户的收件箱看来就是根本不存在。如果域名发布的是 p=quarantine，邮件通常会被投递到收件人的垃圾邮件或杂件箱——这就解释了为什么"我在垃圾箱里找到了"和"我根本没收到"这两类投诉会混在一起出现：两者是同一个底层失败，只是落在了处理隔离策略略有不同的收件系统上。如果域名发布的是 p=none，或者干脆没有 DMARC 记录，邮件送达的概率会更高，但域名对"任何人冒充品牌发送未验证邮件"这件事也就完全没有防护——这是另一个问题，本文不打算展开，而是留给下面提到的另一篇文章。

真正正确的修复方式，只有两种，也只有两种。想靠"让平台别用我们的域名发信"来解决送达问题，等于是放弃了品牌化的发件地址，而这通常不是企业想要的结果。能在保留品牌发件地址的同时让它顺利通过验证的两种修复方式是：

修复第三方发件方的两种方式，各自需要做什么

把平台加进 SPF。 平台文档通常会为此专门提供一个 include: 值——类似 include:mail.platformname.com。把它加进你的 SPF 记录，就等于授权该平台的服务器可以使用你的信封域名发信。这是改动较小的一步，但它只解决了 DMARC "二选一"里的 SPF 那一半——对 DKIM 毫无帮助，而且会让你离 SPF 的十次查询上限（见下文）更近一步，如果你已经接入了不少发件方，这一点尤其要注意。
让平台用对齐到你域名的 DKIM 签名发信。 这是更稳妥的修复方式，因为 DKIM 对齐即便邮件被转发也依然有效，也不依赖收件服务器信任邮件走过的那条网络路径——而这恰恰是 SPF 的弱点。要做对这一步，通常需要为你的域名生成一对 DKIM 密钥，把公钥发布到平台指定的选择器下、挂在 _domainkey.yourbrand.com 之下，再把私钥交给平台用来签名——如今更常见、也更不容易出错的做法是，平台直接给你一条 CNAME 记录，由它自动完成签名，而不需要你手动处理原始密钥。

两者都做并不是过度配置，恰恰相反，这是常态——正因为 DMARC 只需要其中一项通过，同时配置两者意味着任何一个机制临时出问题，都不会单独拖垮你的邮件发送。真正不该做的，也算不上"修复"的做法，是把平台加进 SPF 之后就此打住，还以为"SPF 和 DKIM 反正差不多"。它们核对的是完全不同的东西，可以各自独立出错，而 DMARC 的对齐检查也是分别针对两者进行的。

不借助任何工具，一份 DMARC 报告到底能告诉你什么？

DMARC 记录里的 rua 标签——一个写在你 DMARC DNS 记录里的邮箱地址——会要求收件邮件服务器每天给你发一份关于"声称来自你域名"的邮件的汇总报告：哪些通过了，哪些失败了，来自哪里。这些报告通常以压缩过的 XML 附件形式送达，哪怕暂时用不上专门的监控工具，光靠手动阅读几份报告来排查单次事故，也是完全可行的。

在每份报告里，最重要的字段是 source_ip，它告诉你邮件实际是从哪台服务器发出的——正是靠这个字段，你才能查出一大批失败的邮件其实来自客服平台名下的一个 IP 段，而不是什么可疑来源。紧挨着它的 count 字段，记录了从这个 IP、以同样结果发出的邮件数量，这才能把"这个平台好像时不时会出问题"变成"这个平台上周发了 4000 封邮件，其中 3850 封没通过对齐检查"这种具体结论。再往下是 policy_evaluated，记录的是你域名的策略要求收件方对这封具体邮件做什么处理——它的 disposition（正常投递记作 none，转入垃圾箱记作 quarantine，直接拒收记作 reject），以及这封邮件的 dkim 和 spf 评估结果。最后是 auth_results，分别针对 DKIM 和 SPF，显示实际核对的是哪个域名、结果是否通过——正是在这里，你能直接看到 DKIM 对 platformname.com 是通过的，而你自己域名的对齐却失败了，这是证明"问题出在第三方发件方而不是记录本身写错了"最直接的证据。

最值得盯着看的三个数字，按顺序是：某个 source_ip 的总发信量；这批邮件里 disposition 不是你期望结果的比例；以及那个未通过验证的字段里，auth_results 显示的域名是不是你认识的发件方。如果是，你就找到了第三方发件方的问题所在。如果不是，你可能发现了别的情况——有人在冒充你的域名发送你从未发过的邮件，这是另一个更严重的话题。

DMARC 策略应该多"严"？直接设成 reject 会在哪里出问题？

DMARC 的 p= 标签有三个取值，构成的是一个有意设计的台阶，而不是一个开关。p=none 要求收件方对未通过验证的邮件不做特殊处理，但仍然给你发报告——这是观察阶段，任何域名都应该从这里开始，哪怕这个域名已经运行多年、DMARC 策略从来没人检查过。p=quarantine 要求收件方把未通过验证的邮件当作可疑邮件处理，通常投进垃圾邮件箱而不是收件箱。p=reject 要求收件方直接拒收。pct 标签可以让这三种处理方式只作用于一定比例的失败邮件，而不是全部，这正是让"分阶段上线"而不是"一刀切"成为可能的机制。

一个域名如果还有未知的发件方，就绝不应该直接跳到 p=reject，原因正是本文开头那个场景反过来发生一遍：如果客服平台（或者发票工具、营销发件方、会发送送货单的 ERP 系统）还没有正确完成身份验证，直接切到拒收并不能解决任何问题——只会让原本存在的失败变得彻底而且立刻发生，而且完全看不出是哪个发件方先出的问题。真正管用的顺序是：先发布带报告地址的 p=none，认真读完一整个正常的业务周期的报告——长到足以覆盖一次完整的月结、一次营销发送和日常的订单量——直到每一个合法发件方都显示为已验证且已对齐；然后再切到 p=quarantine，最好从较低的 pct 开始，报告持续干净再逐步提高；最后才切到 p=reject。跳过观察阶段，就是在把域名"保护"进一场自己造成的邮件中断里。

SPF、DKIM、DMARC 都配置正确之后，还有什么会悄悄拖累送达率？

把三条记录的对齐问题解决了，只是排除了最常见的原因，不是唯一的原因。以这类规模的企业来说，还有几个相邻的问题经常出现，值得单独说清楚。

共享发信 IP——常见于一些价格较低的事务性邮件附加服务，以及部分客服平台的外发邮件——意味着你的送达率会部分取决于共享这个 IP 的其他客户。只要其中一个客户发的邮件导致这个 IP 被标记，你完全合规的订单确认邮件也可能被牵连，而这与你自己的域名配置毫无关系。

SPF 查询次数超限 是同一类问题的慢动作版本，值得专门检查：SPF 校验的上限是 10 次 DNS 查询，计入 include、a、mx、ptr、exists 和 redirect 这几种机制——一个多年下来陆续接入了营销平台、电商平台、客服平台、财务系统、快递通知服务的域名，SPF 记录很容易在不知不觉中超过这个上限，一旦超限，整条 SPF 检查就会返回永久性错误，实际上等于对记录里列出的所有发件方都失去了保护，而不只是最新加进来的那一个。

Return-Path 缺失或配置不当——这是 SPF 真正核对的那个技术地址，区别于客户看到的发件人地址——可能导致 SPF 核对了一个完全不该核对的域名，尤其是当某个平台用它替你管理的一个子域名发信、而你的团队从未查看过那个子域名自身的 SPF 状态时。

以及内容本身看起来像钓鱼邮件，这与身份验证完全无关——发送模式异常、使用了不熟悉的短链接服务、或者措辞触发了收件服务器的内容过滤规则——即便 SPF、DKIM、DMARC 全部顺利通过，依然可能被拦截送达，因为身份验证和内容过滤是两套独立的系统，各自对同一封邮件做出判断。

这件事到底该由谁长期负责？

划分责任最清晰、也最经得起下一次换平台考验的方式是：DNS 归你，平台归它，日常监控归负责管理你 Microsoft 365 或 Google Workspace 租户的那一方。 平台的职责是在自己的文档里说清楚，它需要哪个 SPF include 值或者哪条 DKIM CNAME 记录。而你——或者你的 IT 服务商——的职责，是真正把这条 DNS 记录改好，确认它已经生效并且解析正确，并在把这次接入当作"完成"之前，从 DMARC 报告里确认这个平台的邮件确实显示为已验证且已对齐。把"供应商说已经配置好了"当成流程的终点、而不做独立的 DNS 核实，正是这种失败会在每次新增发件方时反复出现的原因。

香港品牌处理新发件方接入的三种方式

没有人负责，只有出问题才会去动 DNS。 平台上线，邮件开始发送，直到客户投诉，才第一次有人听说 SPF 或 DMARC 是什么。这正是把客服平台上线当成一个纯客服项目、而不是一个邮件项目所带来的默认结果，也正是本文场景里那个品牌所处的位置。
DNS 只在上线那一刻检查一次，之后再也没人看过。 通常是当初搭建 Microsoft 365 租户的那个人，把新平台的 SPF include 加进去就算完事。这能拦住最明显的问题，却拦不住"漂移"：某个平台更换了发信基础设施；一份没人读的 DMARC 报告，本可以提前显示出另一个不相干的发件方正在悄悄失败；SPF 查询次数随着这一年陆续接入更多工具，一点点逼近上限。
DNS 变更纳入管理型服务流程，DMARC 报告真的有人在读。 每一个新发件方在正式上线前都会先完成身份验证并对照报告核实，SPF 记录会定期检查是否接近查询上限，DMARC 策略也会被有意识地逐步推进——先 none，再 quarantine，最后 reject——而不是停留在当初随手设定的那个状态。这是三种方式里唯一能在客户之前先发现第二个失败发件方的做法。

Brocent 在这方面做什么，这和防欺诈有什么不同？

有必要说清楚这篇文章和另一篇密切相关的文章之间的区别，因为两篇都在讲 SPF、DKIM、DMARC，讲的却不是同一个问题。我们关于香港一家批发商险些遭遇供应商付款欺诈的文章讲的是相反的方向：邮件从外部发到你这里，看起来来自真实的供应商，要求你把款项付到一个不同的银行账户。那篇文章里对 SPF、DKIM、DMARC 的讨论，说的是这些记录能在多大程度上阻止别人冒充某个发件人向你发信、又在哪些地方无能为力。而这篇文章说的是你自己的外发邮件送不到自己客户手里——原因是你自己新接入的一个发件方，从来没有被正确地做过身份验证。同样的三条 DNS 记录，同样的底层机制，方向相反，修法也不同。

Brocent 的管理型IT云服务直接覆盖了 Microsoft 365 这一侧：部署时就把 Exchange Online 配上 SPF、DKIM、DMARC，同时通过 Microsoft Defender for Microsoft 365 启用安全链接、安全附件和反垃圾邮件——标准上线流程里的身份体系搭建这一步，从第一天起就包含为域名配置 SPF 与 DMARC，而不是等到某个第三方发件方把这个缺口暴露出来才去补。如果企业需要的是反钓鱼、身份冒充检测这一侧，而不是身份验证记录这一侧，这属于管理型电邮安全的范畴——在 Microsoft 365 或 Google Workspace 环境前叠加反钓鱼与商业邮件欺诈检测、勒索软件与恶意软件拦截，以及隔离管理。这两项服务在这里都相关，但原因不同：云服务这一侧是从一开始就把你自己的身份验证配对；电邮安全这一侧解决的是当你开始担心"邮件从另一个方向打过来"时的问题——那正是上面链接的那篇文章在讲的事，而不是这篇。

不管选择哪项服务，都无法替你自动完成某个具体第三方平台的身份验证——总得有人真正去读那个平台的文档，按它的要求完成 DNS 变更，这一步永远是针对具体发件方的，没有哪种管理型IT外包服务能替代它。外包关系真正改变的，是事后有没有人在持续盯着 DMARC 报告，以及 SPF 记录会不会在悄悄逼近查询上限之前被人发现。

常见问题

为什么我们的邮件之前一直正常，突然就不行了？

几乎总是因为有一个新的发件方被接入到你的域名外发流程里——客服平台、营销工具、开票系统——却没有同步修改 SPF 或 DKIM。域名原有的邮件，直接来自 Microsoft 365 或 Google Workspace 的那部分，验证结果和以前一模一样；只有新发件方发出的邮件会失败，这也是为什么问题看起来是"时好时坏"，而不是彻底不通。

我们把平台加进 SPF 记录就够了吗？

有帮助，但那只是 DMARC 检查的一半。SPF 通过且对齐是满足 DMARC 的一种方式，DKIM 通过且对齐是另一种。只把平台加进 SPF，意味着你完全依赖 SPF 对这个发件方持续有效——包括邮件实际经过的网络路径——一旦哪个环节出问题，又没有 DKIM 签名兜底。更稳妥的做法是两者都配置。

DKIM 对齐具体是什么意思？

DKIM 对齐指的是：一个有效 DKIM 签名"归功"给的那个域名——也就是签名头里的 d= 值——和客户看到的发件人地址所在的域名一致，或者在宽松对齐的规则下，至少属于同一个组织域名。一个平台完全可以整天用自己的域名给自己的邮件签上技术上有效的 DKIM 签名；除非它是以你的域名签名，否则这些签名没有一个对你来说是"对齐"的。

这类 DNS 变更真的需要多久才能生效？

DNS 记录本身通常在几分钟到几个小时内就会生效，具体取决于被替换那条记录原来设置的 TTL（生存时间）。出于规划考虑，更稳妥的做法是预留 24 到 48 小时再判断变更是否成功，并且直接用 DNS 查询工具核实这条记录，而不是只靠"客户是不是还在投诉"来判断。

我们应该把 DMARC 策略设成 p=reject 吗？

最终应该达到这一步，前提是能安全地走到那里——但不应该作为第一步动作，也不应该在还有发件方尚未完成身份验证的情况下这么做。安全的顺序是先 none，再 quarantine，最后 reject，只有在 DMARC 报告显示每一个合法发件方都通过验证且已对齐之后，才进入下一阶段。在还有未核实发件方的域名上直接跳到 reject，很可能会悄无声息地拦下你本来最想保护的那部分邮件。

我们需要专门的 DMARC 监控服务吗，还是自己看报告就行？

如果只是排查单次事故，像上文那样手动读几份汇总 XML 报告完全可行。但如果域名长期接入多个第三方发件方，并且打算逐步走向 p=reject，一个监控服务，或者一个真的会按计划审阅报告的管理型IT服务商，能比不定期的人工检查更早发现"漂移"——比如后来新加的发件方，或者某个平台悄悄更换了发信基础设施。

这只是 Microsoft 365 才有的问题吗，其他平台会不会也这样？

不管你的主力邮箱平台是什么，机制都完全一样——SPF、DKIM、DMARC 是互联网标准，不是 Microsoft 或 Google 的专属功能。本文描述的场景，在 Google Workspace 上或者任何其他邮件平台上，只要接入了一个没有同步做 DNS 配置的第三方发件方，都会以完全相同的方式发生。

企业内部到底应该由谁来负责我们的 DNS 和这套配置？

责任应该落在日常管理 Microsoft 365 或 Google Workspace 租户的那一方——内部 IT，或者一家管理型IT外包服务商——而不是营销部门、电商运营部门，或者恰好是签下那个触发问题的平台的那个部门。平台供应商能告诉你它需要什么；但只有真正掌控域名 DNS 的那一方，才能核实变更做对了，并且在未来不断接入新发件方的过程中持续保持正确。

在下一次换平台之前，先把责任划清楚

本文场景里的这个品牌，既没有安全问题，也没有平台问题——客服平台的表现完全符合设计预期。它出的是一个责任缺口：一次本该伴随产品上线同步进行的 DNS 变更，却没有人把这两件事联系在一起、意识到需要去做。修复眼前这次失败，只需要一次 DNS 变更加上几天读报告的工夫。修复这个模式本身，则需要一次性地定下来：以后每接入一个新发件方，由谁负责检查身份验证和对齐——赶在下一个客服平台、营销工具或开票系统悄悄重演同一个失败之前。

如果你的团队正在处理最近换了平台或供应商之后开始消失的邮件，或者希望在下次改动之前先把 DNS 和 DMARC 报告认真核查一遍，欢迎联系我们的团队。如果你想先了解这如何融入一套管理型 Microsoft 365 方案、成本大概是多少，我们的定价页面和按用户计费的管理型IT外包方案说明了具体模式。