一种有效的工具来对抗欺诈邮件
DMARC，或基于域的邮件认证、报告和遵从性，通常与电子邮件认证协议SPF和DKIM一起提及，但它本身并不是一个认证协议。DMARC的目的是让我们这些域所有者通过以下方式来保护我们的电子邮件声誉：
宣布电子邮件认证实践，
请求对未通过认证检查的邮件进行处理，
请求提供声称来自其域的邮件的报告。
DMARC可以成为我们对抗针对我们域名（例如，网络钓鱼和伪造）欺诈邮件的有效工具，并且可以在收件人中提高对我们邮件的信任。这种更高的信任应该反过来导致更高的邮件互动，而打开并产生点击的邮件能推动销售，并为我们的电子邮件营销活动带来更高的投资回报率。
除了保护我们的域名外，我们还预测，实施DMARC将是“未来保障”我们域名的一个极好方式。在Bird，我们相信，随着行业转向IPv6，几乎可以肯定地，从基于IP的声誉模型会转向基于域的声誉模型。基于域的声誉将需要基于域的认证，而DMARC与DKIM和SPF结合，将帮助域在可能绝对必要之前建立基于域的声誉。
在这篇文章中，我们将告诉你如何利用DMARC来保护你的电子邮件声誉，并给你一些关于如何为你的域设置它的建议。
需要了解的术语
在我们开始为你的域设置DMARC之前，我们想确保我们在使用相同的术语。让我们先定义一些将在本文档中使用的术语。
RFC5322.From 域
RFC5322.From域是电子邮件地址的域部分，通常在我们的电子邮件被读取时由收件人看到。在以下示例中，RFC5322.From域是“joesbaitshop.com”
来自：Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= 域
DKIM是一种认证协议，允许一个域对一条消息负责，这种责任可以通过消息接收者进行验证；这是通过在消息离开其原始位置时将加密签名插入到消息头中来实现的。这些签名有效地是该时刻消息的快照，接收者可以使用这些快照查看消息是否在到达目的地时没有变化。生成和插入这些快照的过程称为DKIM签名，负责签名消息的域会在头中以键值标签形式插入其名称“d=signingDomain”，因此称其为DKIM d=域。
返回路径域
返回路径域，有时称为RFC5321.From域或邮件来自域，是退回的邮件路由的域；它也是在电子邮件交易中进行SPF检查的域。除非收件人足够机智以查看给定消息中的所有头，否则该域通常不会被收件人看到。
默认情况下，通过bird.com发送的所有邮件将其返回路径域设置为birdmail.com，如以下示例所示：
返回路径：<msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
然而，为了使DMARC对你的域有效，您需要利用一个自定义的退回域，那个域将与您的发送域相同，例如，使用yourdomain.com作为发送域时，bounces.yourdomain.com。
组织域
术语“组织域”指的是为在互联网上创建域的存在而提交给注册商的域。对于Bird来说，我们的组织域是bird.com和birdmail.com。
域对齐
理解DMARC的最后一个术语是“域对齐”，它有两种变体：“放松”和“严格”。
放松域对齐
任何两个域被称为放松域对齐，当它们的组织域相同时。例如，a.mail.bird.com和b.foo.bird.com因其共同的组织域bird.com而具有放松域对齐。
严格域对齐
两个域仅当且仅当它们是相同时才被称为严格域对齐。因此，foo.bird.com和foo.bird.com是严格对齐的，因为这两个域是相同的。另一方面，foo.bird.com和bar.foo.bird.com则仅处于放松对齐状态。
DMARC域对齐要求
为了使DMARC验证检查通过，DMARC要求存在域对齐如下：
对于SPF，RFC5322.From域和返回路径域必须对齐
对于DKIM，RFC5322.From域和DKIM d=域必须对齐
对齐可以是放松的或严格的，基于发送域的发布政策。
DMARC如何保护您的电子邮件声誉
当我们提到邮箱提供商或其他域“检查DMARC”或“验证DMARC”或“应用DMARC政策”时，我们的意思是接收消息的域正在执行以下步骤：
确定消息的RFC5322.From域
在DNS中查找该域的DMARC政策
执行DKIM签名验证
执行SPF验证
检查域对齐
应用DMARC政策
为了使一条消息通过DMARC验证，该消息必须通过两个认证和对齐检查中的任何一个。因此，如果以下任何一项为真，则该消息将通过DMARC验证：
消息通过SPF检查，并且RFC5322.From域和返回路径域对齐，或
消息通过DKIM验证，并且RFC5322.From域和DKIM d=域对齐，或
上述两项都为真
使DMARC为您的域工作
既然我们解释了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规范提供了三种选择，供域所有者使用以指定其希望对未通过DMARC验证检查的邮件进行处理的方式。它们是：
none，意味着将邮件视为独立于DMARC验证检查的处理方式
quarantine，意味着接收邮件但将其放在收件箱之外的其他地方（通常是垃圾邮件文件夹）
reject，意味着直接拒绝邮件
在决定DMARC政策时，域所有者应记住，可以在DMARC记录中请求这样的处理；是否荣幸遵守请求的政策由邮件的接收者决定。有些收件人会这样做，而有些可能在应用政策时较为宽松，例如仅在域的政策为reject时才对邮件进行垃圾邮件文件处理。
我们建议所有客户开始时政策为none，以确保安全。虽然我们对通过DKIM签名正确认证您的邮件的能力充满信心，但在对您的DMARC政策采取更积极的态度之前，最好花点时间审查有关您的域的报告。
发布您的DMARC政策
域的DMARC政策通过在DNS命名空间的特定位置发布DNS TXT记录来宣布，即“_dmarc.domainname.tld”（请注意前面的下划线）。例如，以我们之前的域joesbaitshop.com为例，一个基本的DMARC政策记录可能如下所示：
_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 FAQ是一个很好的起点。而且，毫无疑问，Bird支持团队随时准备帮助您配置您的Bird帐户以使用DMARC。
感谢您的阅读——今天就开始使用DMARC来保护您的域名吧！