本文是本系列文章的第三部分，介绍如何理解保护从您的域发送的电子邮件的一些机制. 我们在上个月的APP客户端讨论 / SYSOP会议上讨论了这个话题，但是对于那些错过了他们或想要复习的人来说, 我将在本系列中再次讨论这个问题.
将我们在这里分享的内容付诸实践，不仅可能有助于保护您免受入站欺骗垃圾邮件和恶意软件的侵害，还有助于确保您的域名的合法电子邮件实际上得到了传递. 许多大型电子邮件提供商，如谷歌或微软，越来越怀疑收到的电子邮件不能被验证为来自合法发件人，这正是这些机制的设计目的.
所有这些方法都涉及在您的域的主区域文件中设置特殊的DNS记录，这些记录有助于告诉来自您的域的邮件的潜在收件人该邮件是否来自您授权代表您传输邮件的位置.
在这个系列中, 我们来看看三种不同的机制，如果所有的雇员都能协同工作，以帮助保护你的电子邮件:
- SPF - 发送方策略框架
- DKIM -域密钥识别邮件
- DMARC —基于域的消息认证、报告和一致性
所有这些都是围绕DNS TXT记录在您的DNS域的权威区域文件中设置的
本周- DMARC记录
我们在前两篇文章中介绍了SPF和DKIM记录，所以这次我们更多地讨论DMARC，它可能是三者中最复杂的.
DMARC的使用为域名所有者建立了一种方法:
- 发布其电子邮件身份验证实践
- 说明对未通过身份验证检查的邮件应采取哪些措施
- 启用对声称来自其域的邮件所采取的这些操作的报告
使用DMARC依赖于已建立的SPF和DKIM标准进行电子邮件身份验证，因此这些其他工具的设置和操作是使用DMARC的先决条件.
使用DMARC，域管理员发布一个策略，定义其电子邮件身份验证实践，以及他们希望接收的邮件服务器如何处理违反此策略的邮件. 该DMARC策略被列为域总体DNS TXT记录的一部分.
当入站邮件服务器接收到传入电子邮件时, 它使用DNS查找消息“From”报头中包含的域的DMARC策略. 然后，入站服务器检查评估消息的三个关键因素:
- 消息的DKIM签名是否有效?
- 消息是否来自发送域SPF记录允许的IP地址?
- 消息中的标题是否显示正确的“域对齐”??
有了这些信息, 接收邮件服务器准备应用发送域的DMARC策略来决定是否接受, 拒绝, 否则标记电子邮件消息. 在使用DMARC策略确定消息的正确处置之后, 接收邮件服务器也将结果报告给发送域所有者.
一个典型的DMARC记录的格式看起来像这样:
_dmarc.mydomain.com. 在三种 "v=DMARC1\; p=没有一个\; rua = mailto: dmarc-aggregate@mydomain.com\; ruf = mailto: dmarc-afrf@mydomain.com\; pct=100"
看看这张唱片的各个片段:
_dmarc.mydomain.com -是简单的标识符，表示这是您域的DMARC记录
在三种 -是DNS中的记录标识符，表示这是TXT或“文本”记录类型
v = DMARC1 - 指定DMARC版本
p =没有- 指定首选处理或DMARC策略
rua = mailto: dmarc-aggregate@mydomain.com - 聚合报表是否应发送到该邮箱
ruf = mailto: dmarc-afrf@mydomain.com - 是否应该发送法医报告的邮箱
pct = 100 - 域所有者希望应用其策略的邮件百分比是多少
DMARC规范为域所有者提供了三种选择，用于指定他们对未通过DMARC验证检查的邮件的首选处理方式. 这些“p=策略”是:
- 没有一个:将邮件视为没有任何DMARC验证的邮件
- 检疫:接受邮件，但把它放在收件人收件箱以外的地方(通常是垃圾邮件文件夹)
- 拒绝:直接拒绝该消息
请记住，域名所有者只能请求, 没有力量, enforcement of its DMARC record; it’s up to the inbound mail server to decide whether or not to honor the requested policy.
总报告, 哪些是XML文档，显示声称来自特定域的接收消息的统计数据. 报告的日期包括身份验证结果和消息处理. 聚合报表设计为机器可读.
法医报告, 哪些是身份验证失败的消息的单独副本, 每个都包含在一个完整的电子邮件信息中，使用一种称为AFRF的特殊格式. 取证报告对于排除域自身的身份验证问题和识别恶意域和网站都很有用.
如果您有关于使用DMARC的问题，或者需要帮助为您的域名实现DMARC，请APP客户端的支持团队.
下次见.......
最近的评论