DMARC 缺失：冒充邮件为何能直达客户？

Sat, 07 Nov 2026 09:00:00 +0800

问题背景

公司的对公邮箱用的是 Microsoft 365，域名是 example.com。日常发信有三类来源：员工在 Outlook 里正常收发、市场部用一家 SaaS 平台发活动通知、ERP 通过本地 SMTP 中继给客户发发货和账单邮件。三类来源各自配置，IT 只保证“能发出去”，从来没在 DNS 里配过 SPF、DKIM 或 DMARC。

上个月，几个老客户先后把收到的邮件转给销售：发件人显示是 service@example.com，标题是“【发货通知】您的订单已发出”，正文让点击链接查看物流，链接指向一个仿冒的登录页。客户问“这是你们发的吗”，销售一看域名是真的、签名栏也是公司的，差点没看出来。

故障现象

多封仿冒邮件发件人显示名和地址都是公司域名，内容围绕发货、账单、合同，针对性很强。
客户邮件网关的 Authentication-Results 里，SPF、DKIM、DMARC 三项全是 none，没有任何认证结果。
有一封邮件甚至进了客户高管的收件箱，没有进垃圾箱；客户的安全团队随后发来问询。
公司自己的邮件网关只按内容打分，没有发件人认证数据可用，无法判断哪些是真、哪些是假。
检查 DNS：example.com 没有 SPF 记录，_dmarc.example.com 不存在，DKIM 选择器也查不到公钥。
市场部、ERP 的邮件一直正常发着，员工侧完全没有感知。

排查过程

第一步确认仿冒方式。把客户转来的邮件头完整取出来看：From 是 service@example.com，Return-Path 是攻击者自己的域名，Authentication-Results 三项都是 none。这说明收件方没有任何依据去验证发件人，只能按内容打分；内容写得像正经业务邮件，就很容易过。

第二步查 DNS 配置。dig TXT example.com 没有任何以 v=spf1 开头的记录；dig TXT _dmarc.example.com 返回 NXDOMAIN；再按常见选择器查 selector1._domainkey.example.com 和 selector2._domainkey.example.com，也没有记录。SPF、DKIM、DMARC 三件套一个都没有。

第三步解释为什么“没有记录”就等于“随便冒充”。SPF 用发信 IP 和域名授权列表做比对，没有记录时收件方只能返回 none；DKIM 用私钥签名、公钥验签，没有签名就无法证明邮件经过公司授权；DMARC 则要求 SPF 或 DKIM 至少一项与 From 域名对齐，并告诉收件方“认证失败时怎么处理”。三者都没有，收件方既没有证据、也没有策略，仿冒邮件就按普通邮件处理。

第四步梳理合法发信源。这一步不能跳：SPF 一旦配错，正常邮件会被自己拦掉。逐个确认：M365 的出口、市场 SaaS 的发送域和 SPF include、ERP 中继的公网 IP，以及是否有其他部门在用第三方邮件服务。把所有来源列成清单，再算 SPF 的 DNS 查询次数，确保不超过 10 次上限。

第五步设计分阶段方案。直接上 p=reject 风险太高，先 p=none 只收集报告，观察哪些合法来源认证失败；修完再进 p=quarantine，最后到 p=reject。这样既保护域名，又不会把业务邮件误杀。

第六步验证。配置完成后，从 M365、市场 SaaS、ERP 各发一封测试邮件到外部邮箱，确认 SPF、DKIM、DMARC 全部 pass；再从一台外部 VPS 伪造 service@example.com 发信，确认收件方按 DMARC 策略拒收或隔离。

解决方案

先补 SPF：在 example.com 发布一条 TXT，把 M365、市场 SaaS 和中继 IP 都 include 进去，结尾用 -all 表示未授权 IP 一律失败。注意 SPF 的 10 次 DNS 查询上限，include 太多时要合并或做 flatten，不要拆成多条 SPF 记录。
再上 DKIM：在 M365 启用 DKIM 签名，发布 selector1/selector2 公钥；市场 SaaS 在平台侧开启 DKIM 并把选择器记录加到 DNS；ERP 中继如果支持 DKIM 就签名，不支持则至少保证 SPF 对齐。
DMARC 分三步走：第一阶段 p=none，带 rua 收集聚合报告，跑两到四周；把报告里认证失败的合法来源逐个修好；第二阶段 p=quarantine，可先用 pct=25 逐步放量；第三阶段 p=reject，并给子域设置 sp=reject。
收件侧配合：确认公司邮件网关支持并按 DMARC 结果处理入站邮件；对员工做一次识别仿冒邮件的提示，保留举报入口。
DNS 变更管理：SPF/DKIM/DMARC 记录纳入变更审批，避免多条 SPF 记录并存（多条会直接导致 SPF 失效），TTL 设置合理，变更后立即用外部 DNS 验证。
持续监控：定期解析 DMARC 聚合报告，发现新的失败来源先判断是合法新系统还是仿冒；对外包/新采购的邮件服务，把“提供 SPF include 与 DKIM 公钥”写进上线清单。

根因分析

直接根因是 公司域名没有配置 SPF、DKIM、DMARC，收件方无法验证发件人是否经过授权，仿冒邮件因此可以伪装成公司地址直接投递。

更深一层，是把邮件安全理解成了“邮件网关的事”。网关能拦垃圾邮件、能查附件，但发件人认证是域名所有者的责任：SPF 告诉世界“哪些 IP 有权代表我发信”，DKIM 给邮件加签名，DMARC 告诉收件方“没通过认证时怎么办”。这三样不在网关上，而在 DNS 里；不配，就等于把 domain 的解释权交给了任何人。

还有一层是“我们不发垃圾邮件，所以不需要 DMARC”的误解。DMARC 防的不是自己发垃圾邮件，而是别人冒用你的域名发邮件；它保护的是品牌和客户信任，不是自家收件箱。等客户已经收到仿冒邮件再补，损失的是解释成本和信任。

预防措施

建立发信源清单：每新增一个 SaaS、中继或营销平台，上线前必须补齐 SPF include 与 DKIM，变更走 DNS 审批。
DMARC 上线后持续看聚合报告，按来源 IP/域名归因；出现新的失败来源，先确认是否合法系统，再决定放行或封禁。
定期做外部仿冒测试：从第三方 VPS 尝试伪造本域发信，验证 DMARC 策略确实生效。
对客户和员工公布举报渠道，收到可疑邮件时能快速转交安全团队分析。
把域名邮件认证纳入品牌保护范围，和官网、商标、证书一起管理，而不是留给某个人的“顺手配置”。

总结

邮件头的 From 只是一个声明，SPF、DKIM、DMARC 才是让这个声明可信的签名和规则。没有它们，任何人都可以在自己的服务器上写一句 From: service@example.com，而收件方没有任何依据拒绝。补这三条 DNS 记录不需要买新设备，也不需要改业务流程，但它决定了客户收到的那封信到底是不是你发的。域名是品牌资产，发件人认证就是它的防伪标识。

邮件仿冒 on Zero Day Notes