DMARC：如何保护您的电子邮件声誉
鸟
2016年4月13日
电子邮件
1 min read
关键要点
DMARC 通过发布您的身份验证实践并请求处理失败的消息来保护您的域名免受钓鱼、欺骗和未经授权的电子邮件使用。
它与 SPF 和 DKIM 配合使用，以确保域名一致性并防止欺诈邮件损害您的发件人声誉。
强大的 DMARC 策略支持更高的信任、更高的互动，并为您的域名在生态系统转向基于域名的信誉模型时做好未来的准备。
DMARC 验证检查依赖于发件人域名、退回路径域名 (SPF) 和 DKIM 签名域名之间的一致性。
设置 DMARC 需要接收报告、理解汇总与取证数据的差异，以及配置工具来解析这些数据。
您以安全的 p=none 策略开始监控流量，然后再移至 隔离 或 拒绝。
发布 DMARC 记录涉及在 _dmarc.yourdomain.com 创建 DNS TXT 条目，包含策略、报告地址和诸如百分比发布之类的可选参数。
适当的报告邮箱（汇总 + 取证）和解析工具对于监控合规性、检测欺骗行为并确保一致性是正确的至关重要。
DMARC 只需要以下之一通过：对齐的 SPF 或对齐的 DKIM。
实施 DMARC 加强电子邮件安全，并在品牌完整性、信任和长期可送达性方面发挥重要作用。
Q&A 精华
什么是DMARC，它为何重要？
DMARC（基于域的消息验证、报告和一致性）是一种通过DNS发布的策略，通过执行域一致性并通过报告启用可见性来保护您的域免受欺骗和网络钓鱼攻击。
DMARC 是一种身份验证协议吗？
不，DMARC本身不是认证——它依赖SPF和DKIM进行邮件认证，并使用策略和报告来控制接收服务器如何处理失败。
DMARC检查什么？
它验证：
SPF 验证 + 对齐
DKIM 验证 + 对齐
发件人只需要其中之一就可以通过 DMARC 验证。
什么是“domain alignment”?
要求是可见的发件人域必须与SPF Return-Path域或DKIM签名域严格匹配或共享相同的组织域（宽松）。
为什么 DMARC 会提高送达率？
因为邮箱服务商更信任通过认证的、对齐的域名。DMARC 防止虚假邮件侵蚀您的声誉，并改善合法邮件的收件箱投递。
aggregate 和 forensic DMARC 报告之间有什么区别？
Aggregate reports (RUA): 所有流量的认证结果的 XML 汇总。
Forensic reports (RUF): 失败消息的个别样本以便进行深入分析。
我在发布 DMARC 之前需要哪些 mailboxes？
您应该创建两个地址，例如：
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
这样可以使报告流保持分离，便于解析。
我应该从什么DMARC策略开始？
始终以p=none开始。它监控身份验证活动而不影响交付，使您能够安全地识别对齐问题和欺骗尝试。
可用的 DMARC policies 是什么？
无: 仅监控
隔离: 将失败的消息发送到垃圾邮件
拒绝: 完全阻止失败的消息
在哪里发布 DMARC 记录？
在您的DNS中：
_dmarc.yourdomain.com
它必须是一个TXT记录，指定您的策略、版本和报告端点。
基本的 DMARC 记录是什么样的？
示例:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
DMARC失败会发生什么？
接收服务器会应用您请求的策略（无、隔离、拒绝），但最终处理决定取决于供应商。严格的策略可以显著减少使用您的域名进行钓鱼攻击的尝试。
在这篇文章中，我们将告诉你有关利用DMARC保护你的电子邮件声誉的所有信息，并为你提供有关如何为你的域名设置它的指引。
在这篇文章中，我们将告诉你有关利用DMARC保护你的电子邮件声誉的所有信息，并为你提供有关如何为你的域名设置它的指引。
在这篇文章中，我们将告诉你有关利用DMARC保护你的电子邮件声誉的所有信息，并为你提供有关如何为你的域名设置它的指引。
An Effective Tool to Fight Fraudulent Mail
经常与邮件认证协议SPF和DKIM一起提及的DMARC，或称基于域的消息认证、报告和一致性，本身不是一种认证协议。相反，DMARC的目的是让我们，作为域名所有者，通过以下方式保护我们的邮件声誉：
公布邮件认证实践，
请求处理未通过认证检查的邮件，
请求有关声称来自其域的邮件的报告。
DMARC可以成为我们打击针对我们域名（如网络钓鱼和欺骗）的欺诈邮件的有效工具，并能在我们的邮件收件人中提升信任度。对于需要超出认证的端到端加密的组织，实施S/MIME并采用高效的收件人公钥收集方法，将提供额外的安全层。这种更高的信任度应当转而导致对我们邮件的更高参与度，邮件被打开并产生点击率从而推动销售，并为我们的电子邮件活动带来更高的投资回报率。
为了保护我们的域名，我们预测现在实施DMARC将是“面向未来”保护我们的域名的一个绝佳途径。在Bird，我们相信随着行业向IPv6的迁移，几乎可以肯定会从基于IP的声誉模型转向基于域的声誉模型。基于域的声誉将需要基于域的认证，而DMARC与DKIM和SPF结合使用，将有助于域在必要之前很久就建立起基于域的声誉。
在这篇文章中，我们将告诉您关于利用DMARC保护您的邮件声誉所需了解的一切，并给您关于如何为您的域设置它的提示。
经常与邮件认证协议SPF和DKIM一起提及的DMARC，或称基于域的消息认证、报告和一致性，本身不是一种认证协议。相反，DMARC的目的是让我们，作为域名所有者，通过以下方式保护我们的邮件声誉：
公布邮件认证实践，
请求处理未通过认证检查的邮件，
请求有关声称来自其域的邮件的报告。
DMARC可以成为我们打击针对我们域名（如网络钓鱼和欺骗）的欺诈邮件的有效工具，并能在我们的邮件收件人中提升信任度。对于需要超出认证的端到端加密的组织，实施S/MIME并采用高效的收件人公钥收集方法，将提供额外的安全层。这种更高的信任度应当转而导致对我们邮件的更高参与度，邮件被打开并产生点击率从而推动销售，并为我们的电子邮件活动带来更高的投资回报率。
为了保护我们的域名，我们预测现在实施DMARC将是“面向未来”保护我们的域名的一个绝佳途径。在Bird，我们相信随着行业向IPv6的迁移，几乎可以肯定会从基于IP的声誉模型转向基于域的声誉模型。基于域的声誉将需要基于域的认证，而DMARC与DKIM和SPF结合使用，将有助于域在必要之前很久就建立起基于域的声誉。
在这篇文章中，我们将告诉您关于利用DMARC保护您的邮件声誉所需了解的一切，并给您关于如何为您的域设置它的提示。
经常与邮件认证协议SPF和DKIM一起提及的DMARC，或称基于域的消息认证、报告和一致性，本身不是一种认证协议。相反，DMARC的目的是让我们，作为域名所有者，通过以下方式保护我们的邮件声誉：
公布邮件认证实践，
请求处理未通过认证检查的邮件，
请求有关声称来自其域的邮件的报告。
DMARC可以成为我们打击针对我们域名（如网络钓鱼和欺骗）的欺诈邮件的有效工具，并能在我们的邮件收件人中提升信任度。对于需要超出认证的端到端加密的组织，实施S/MIME并采用高效的收件人公钥收集方法，将提供额外的安全层。这种更高的信任度应当转而导致对我们邮件的更高参与度，邮件被打开并产生点击率从而推动销售，并为我们的电子邮件活动带来更高的投资回报率。
为了保护我们的域名，我们预测现在实施DMARC将是“面向未来”保护我们的域名的一个绝佳途径。在Bird，我们相信随着行业向IPv6的迁移，几乎可以肯定会从基于IP的声誉模型转向基于域的声誉模型。基于域的声誉将需要基于域的认证，而DMARC与DKIM和SPF结合使用，将有助于域在必要之前很久就建立起基于域的声誉。
在这篇文章中，我们将告诉您关于利用DMARC保护您的邮件声誉所需了解的一切，并给您关于如何为您的域设置它的提示。
Terms to Know
在我们为您的域设置DMARC之前，我们希望确保我们在使用相同的语言。让我们从定义一些将在本文档中使用的术语开始。
RFC5322.From Domain
RFC5322.From Domain是电子邮件地址的域部分，通常是电子邮件被读取时收件人能看到的部分。在以下示例中，RFC5322.From域是“joesbaitshop.com”。
发件人：Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= 域
DKIM是一种身份验证协议，它允许一个域以可以被消息接收者验证的方式对信息负责；这是通过在消息离开其起始点时，插入到消息头中的加密签名来完成的。这些签名有效地捕捉了当时信息的外观，接收者可以使用这些签名来查看信息是否保持不变地到达了目的地。产生和插入这些签名的过程称为DKIM签名，负责通过签名对消息负责的域在头中以“d=signingDomain”作为键值标签插入其名称，因此被称为DKIM d= 域。
Return-Path 域
Return-Path域，有时被称为RFC5321. From域或Mail From域，是用于路由退信的域；也是在电子邮件交易过程中进行SPF检查的域。除非收件人足够精明去查看给定消息中的所有头，否则通常不被收件人看到。
默认情况下，通过bird.com发送的所有邮件将使用birdmail.com作为其Return-Path域，如以下示例中所示：
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
但是，为了使DMARC在您的域中有效，您将需要利用自定义退信域，其末尾将与您的发信域相同，例如，使用yourdomain.com作为您的发信域时，bounces.yourdomain.com。
Organizational Domain
“Organizational Domain”一词指提交给注册商以在互联网上创建域存在的域。对于Bird，我们的组织域是bird.com和birdmail.com。
Domain Alignment
关于DMARC需要理解的最后一个术语是“Domain Alignment”，它有两种变体：“relaxed”和“strict”。
Relaxed Domain Alignment
当两个域的组织域相同时，可以说它们具有relaxed domain alignment。例如，a.mail.bird.com和b.foo.bird.com具有relaxed domain alignment，因为它们的共同组织域是bird.com。
Strict Domain Alignment
只有当两个域是相同的时，才能说它们具有strict domain alignment。因此，foo.bird.com和foo.bird.com是严格对齐的，因为这两个域是相同的。另一方面，foo.bird.com和bar.foo.bird.com仅为relaxed alignment。
DMARC Domain Alignment Requirements
为了使DMARC验证检查通过，DMARC要求域对齐如下：
对于SPF，RFC5322.From域和Return-Path域必须对齐
对于DKIM，RFC5322.From域和DKIM d=域必须对齐
对齐可以是relaxed或strict，基于发送域的已发布策略。
在我们为您的域设置DMARC之前，我们希望确保我们在使用相同的语言。让我们从定义一些将在本文档中使用的术语开始。
RFC5322.From Domain
RFC5322.From Domain是电子邮件地址的域部分，通常是电子邮件被读取时收件人能看到的部分。在以下示例中，RFC5322.From域是“joesbaitshop.com”。
发件人：Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= 域
DKIM是一种身份验证协议，它允许一个域以可以被消息接收者验证的方式对信息负责；这是通过在消息离开其起始点时，插入到消息头中的加密签名来完成的。这些签名有效地捕捉了当时信息的外观，接收者可以使用这些签名来查看信息是否保持不变地到达了目的地。产生和插入这些签名的过程称为DKIM签名，负责通过签名对消息负责的域在头中以“d=signingDomain”作为键值标签插入其名称，因此被称为DKIM d= 域。
Return-Path 域
Return-Path域，有时被称为RFC5321. From域或Mail From域，是用于路由退信的域；也是在电子邮件交易过程中进行SPF检查的域。除非收件人足够精明去查看给定消息中的所有头，否则通常不被收件人看到。
默认情况下，通过bird.com发送的所有邮件将使用birdmail.com作为其Return-Path域，如以下示例中所示：
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
但是，为了使DMARC在您的域中有效，您将需要利用自定义退信域，其末尾将与您的发信域相同，例如，使用yourdomain.com作为您的发信域时，bounces.yourdomain.com。
Organizational Domain
“Organizational Domain”一词指提交给注册商以在互联网上创建域存在的域。对于Bird，我们的组织域是bird.com和birdmail.com。
Domain Alignment
关于DMARC需要理解的最后一个术语是“Domain Alignment”，它有两种变体：“relaxed”和“strict”。
Relaxed Domain Alignment
当两个域的组织域相同时，可以说它们具有relaxed domain alignment。例如，a.mail.bird.com和b.foo.bird.com具有relaxed domain alignment，因为它们的共同组织域是bird.com。
Strict Domain Alignment
只有当两个域是相同的时，才能说它们具有strict domain alignment。因此，foo.bird.com和foo.bird.com是严格对齐的，因为这两个域是相同的。另一方面，foo.bird.com和bar.foo.bird.com仅为relaxed alignment。
DMARC Domain Alignment Requirements
为了使DMARC验证检查通过，DMARC要求域对齐如下：
对于SPF，RFC5322.From域和Return-Path域必须对齐
对于DKIM，RFC5322.From域和DKIM d=域必须对齐
对齐可以是relaxed或strict，基于发送域的已发布策略。
在我们为您的域设置DMARC之前，我们希望确保我们在使用相同的语言。让我们从定义一些将在本文档中使用的术语开始。
RFC5322.From Domain
RFC5322.From Domain是电子邮件地址的域部分，通常是电子邮件被读取时收件人能看到的部分。在以下示例中，RFC5322.From域是“joesbaitshop.com”。
发件人：Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= 域
DKIM是一种身份验证协议，它允许一个域以可以被消息接收者验证的方式对信息负责；这是通过在消息离开其起始点时，插入到消息头中的加密签名来完成的。这些签名有效地捕捉了当时信息的外观，接收者可以使用这些签名来查看信息是否保持不变地到达了目的地。产生和插入这些签名的过程称为DKIM签名，负责通过签名对消息负责的域在头中以“d=signingDomain”作为键值标签插入其名称，因此被称为DKIM d= 域。
Return-Path 域
Return-Path域，有时被称为RFC5321. From域或Mail From域，是用于路由退信的域；也是在电子邮件交易过程中进行SPF检查的域。除非收件人足够精明去查看给定消息中的所有头，否则通常不被收件人看到。
默认情况下，通过bird.com发送的所有邮件将使用birdmail.com作为其Return-Path域，如以下示例中所示：
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
但是，为了使DMARC在您的域中有效，您将需要利用自定义退信域，其末尾将与您的发信域相同，例如，使用yourdomain.com作为您的发信域时，bounces.yourdomain.com。
Organizational Domain
“Organizational Domain”一词指提交给注册商以在互联网上创建域存在的域。对于Bird，我们的组织域是bird.com和birdmail.com。
Domain Alignment
关于DMARC需要理解的最后一个术语是“Domain Alignment”，它有两种变体：“relaxed”和“strict”。
Relaxed Domain Alignment
当两个域的组织域相同时，可以说它们具有relaxed domain alignment。例如，a.mail.bird.com和b.foo.bird.com具有relaxed domain alignment，因为它们的共同组织域是bird.com。
Strict Domain Alignment
只有当两个域是相同的时，才能说它们具有strict domain alignment。因此，foo.bird.com和foo.bird.com是严格对齐的，因为这两个域是相同的。另一方面，foo.bird.com和bar.foo.bird.com仅为relaxed alignment。
DMARC Domain Alignment Requirements
为了使DMARC验证检查通过，DMARC要求域对齐如下：
对于SPF，RFC5322.From域和Return-Path域必须对齐
对于DKIM，RFC5322.From域和DKIM d=域必须对齐
对齐可以是relaxed或strict，基于发送域的已发布策略。
DMARC 如何发挥作用以保护您的电子邮件声誉
当我们谈到邮箱提供商或其他域“检查DMARC”、“验证DMARC”或“应用DMARC策略”时，我们的意思是接收消息的域正在执行以下步骤：
找出消息的RFC5322.From域
在DNS中查找该域的DMARC策略
执行DKIM签名验证
执行SPF验证
检查域对齐
应用DMARC策略
为了使消息通过DMARC验证，消息必须仅通过两项身份验证和对齐检查之一。因此，如果以下任一条件为真，消息将通过DMARC验证：
消息通过SPF检查，RFC5322.From域和Return-Path域对齐，或
消息通过DKIM验证，RFC5322.From域和DKIM d=域对齐，或
上述两者均为真
DMARC验证路径概览
身份验证路径 | 比较的域 | 所需对齐 | DMARC通过条件 |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | 放宽或严格 | SPF通过且域对齐 |
DKIM | RFC5322.From ↔ DKIM d= | 放宽或严格 | DKIM通过且域对齐 |
SPF + DKIM | 上述两者 | 任一对齐 | 一个或两个对齐检查通过 |
当我们谈到邮箱提供商或其他域“检查DMARC”、“验证DMARC”或“应用DMARC策略”时，我们的意思是接收消息的域正在执行以下步骤：
找出消息的RFC5322.From域
在DNS中查找该域的DMARC策略
执行DKIM签名验证
执行SPF验证
检查域对齐
应用DMARC策略
为了使消息通过DMARC验证，消息必须仅通过两项身份验证和对齐检查之一。因此，如果以下任一条件为真，消息将通过DMARC验证：
消息通过SPF检查，RFC5322.From域和Return-Path域对齐，或
消息通过DKIM验证，RFC5322.From域和DKIM d=域对齐，或
上述两者均为真
DMARC验证路径概览
身份验证路径 | 比较的域 | 所需对齐 | DMARC通过条件 |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | 放宽或严格 | SPF通过且域对齐 |
DKIM | RFC5322.From ↔ DKIM d= | 放宽或严格 | DKIM通过且域对齐 |
SPF + DKIM | 上述两者 | 任一对齐 | 一个或两个对齐检查通过 |
当我们谈到邮箱提供商或其他域“检查DMARC”、“验证DMARC”或“应用DMARC策略”时，我们的意思是接收消息的域正在执行以下步骤：
找出消息的RFC5322.From域
在DNS中查找该域的DMARC策略
执行DKIM签名验证
执行SPF验证
检查域对齐
应用DMARC策略
为了使消息通过DMARC验证，消息必须仅通过两项身份验证和对齐检查之一。因此，如果以下任一条件为真，消息将通过DMARC验证：
消息通过SPF检查，RFC5322.From域和Return-Path域对齐，或
消息通过DKIM验证，RFC5322.From域和DKIM d=域对齐，或
上述两者均为真
DMARC验证路径概览
身份验证路径 | 比较的域 | 所需对齐 | DMARC通过条件 |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | 放宽或严格 | SPF通过且域对齐 |
DKIM | RFC5322.From ↔ DKIM d= | 放宽或严格 | DKIM通过且域对齐 |
SPF + DKIM | 上述两者 | 任一对齐 | 一个或两个对齐检查通过 |
为您的域名启用DMARC
既然我们已经解释了DMARC的机制，让我们谈谈如何让DMARC为我们工作，涉及以下三个步骤：
做好接收DMARC报告的准备
决定使用何种DMARC策略用于您的域
发布您的DMARC记录
我们将在下面详细介绍这些步骤，但我们直接告诉您，上述步骤1将消耗大约95%的准备时间。
既然我们已经解释了DMARC的机制，让我们谈谈如何让DMARC为我们工作，涉及以下三个步骤：
做好接收DMARC报告的准备
决定使用何种DMARC策略用于您的域
发布您的DMARC记录
我们将在下面详细介绍这些步骤，但我们直接告诉您，上述步骤1将消耗大约95%的准备时间。
既然我们已经解释了DMARC的机制，让我们谈谈如何让DMARC为我们工作，涉及以下三个步骤：
做好接收DMARC报告的准备
决定使用何种DMARC策略用于您的域
发布您的DMARC记录
我们将在下面详细介绍这些步骤，但我们直接告诉您，上述步骤1将消耗大约95%的准备时间。
准备接收 DMARC 报告
任何发布DMARC政策的域应该首先准备接收关于其域的报告。这些报告将由执行DMARC验证的任何域生成，看到声称是从我们的域发出的邮件，并且至少每天发送一次。报告将有两种格式：
聚合报告，它是显示每个来源的邮件量、身份验证结果以及报告者如何处理邮件的统计数据的XML文档。聚合报告设计为机器解析，其数据存储在某处以便进行整体流量分析、审计我们域的邮件流，并可能识别未经身份验证的、潜在欺诈性邮件来源的趋势。
法证报告，即未通过身份验证的邮件的单独副本，每封邮件的完整格式为AFRF。法证报告应包含完整的邮件头和邮件正文，但由于隐私问题，许多报告者会删除或编辑部分信息。尽管如此，法证报告在排查我们域自身的身份验证问题以及通过消息正文中的URI识别用于欺诈我们域所有者客户的恶意域和网站时仍然有用。
接收这些报告的准备工作首先涉及在我们的域中创建两个邮箱来处理这些报告，例如agg_reports@ourdomain.com和afrf_reports@ourdomain.com。请注意，这些邮箱名称是完全任意的，对于邮箱本地部分的命名没有要求；我们可以自由选择任何我们想要的名称，但为了便于处理，保持这两个邮箱分开。
一旦邮箱名称在我们的域中被选择并创建，接下来的工作是安装工具来读取这些邮箱并利用数据，特别是聚合数据报告，因为这些报告再次设计为机器解析，而不是供人类阅读。另一方面，法证报告可能可以通过我们自己阅读来管理，但我们能否做到这一点将取决于我们的邮件客户端对如何显示AFRF格式消息的理解以及我们接收到的报告数量。
虽然我们可以自己编写工具来处理DMARC报告，但在Bird为bird.com客户提供此类服务之前（这是我们正在考虑的，但尚未承诺），我们建议使用已经可用的工具来完成任务。
任何发布DMARC政策的域应该首先准备接收关于其域的报告。这些报告将由执行DMARC验证的任何域生成，看到声称是从我们的域发出的邮件，并且至少每天发送一次。报告将有两种格式：
聚合报告，它是显示每个来源的邮件量、身份验证结果以及报告者如何处理邮件的统计数据的XML文档。聚合报告设计为机器解析，其数据存储在某处以便进行整体流量分析、审计我们域的邮件流，并可能识别未经身份验证的、潜在欺诈性邮件来源的趋势。
法证报告，即未通过身份验证的邮件的单独副本，每封邮件的完整格式为AFRF。法证报告应包含完整的邮件头和邮件正文，但由于隐私问题，许多报告者会删除或编辑部分信息。尽管如此，法证报告在排查我们域自身的身份验证问题以及通过消息正文中的URI识别用于欺诈我们域所有者客户的恶意域和网站时仍然有用。
接收这些报告的准备工作首先涉及在我们的域中创建两个邮箱来处理这些报告，例如agg_reports@ourdomain.com和afrf_reports@ourdomain.com。请注意，这些邮箱名称是完全任意的，对于邮箱本地部分的命名没有要求；我们可以自由选择任何我们想要的名称，但为了便于处理，保持这两个邮箱分开。
一旦邮箱名称在我们的域中被选择并创建，接下来的工作是安装工具来读取这些邮箱并利用数据，特别是聚合数据报告，因为这些报告再次设计为机器解析，而不是供人类阅读。另一方面，法证报告可能可以通过我们自己阅读来管理，但我们能否做到这一点将取决于我们的邮件客户端对如何显示AFRF格式消息的理解以及我们接收到的报告数量。
虽然我们可以自己编写工具来处理DMARC报告，但在Bird为bird.com客户提供此类服务之前（这是我们正在考虑的，但尚未承诺），我们建议使用已经可用的工具来完成任务。
任何发布DMARC政策的域应该首先准备接收关于其域的报告。这些报告将由执行DMARC验证的任何域生成，看到声称是从我们的域发出的邮件，并且至少每天发送一次。报告将有两种格式：
聚合报告，它是显示每个来源的邮件量、身份验证结果以及报告者如何处理邮件的统计数据的XML文档。聚合报告设计为机器解析，其数据存储在某处以便进行整体流量分析、审计我们域的邮件流，并可能识别未经身份验证的、潜在欺诈性邮件来源的趋势。
法证报告，即未通过身份验证的邮件的单独副本，每封邮件的完整格式为AFRF。法证报告应包含完整的邮件头和邮件正文，但由于隐私问题，许多报告者会删除或编辑部分信息。尽管如此，法证报告在排查我们域自身的身份验证问题以及通过消息正文中的URI识别用于欺诈我们域所有者客户的恶意域和网站时仍然有用。
接收这些报告的准备工作首先涉及在我们的域中创建两个邮箱来处理这些报告，例如agg_reports@ourdomain.com和afrf_reports@ourdomain.com。请注意，这些邮箱名称是完全任意的，对于邮箱本地部分的命名没有要求；我们可以自由选择任何我们想要的名称，但为了便于处理，保持这两个邮箱分开。
一旦邮箱名称在我们的域中被选择并创建，接下来的工作是安装工具来读取这些邮箱并利用数据，特别是聚合数据报告，因为这些报告再次设计为机器解析，而不是供人类阅读。另一方面，法证报告可能可以通过我们自己阅读来管理，但我们能否做到这一点将取决于我们的邮件客户端对如何显示AFRF格式消息的理解以及我们接收到的报告数量。
虽然我们可以自己编写工具来处理DMARC报告，但在Bird为bird.com客户提供此类服务之前（这是我们正在考虑的，但尚未承诺），我们建议使用已经可用的工具来完成任务。
使用哪个 DMARC Policy
DMARC规范为域名所有者提供了三种选择，以指定对未通过DMARC验证的邮件的首选处理方式。它们是:
none，意味着按照独立于DMARC验证检查的方式处理邮件
quarantine，意味着接受邮件但将其放置在收件人的Inbox以外的位置（通常是垃圾邮件文件夹）
reject，意味着直接拒绝邮件
重要的是要记住，域名所有者只能在其DMARC记录中请求这种处理；是否遵循请求的策略由邮件接收者决定。 有些会这样做，而其他可能在应用策略时更加宽松，例如只有在域策略为reject时才将邮件移至垃圾邮件文件夹。
我们建议所有客户使用none策略启动，以确保安全。虽然我们对通过DKIM签名正确认证您的邮件的能力有信心，但最好花些时间查看关于您域名的报告，然后再变得更激进地实施DMARC策略。
DMARC规范为域名所有者提供了三种选择，以指定对未通过DMARC验证的邮件的首选处理方式。它们是:
none，意味着按照独立于DMARC验证检查的方式处理邮件
quarantine，意味着接受邮件但将其放置在收件人的Inbox以外的位置（通常是垃圾邮件文件夹）
reject，意味着直接拒绝邮件
重要的是要记住，域名所有者只能在其DMARC记录中请求这种处理；是否遵循请求的策略由邮件接收者决定。 有些会这样做，而其他可能在应用策略时更加宽松，例如只有在域策略为reject时才将邮件移至垃圾邮件文件夹。
我们建议所有客户使用none策略启动，以确保安全。虽然我们对通过DKIM签名正确认证您的邮件的能力有信心，但最好花些时间查看关于您域名的报告，然后再变得更激进地实施DMARC策略。
DMARC规范为域名所有者提供了三种选择，以指定对未通过DMARC验证的邮件的首选处理方式。它们是:
none，意味着按照独立于DMARC验证检查的方式处理邮件
quarantine，意味着接受邮件但将其放置在收件人的Inbox以外的位置（通常是垃圾邮件文件夹）
reject，意味着直接拒绝邮件
重要的是要记住，域名所有者只能在其DMARC记录中请求这种处理；是否遵循请求的策略由邮件接收者决定。 有些会这样做，而其他可能在应用策略时更加宽松，例如只有在域策略为reject时才将邮件移至垃圾邮件文件夹。
我们建议所有客户使用none策略启动，以确保安全。虽然我们对通过DKIM签名正确认证您的邮件的能力有信心，但最好花些时间查看关于您域名的报告，然后再变得更激进地实施DMARC策略。
发布您的 DMARC Policy
一个域名的 DMARC 策略是通过在 DNS 命名空间的特定位置发布 DNS TXT 记录来宣布的，即 "_dmarc.domainname.tld"（注意前导下划线）。我们之前示例域的基本 DMARC 策略记录，joesbaitshop.com，可能如下所示：
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
分析此记录，我们有：
v=DMARC1 指定 DMARC 版本（目前只有 1 可用）
p=none 指定首选的处理方法，或 DMARC 策略
rua=mailto:agg_reports@joesbait.com 是用于接收汇总报告的邮箱
ruf=mailto:afrf_reports@joesbait.com 是用于接收取证报告的邮箱
pct=100 是域名所有者希望其策略应用的邮件百分比。刚开始使用 DMARC 的域名，尤其是那些可能生成大量报告的域名，可能希望在这里以较低的数字开始，以查看其报告处理流程如何应对负载。
域名所有者还可以在其 DMARC 策略记录中使用其他配置选项，但我们提供的提示应该是一个不错的开始。
一个域名的 DMARC 策略是通过在 DNS 命名空间的特定位置发布 DNS TXT 记录来宣布的，即 "_dmarc.domainname.tld"（注意前导下划线）。我们之前示例域的基本 DMARC 策略记录，joesbaitshop.com，可能如下所示：
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
分析此记录，我们有：
v=DMARC1 指定 DMARC 版本（目前只有 1 可用）
p=none 指定首选的处理方法，或 DMARC 策略
rua=mailto:agg_reports@joesbait.com 是用于接收汇总报告的邮箱
ruf=mailto:afrf_reports@joesbait.com 是用于接收取证报告的邮箱
pct=100 是域名所有者希望其策略应用的邮件百分比。刚开始使用 DMARC 的域名，尤其是那些可能生成大量报告的域名，可能希望在这里以较低的数字开始，以查看其报告处理流程如何应对负载。
域名所有者还可以在其 DMARC 策略记录中使用其他配置选项，但我们提供的提示应该是一个不错的开始。
一个域名的 DMARC 策略是通过在 DNS 命名空间的特定位置发布 DNS TXT 记录来宣布的，即 "_dmarc.domainname.tld"（注意前导下划线）。我们之前示例域的基本 DMARC 策略记录，joesbaitshop.com，可能如下所示：
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
分析此记录，我们有：
v=DMARC1 指定 DMARC 版本（目前只有 1 可用）
p=none 指定首选的处理方法，或 DMARC 策略
rua=mailto:agg_reports@joesbait.com 是用于接收汇总报告的邮箱
ruf=mailto:afrf_reports@joesbait.com 是用于接收取证报告的邮箱
pct=100 是域名所有者希望其策略应用的邮件百分比。刚开始使用 DMARC 的域名，尤其是那些可能生成大量报告的域名，可能希望在这里以较低的数字开始，以查看其报告处理流程如何应对负载。
域名所有者还可以在其 DMARC 策略记录中使用其他配置选项，但我们提供的提示应该是一个不错的开始。
总结
在上面的信息中有很多内容需要解读！我们希望您发现创建 DMARC 策略记录的操作指南会对您有所帮助。我们还希望我们对为什么 DMARC 重要性的解释能帮助您明确为什么您应该开始使用这个重要工具来保护您的电子邮件声誉。
当然，这不是该主题的完整或权威文档。如果您想深入研究或需要更多帮助，一个很好的起点是官方 DMARC 常见问题解答。而且，不用说，MessageBird 支持团队随时准备帮助您为 DMARC 配置您的 MessageBird 帐户。
感谢您的阅读—今天就开始使用 DMARC 来保护您的域名吧！
在上面的信息中有很多内容需要解读！我们希望您发现创建 DMARC 策略记录的操作指南会对您有所帮助。我们还希望我们对为什么 DMARC 重要性的解释能帮助您明确为什么您应该开始使用这个重要工具来保护您的电子邮件声誉。
当然，这不是该主题的完整或权威文档。如果您想深入研究或需要更多帮助，一个很好的起点是官方 DMARC 常见问题解答。而且，不用说，MessageBird 支持团队随时准备帮助您为 DMARC 配置您的 MessageBird 帐户。
感谢您的阅读—今天就开始使用 DMARC 来保护您的域名吧！
在上面的信息中有很多内容需要解读！我们希望您发现创建 DMARC 策略记录的操作指南会对您有所帮助。我们还希望我们对为什么 DMARC 重要性的解释能帮助您明确为什么您应该开始使用这个重要工具来保护您的电子邮件声誉。
当然，这不是该主题的完整或权威文档。如果您想深入研究或需要更多帮助，一个很好的起点是官方 DMARC 常见问题解答。而且，不用说，MessageBird 支持团队随时准备帮助您为 DMARC 配置您的 MessageBird 帐户。
感谢您的阅读—今天就开始使用 DMARC 来保护您的域名吧！
