一、DMARC（Domain-based Message Authentication, Reporting & Conformance）
DMARC是一种基于现有的SPF和DKIM协议的可扩展电子邮件认证协议，在邮件收发双方建立了邮件反馈机制，便于邮件发送方和邮件接收方共同对域名的管理进行完善和监督。
DMARC要求域名所有者在DNS记录中设置SPF记录和DKIM记录，并明确声明对验证失败邮件的处理策略。邮件接收方接收邮件时，首先通过DNS获取DMARC记录，再对邮件来源进行SPF验证和DKIM验证，对验证失败的邮件根据DMARC记录进行处理，并将处理结果反馈给发送方。
DMARC能够有效识别并拦截欺诈邮件和钓鱼邮件，保障用户个人信息安全。
设置完 SPF 和 DKIM 后，您就能以 TXT 记录的形式向您网域的 DNS 记录添加政策，从而配置 DMARC（方法与配置 SPF 或 ADSP 一样）。
例子：paypal.com的dmarc记录
_dmarc.paypal.com text = "v=DMARC1\; p=reject\; rua=mailto:[email protected]\; ruf=mailto:[email protected],mailto:[email protected]"
二、DMARC记录中常用参数
adkim：（纯文本；可选的；默认为“r”）表明域名所有者要求使用严格的或者宽松的DKIM身份校验模式，有效值如下：
r: relaxed mode 宽松
s: strict mode 严格
aspf：（纯文本；可选的；默认为“r”）表明域名所有者要求使用严格的或者宽松的SPF身份校验模式，有效值如下：
r: relaxed mode 宽松
s: strict mode 严格
fo：故障报告选项（纯文本；可选的；默认为0），以冒号分隔的列表，如果没有指定“ruf”，那么该标签的内容将被忽略。
0：如果所有身份验证机制都不能产生“pass”结果，那么生成一份DMARC故障报告；
1：如果任一身份验证机制产生“pass”以外的结果，那么生成一份DMARC故障报告；
d：如果消息的签名验证失败，那么生成一份DKIM故障报告；
s：如果消息的SPF验证失败，那么生成一份SPF故障报告。
p：要求的邮件接收者策略（纯文本；必要的）表明接收者根据域名所有者的要求制定的策略。
none：域名所有者要求不采取特定措施
quarantine：域名所有者希望邮件接收者将DMARC验证失败的邮件标记为可疑的。
reject：域名所有者希望邮件接收者将DMARC验证失败的邮件拒绝。
pct：（纯文本0-100的整型；可选的，默认为100）域名所有者邮件流中应用DMARC策略的消息百分比。
rf：用于消息具体故障报告的格式（冒号分隔的纯文本列表；可选的；默认为“afrf”）
ri：汇总报告之间要求的间隔（纯文本32位无符号整型；可选的；默认为86400）.表明要求接收者生成汇总报告的间隔不超过要求的秒数。
rua：发送综合反馈的邮件地址（逗号分隔的DMARC URI纯文本列表；可选的）
ruf：发送消息详细故障信息的邮件地址（逗号分隔的DMARC URI纯文本列表；可选的）
sp：要求邮件接收者对所有子域使用的策略（纯文本；可选的），若缺省，则“p”指定的策略将应用到该域名和子域中。
v：版本（纯文本；必要的）值为“DMARC1”，必须作为第一个标签。
其中只有 v（版本）和 p（策略）标记是必需的。
有关其他可用标记，请参阅 DMARC 标记注册表
Google 不支持用于分发取证报告的 DMARC“ruf”标记。
有三种政策设置（即邮件处理设置）可供选用：
- 无 - 不采取任何行动。仅在每日报告中记录受影响的邮件。
- 隔离 - 将受影响的邮件标为垃圾邮件。
- 拒绝 - 在 SMTP 传输层取消邮件。
匹配模式指发件人记录与 SPF 和 DKIM 签名相比的一致程度，有两个可能的值：宽松或严格，分别以“r”和“s”表示。简言之，“宽松”允许部分匹配（例如给定网域的子域），而“严格”要求完全匹配。
请务必为您输入的电子邮件地址添加可选的“rua”标记，以便接收每日报告。
在DNS Editor里如下显示：
三、格式定义
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
例如：“mailto:[email protected]!50m”表示要求通过邮件发送给“[email protected]”的报告的有效载荷不超过50MB。
dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]
dmarc-version = "v=DMARC1"
dmarc-sep = ";"
dmarc-request = "p=(none/quarantine/reject)"
dmarc-srequest = "sp=(none/quarantine/reject)"
dmarc-auri = "rua=dmarc-uri *(,dmarc-uri)"
dmarc-furi = "ruf=dmarc-uri *(,dmarc-uri)"
dmarc-adkim = "adkim=(r/s)"
dmarc-aspf = "aspf=(r/s)"
dmarc-ainterval = "ri= 1*DIGIT"
dmarc-fo = "fo=(0/1/d/s)*(:(0/1/d/s))"
dmarc-rfmt = "rf= Keyword *(:Keyword)"
; 仅用于报告格式注册
dmarc-percent = "pct=1*3DIGIT"四、例子
1、用dig命令查询DMARC记录
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:[email protected];
ruf=mailto:[email protected]"注意：DMARC DNS TXT记录的拥有者字段必须始终为“_dmarc”，若指定该记录应用到域或子域，可以采用“_dmarc.example.com”的形式。
2、DMARC DNS记录
; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:[email protected]; "
"ruf=mailto:[email protected]" )五、部署
我们强烈建议您按照以下操作顺序应用政策，从而逐步加强 DMARC 的使用。首先，监控您的流量，并查找报告中的异常之处，例如仍没有签名或可能经过伪装的邮件。在您对结果感 到满意之后，将 TXT 记录策略设置从“无”改为“隔离”。然后，再次查看结果，这次要检查垃圾邮件的捕获情况及每日 DMARC 报告。最后，在确信您的所有邮件都已签名之后，将策略设置改为“拒绝”，以充分利用 DMARC。重新查看报告，以确保结果如您所愿。
类似地，可选的 pct 标记也可以用来对 DMARC 进行分步部署和采样。因为默认值为 100%，所以，如果在 DMARC TXT 记录中采用“pct=20”，则系统只对所有受该策略影响的邮件中的五分之一（而不是全部）真正执行此操作。在您选择隔离和拒绝邮件时，此设置非常有用。您一开始可以采用较低的百分比，之后每隔几天逐步提升比例。
保守的部署周期大致如下：
- 全部监控。
- 隔离 1%。
- 隔离 5%。
- 隔离 10%。
- 隔离 25%。
- 隔离 50%。
- 全部隔离。
- 拒绝 1%。
- 拒绝 5%。
- 拒绝 10%。
- 拒绝 25%。
- 拒绝 50%。
- 全部拒绝。
尝试尽快删除百分比，以完成整个部署。
同时也提醒您，要查看每日报告。
六、记录示例
以下是一些 DMARC TXT 记录示例 (_dmarc.your_domain.com IN TXT)，您可以根据实际使用情况进行修改。当然，您需要将“your_domain.com”和“postmaster@your_domain.com”替换为您的实际域名和电子邮件地址。
不采取任何行动
在以下 TXT 记录中，如果有任何声称从 <您的网域>.com 发送的邮件未通过 DMARC 检查，系统不会采取任何行动，而是会在发送给 postmaster@<您的网域>.com 的每日汇总报告中显示所有这类邮件。
"v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com"
隔离邮件
在以下 TXT 记录中，如果有任何声称从 <您的网域>.com 发送的邮件未通过 DMARC 检查，系统会按 5% 的比例隔离这类邮件，然后将每日汇总报告通过电子邮件发送到 postmaster@<您的网域>.com。
"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@your_domain.com"
拒绝邮件
在以下 TXT 记录中，如果有任何声称从 <您的网域>.com 发送的邮件未通过 DMARC 检查，系统会完全拒绝此类邮件，然后将每日汇总报告通过电子邮件发送到 postmaster@<您的网域>.com 和 dmarc@<您的网域>.com。
"v=DMARC1; p=reject; rua=mailto:postmaster@your_domain.com, mailto:dmarc@your_domain.com"
七、每日报告
每日报告采用 XML 格式。阅读每日报告有助于您更好地了解邮件递送情况，并确保外发电子邮件来源经过适当的身份验证。如果不同的 IP 地址发送声称来自您网域的邮件，请确保这些 IP 地址确实符合规范，并使用 DKIM 对其进行正确配置，或将其添加到相应的 SPF 范围内。如果出现新的电子邮件来源，或现有电子邮件来源的配置出现问题，这些报告还可以帮助您在政策遭到屏蔽的情况下快速采取行动。
以下是一份报告的摘录，其中显示了从两个 IP 地址发送邮件的结果，一封邮件为直接发送，另一封为转发。两封邮件均成功通过检查：
<record>
<row>
<source_ip>207.126.144.129</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>207.126.144.131</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>参考：https://support.google.com/a/answer/2466563?hl=zh-Hans
https://dmarc.org//draft-dmarc-base-00-01.html#iana_dmarc_tags
DMARC RFC协议：http://tools.ietf.org/html/rfc7489
DMARC官方网站：https://dmarc.org/