DMARC 策略告诉接收服务器，如何处理使用你的 From 域名却未通过 DMARC 的邮件。最终决定由接收方按自身规则作出。过早启用严格策略可能影响账单、客服回复和转发邮件；仔细配置则有助于限制直接域名伪造。整体邮件设置可先参考企业邮箱指南。
问题往往不是协议太复杂，而是没有核查实际发送源。有些团队长期保留 p=none 却不分析结果，另一些则在合法发送源尚未成功认证并对齐时，直接启用 p=reject，可能导致正常邮件被拒收。
实用的做法是先用 p=none 了解真实发送源，确认认证成功且对齐后再考虑 p=quarantine，分析剩余失败后才考虑 p=reject。并非所有失败都是伪造，升级时机应取决于实际业务。
什么是 DMARC 策略？
DMARC 策略对使用你的 From 域名、未通过 DMARC 的邮件提出处理建议。选项包括 none、quarantine 和 reject。关键是每个合法发送源是否有成功且域名对齐的 SPF 或 DKIM。
接收方验证 SPF、DKIM，并检查它们与可见 From 域名的对齐。至少一种机制需要同时满足验证成功和域名对齐。
SPF 验证成功且域名对齐，DMARC 就通过。
DKIM 验证成功且域名对齐，DMARC 就通过。
没有成功且对齐的路径时，接收方会考虑 DMARC 策略。
| 策略 | 记录 | 请求接收方采取的行动 | 适用场景 |
|---|---|---|---|
| None | p=none | 不因 DMARC 执行限制，并请求报告 | 发现发送源与监测 |
| Quarantine | p=quarantine | 视为可疑邮件，例如放入垃圾邮件 | 逐步执行限制 |
| Reject | p=reject | 请求拒收，通常在 SMTP 阶段 | 更严格的限制 |
最初应该选择哪种 DMARC 策略？
除非已确认所有发送源都有成功且对齐的认证，否则可从 p=none 开始。先观察真实流量，再请求更严格的处理。
可用的初始记录示例：
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com这个模式本身不要求阻止伪造，而是让你从提供报告的接收方获得信息。一个域名实际使用的发送系统，往往比管理者以为的更多。
容易遗漏的来源包括：
- 发送账单的会计软件。
- 发送录用通知的人事或招聘工具。
- 发送营销活动的 CRM 和营销平台。
- 以主域名回复的客服系统。
- 可能影响下一跳 SPF 的用户转发规则。
跳过监测可能让策略影响真实业务邮件。需要核查实际发送路径，而不只是 DNS 语法。
对于批量发件人，DMARC 记录已属于重要的发送要求。Google 的指南涉及域名认证和对齐。这里介绍的协议见 RFC 7489。
DMARC 应在 none 模式停留多久？
用 none 观察两到四周可以作为起点，但不能保证涵盖所有发送周期。月度或不常发生的流程可能需要更长观察时间或专门测试。
三天通常不够，可能错过月度账单、季度通知，以及只偶尔发送密码重置邮件的旧应用。
观察时应覆盖：
- 日常业务邮件。
- 营销发送。
- 账单周期。
- 客服升级处理。
- 转发邮件。
- 第三方自动化。
查看可用的汇总报告，区分已知合法系统、可疑来源和尚未解释的失败。并非所有接收方都会发送报告，也不是每次失败都代表伪造。
例如，通讯邮件平台使用自己的域名签名，SPF 也只为未对齐的平台域名通过。没有成功且对齐的认证路径，DMARC 就失败。下一步应修复对齐，而不是启用 reject。
TrekMail 的 DNS 流程显示所需记录并帮助验证，但不能代替完整的发送源清单。可查看添加域名和必需 DNS 记录。
为什么转发可能影响 DMARC？
转发会改变发送服务器，原始 SPF 可能失败，因此成功且对齐的 DKIM 通常格外重要。策略本身并不改变验证规则；没有成功且对齐的路径时，DMARC 可能失败。
即使有经验的管理员，也需要区分这些概念。
邮件有多种发送身份。用户看到的是 From，信封发件人则用于退信。SPF 检查对应域名和发送 IP，DMARC 另外检查这个已认证域名与可见 From 的对齐。
转发后，原始 SPF 授权往往不适用于新的 IP。只要已签名数据在规范化规则下保持不变，DKIM 就可能保留。
因此，以下两点可以同时成立：
- 转发后 SPF 失败。
- DKIM 成功且对齐，因此 DMARC 仍通过。
转发对业务重要时，应在执行限制前测试真实路径和合法发送源的成功对齐 DKIM。发往 Gmail 可参考把域名邮件转发到 Gmail；其他故障可查看邮件转发配置。
ARC 可以跨中间系统和邮件列表传递认证上下文，但不能代替自身对齐。是否采信这些信息由接收方决定。协议见 RFC 8617。
什么时候改用 quarantine？
当报告和专门测试确认合法发送源有成功且对齐的 SPF 或 DKIM 后，可考虑 quarantine。它请求把失败邮件视为可疑，但不保证进入垃圾邮件，也不保证能够找回。
记录示例：
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com遗漏的发送源可能因此显现，例如邮件落入垃圾邮件。但接收方可能作出其他本地决定，因此仍需主动检查和收集反馈。
可采用以下处理流程：
- 用户报告邮件缺失。
- 检查发送源、认证与对齐。
- 修复 SPF、DKIM 或两者。
- 重新测试后再考虑 reject。
部分团队通过 pct=25 或 pct=50 分阶段执行。不同接收方的支持和行为不同，不能保证精确遵守比例。直接升级到 100% 也必须有充分的验证依据。
正确配置的 TrekMail 托管 SMTP 可以为你的域名签名，应通过真实邮件头与对齐检查确认。转发后 SPF 失败、DKIM 成功的常见情况见邮件进入垃圾邮件。
什么时候改用 reject？
确认合法来源并调查剩余失败后，才考虑 reject。它请求拒收未通过 DMARC 的邮件，但不保证所有接收方执行相同操作。
记录示例：
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com经过准备后，这可以成为许多域名的合理目标。
可能的益处包括：
- 限制受保护域名的直接伪造。
- 增加部分钓鱼和发件人域名滥用的难度。
- 明确表达认证失败后的处理意愿。
- 成为更全面品牌保护措施的一部分。
Google 的发送者 FAQ 介绍拒收和限流，包括 DMARC 相关错误 4.7.31 和对齐问题 4.7.32。退信也可能包含 5.7.26 和域名策略说明。应结合完整错误信息查看Google 电子邮件发件人指南常见问题。
需要注意：旧财务 SaaS 没有成功且对齐的认证路径时，账单可能被拒收。应预先验证这些邮件并规划故障处理。
应该在 DNS 发布什么 DMARC 策略记录？
把策略作为 TXT 发布到 _dmarc.yourdomain.com。该名称下只应有一条 DMARC 策略记录，冲突的多条记录可能阻碍解析。
下面是互为替代的示例，不能同时发布：
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"TrekMail 域名配置通常一起处理 MX、SPF、DKIM 和 DMARC。下例仅展示结构，不是直接执行限制的建议；quarantine 并非通用初始策略，SPF 和 DKIM 也须匹配实际外发服务。
@ MX 10 mail.trekmail.net.
@ TXT "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey TXT "<unique value from dashboard>"
_dmarc TXT "v=DMARC1; p=quarantine;"不要发布重复 SPF，也不要猜测 DKIM 值。核查旧 MX 是否仍有用途。自备发送服务时，应按其要求配置 SPF、DKIM，并另行验证对齐。参阅自备 SMTP（BYO）。
常见的 DMARC 策略错误
常见问题包括长期不分析 p=none、过早执行限制、只依赖 SPF，以及忽略子域名。实际影响取决于业务配置。
注意以下情况：
none没有分析和后续计划。报告本身不执行 DMARC 限制。- SPF 状态正常，却没有 DKIM 对齐；转发可能暴露这种依赖。
- 忽略子域名继承。可用
sp=设置不同的子域名策略。 - 忽略 SPF 限制：超过 10 个被求值、会触发 DNS 的项可能产生
PermError，不是简单统计全部 DNS 查询次数。 - 服务以你的域名发送，却没有检查实际签名方式。
不同子域名处理的示例：
v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com主域名请求 reject，继承策略的子域名使用 none。这不只适用于某个选定的测试子域名；子域名自己的具体 DMARC 记录可以覆盖继承策略。
TrekMail 如何支持 DMARC 配置
TrekMail 在多域名面板中结合域名管理、DNS 检查、发送配置和共享存储。这可能减少分散管理，但不能代替外部发送源核查和充分的 DMARC 观察。
价格参考为 Starter 每月 $3.50 起并提供托管 SMTP，Nano 则作为自备 SMTP 的免费方案提供。IMAP 邮箱、自有域名、Catch-all、转发、迁移和 API 的可用性取决于当前套餐及前提条件。选择前请核实价格和功能。
对 DMARC 来说，最重要的是了解所有以你的域名发送的系统。发布 TXT 本身不能完成这项工作。
根据套餐和设置，可以：
- 在一处管理多个域名。
- 上线前检查必需 DNS 记录。
- 在适用付费套餐使用托管 SMTP，或在 Nano 自备 SES/SendGrid。
- 把邮箱托管与外发服务选择分开。
- 在源服务允许访问时，通过内置 IMAP 迁移导入旧邮件。
完整域名设置见在我的域名设置邮箱。多个品牌或客户域名的管理可参考多域名邮件托管。
结论：逐步执行 DMARC 策略
合理的路径从 none 开始，修复认证与对齐，经验证后再到 quarantine，必要时到 reject。每一步都需要实际业务流量的依据。
简要步骤：
- 用
p=none观察，例如 2 到 4 周，并额外覆盖不常发生的发送周期。 - 确保每个合法发送源有成功且对齐的 SPF，或优先配置 DKIM。
- 核查后再改为
p=quarantine。 - 调查剩余失败并确认合法来源后，才启用
p=reject。
这样可以降低正常邮件受影响的风险，并请求更严格地处理域名伪造，但不构成投递或安全保证。如需统一管理邮箱、转发和迁移，可阅读 TrekMail 文档，或在 https://trekmail.net/pricing 比较套餐。
