| 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
