| name | performing-dmarc-policy-enforcement-rollout |
| description | 执行从 p=none 监控到 p=quarantine 再到 p=reject 执行的分阶段 DMARC 推进,确保所有合法邮件来源在封锁未授权发件人之前完成认证。 |
| domain | cybersecurity |
| subdomain | phishing-defense |
| tags | ["dmarc","spf","dkim","email-authentication","anti-spoofing","phishing","dns","email-security"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
执行 DMARC 策略执行推进
概述
基于域名的消息认证、报告和一致性(DMARC)是邮件防欺骗保护的基石。DMARC 推进经历三个阶段:监控(p=none)、隔离(p=quarantine)和完全执行(p=reject)。配置为 p=reject 时,同时未通过 SPF 和 DKIM 检查的任何邮件都将被直接拒绝。Google 和 Yahoo 现在要求批量发件人(5000 封以上邮件)使用 DMARC,推动未认证消息减少了 65%。安全部署通常需要 3-6 个月。
前置条件
- 对域名 DNS 管理的管理员访问权限
- 了解 SPF、DKIM 和 DMARC 协议(RFC 7208、6376、7489)
- 完整的所有合法邮件发件来源清单
- DMARC 报告分析工具(EasyDMARC、DMARCLY、Valimail 或 dmarcian)
- 具备 DMARC 执行能力的邮件网关
核心概念
DMARC 策略级别
| 策略 | 行为 | 使用场景 |
|---|
| p=none | 仅监控,对失败不采取操作 | 发现阶段 |
| p=quarantine | 将失败邮件发送到垃圾邮件/垃圾箱 | 过渡阶段 |
| p=reject | 完全封锁失败邮件 | 完全执行 |
DMARC 记录结构
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@company.com; ruf=mailto:dmarc-forensic@company.com; adkim=r; aspf=r; fo=1
- p:组织域名的策略
- sp:子域名的策略
- pct:受策略约束的消息百分比(用于逐步推进)
- rua:聚合报告目标(每日 XML 报告)
- ruf:取证报告目标(每次失败的报告)
- adkim:DKIM 对齐模式(r=宽松,s=严格)
- aspf:SPF 对齐模式(r=宽松,s=严格)
- fo:失败报告选项(0=两者都失败,1=任一失败)
SPF 和 DKIM 对齐
- SPF 对齐:Return-Path(信封发件人)中的域名必须与 From 头部域名匹配
- DKIM 对齐:DKIM 签名中的 d= 域名必须与 From 头部域名匹配
- 宽松:组织域名匹配(sub.example.com 匹配 example.com)
- 严格:需要精确域名匹配
实施步骤
步骤一:清点所有发件来源(第 1-2 周)
- 审计所有以您的域名发送邮件的系统(营销、CRM、工单、交易邮件)
- 记录第三方服务:Salesforce、Mailchimp、SendGrid、Zendesk 等
- 识别内部邮件服务器、应用程序和中继主机
- 检查影子 IT 邮件发送(部门使用未授权服务)
步骤二:配置 SPF 和 DKIM(第 2-4 周)
- 整合 SPF 记录,包含所有合法发件 IP 和 include 机制
- 确保 SPF 记录保持在 10 次 DNS 查询限制以内
- 为每个发件来源生成并发布 DKIM 密钥
- 验证 DKIM 签名对所有出站邮件路径有效
- 使用 MX Toolbox 或 dmarcian SPF/DKIM 验证器进行测试
步骤三:以监控模式部署 DMARC(第 4-6 周)
- 发布初始 DMARC 记录:
v=DMARC1; p=none; rua=mailto:dmarc@company.com; fo=1
- 等待 1-2 周收集有代表性的聚合报告
- 分析报告以识别未授权发件人和对齐失败
- 修复所有显示失败的合法来源的 SPF/DKIM
- 持续迭代直至所有合法邮件通过 DMARC
步骤四:使用 pct 标签切换到隔离模式(第 6-12 周)
- 更新为 10% 隔离:
v=DMARC1; p=quarantine; pct=10; rua=...
- 监控误报(合法邮件被隔离)
- 逐步提高 pct:10% -> 25% -> 50% -> 75% -> 100%
- 每次提高:等待 1-2 周并在推进前审查报告
- 修复每个阶段发现的剩余对齐问题
步骤五:推进至拒绝策略(第 12-20 周)
- 在 100% 稳定隔离后,切换至 10% 拒绝:
v=DMARC1; p=reject; pct=10; rua=...
- 逐步提高 pct:10% -> 25% -> 50% -> 100%
- 密切监控合法邮件是否被拒绝
- 建立紧急回滚流程(恢复至隔离模式)
- 应用子域名策略:
sp=reject
步骤六:持续监控和维护
- 持续监控 DMARC 聚合报告
- 在新发件来源开始发送前将其添加进来
- 审查取证报告中的欺骗尝试
- 随发件基础设施变化维护 SPF 记录
- 每年轮换 DKIM 密钥
工具与资源
- EasyDMARC:带有聚合/取证报告分析的 DMARC 监控仪表板
- DMARCLY:具备自动 DNS 更新的 SPF、DKIM、DMARC 监控
- dmarcian:DMARC 部署和管理平台
- Valimail:带托管认证的自动化 DMARC 执行
- MX Toolbox:DNS 记录查询和 DMARC 验证器
- Google 管理工具箱:DMARC 检查和诊断工具
验证
- DMARC 记录已发布并在 _dmarc.domain.com 正确解析
- 所有合法发件来源通过 SPF 和/或 DKIM 对齐
- 聚合报告显示超过 99% 的合法邮件通过 DMARC
- 来自未授权发件人的伪造邮件被拒绝
- 完全 p=reject 执行后无合法邮件被封锁
- 子域名策略(sp=)也设置为 reject