本文是本系列文章的开始，介绍如何理解保护从您的域发送的电子邮件的一些机制. 我们在本月的APP客户端讨论 / SYSOP会议上讨论了这个话题，但是对于那些错过了他们或想要复习的人，我在这个系列中再次讨论这个话题.
将我们在这里分享的内容付诸实践，不仅可能有助于保护您免受入站欺骗垃圾邮件和恶意软件的侵害，还有助于确保您的域名的合法电子邮件实际上得到了传递. 许多大型电子邮件提供商，如谷歌或微软，越来越怀疑收到的电子邮件不能被验证为来自合法发件人，这正是这些机制的设计目的.
所有这些方法都涉及在您的域的主区域文件中设置特殊的DNS记录，这些记录有助于告诉来自您的域的邮件的潜在收件人该邮件是否来自您授权代表您传输邮件的位置.
在本系列中，我们将介绍三种不同的机制，如果所有采用的机制都能相互协作，以帮助保护您的电子邮件:
- SPF - 发送方策略框架
- DKIM -域密钥识别邮件
- DMARC —基于域的消息认证、报告和一致性
所有这些都是围绕DNS TXT记录设置在您的DNS域的权威区域文件
本周- SPF记录
SPF记录用于确定哪些主机可以代表您的域发送电子邮件.
典型SPF记录的格式是这样的:
mydomain.com. 在三种 " v = spf1 mx . a 包括:_spf . a.谷歌.com ~”
它们看起来有点像字母汤的集合，但让我们看看我是否能解释清楚其中包含的内容. 拆开这个DNS SPF TXT记录:
mydomain.com 仅仅是您的域名的标识符吗
在三种 -是DNS中的记录标识符，表示这是TXT或“文本”记录类型
v = spf1 -标识SPF的版本号
前三个部分只是为SPF记录中的主要部分设置了表格这些记录是允许代表你的域发送邮件的设备的标识符.
在我们的例子中:
mx -确定任何有效的MX服务器，已经确定接收邮件在我们的区域文件为我们的域也允许发送邮件为我们的域. 这很有意义，因为MX是邮件交换器的简写，所以这是一种非常快速的方式，说明任何被目的标识为邮件交换器的服务器都应该被视为有效的发送者.
a -识别在我们的DNS区域文件中定义的任何有效的主机与“A”或主机类型记录也允许为该域发送邮件.
So, 以上两个条目使我们能够快速识别在我们控制下的设备类别，这些设备被授权代表我们的域发送邮件. 很简单，但现在我们要变得更复杂一点.
当我们使用其他第三方服务时，这些服务可能代表我们的域名发送电子邮件，比如来自谷歌 Apps的服务器，或者可能是由第三方供应商托管的学生服务应用程序，或者可能是本地RIC? 下面是使用" 包括: "关键字的示例，表示下面域名内的主机也被授权代表我们发送主机:
包括: _spf.谷歌.在这种情况下，标识来自“_spf . Com”内部的主机.谷歌.Com "域名被允许代表我们发送邮件.
您可以在SPF记录中使用尽可能多的“包括:”语句，以涵盖您可能使用的所有可能的第三方提供商.
SPF记录的末尾是“所有”标识符，它告诉收件人如何处理从SPF记录中未被识别为授权的主机接收的邮件.
这里的关键不是“所有”这个词，而是放在“所有”这个词前面的符号。.
- “-全部”被称为硬失败——不符合要求，要求被拒绝
- “~all”被称为软不合格——标记为不符合要求，但要求被接受
- “?“所有”被称为“中立”——留给收信人自行决定.
随着电子邮件提供商在打击垃圾邮件和恶意软件方面越来越积极，实际情况是，收到的任何不能在SPF记录中识别为来自有效发件人的邮件都很可能被拒绝或至少被标记为垃圾邮件.
这就是我们的例子.
还有几个其他可能的标识符也可以在SPF记录中使用, 但我们将把这些留到下次讨论.
如果您对使用SPF有疑问或需要帮助为您的域实现SPF，请APP客户端的支持团队.
在关于这个主题的下一个花絮中，我们将探讨DKIM记录的使用.
下次见.......
最近的评论