一般未配置SPF/DKIM/DMARC的邮件服务器存在两种安全问题：邮件诈骗和邮件反向散射。
SPF：校验发件端IP地址，防止邮件诈骗。
DKIM：校验邮件签名信息，防止邮件诈骗和邮件反向散射。
MDARC：基于SPF/DKIM，按照真实发件端的声明进行真实性验证及异常报告。
SPF原理
SPF(Sender Policy Framework) 是一种以IP地址认证电子邮件发件人身份的技术，通过认证发件IP与发件域名中的声明进行匹配，从而防止别人伪造你来发邮件。
SPF验证过程
接收端获取发件端IP(发送端的连接IP，无法改变).
接收端查询发件域名(SMTP会话过程中，MAIL FROM指令中的用户名域名部分)的txt记录
根据SPF记录的规则进行匹配，可按声明的策略进行处理。
SPF配置
参考RFC 4408标准，在DNS上新建一条txt记录，内容类似如下：
安全性问题
邮件伪造
这是最众所周知的问题，如果没有配置SPF，攻击者可以任意伪造邮件，相关的伪造方式可以参考我之前的文章: SMTP命令行及Python发送邮件
SPF过配置
假设一种情况，如果我的SMTP服务器是：10.1.1.2和10.1.1.110，为了方便起见，将SPF记录设置为：v=spf1 ip4:10.1.1.0/24 -all。 那么这就存在安全隐患了，在该C段里面，任意一台主机被getshell，那么攻击者就可以通过合法的IP发送伪造邮件了。
如下例子中，8组C段，共计2000多个IP，无论这些IP是否属于该单位，均有很大的可能性被getshell.
通过简单扫描(nmap -F)，发现大量资产：
不能防护子域名域名？ （待验证）
不确定是否因为SPF可以保护或者只是网易的反垃圾邮件机制好，测试暂未通过：
DKIM
区别于SPF，DKIM使用非对称加密的方式对发件人进行身份验证。
DKIM原理
DMKI（DomainKeys Identified Mail）是基于传统的密钥认证方式，它会产生两组钥匙，公钥(public key)和私钥(private key)，公钥将会存放在 DNS 中，而私钥会存放在邮件发送服务器中。数字签名会自动产生，并依附在邮件头中，发送到寄信者的服务器里。公钥则放在DNS服务器上，供自动获得。收信的服务器，将会收到夹带在邮件头中的签名和在DNS上自己获取公钥，然后进行比对，比较寄信者的域名是否合法，如果不合法，则判定为垃圾邮件。
DKIM验证过程
发送端：
生成一对密钥，即公钥和私钥。
通过DNS发送domainkey的公钥。
发送邮件时，用私钥加密该邮件，并将加密后的密文附加到邮件中。
接收端：
提取信头中dkim信头，并查询该发件域的公钥。
利用该公钥，对信头中的密文进行验证。
查询该域名的_adsp._domainkey记录，可按该策略进行处理。
DKIM配置
确定一个(或多个) DKIM selector(s)，比如default._domainkey、beijing._domainkey、subcompany._domainkey，用于配置不同的公私玥。
使用openssl工具生产一对(或多对)公钥和密钥。
在邮件服务器上配置DKIM（具体不会，可询问邮件供应商）。
在DNS上给DKIM selector(s)添加txt记录，比如：
新建foobar._domainkey.oddboy.cn的TXT记录，内容：
v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8T/rJ2fc7nPxDHF/wjTYgDXCjRDDudAuS1eJ7SAUY06BBZuUXhLus2jWpHL5e3YugU9+NoHJsG9g+B34PJxaSnMhcOwrybMsv9ovMuQtzZO5/wDobO0Usc6HIj5K0y9JL7Kqlq5zUv3KDIE3ZOA3aVkgeeeo6Er91Oc8DpwcopwIDAQAB
查看DKIM记录：
安全性问题
DKMI绕过
暂时未具体研究，可参考文章：
绕过DKIM验证，伪造钓鱼邮件
DMARC
DMARC（Domain-based Message Authentication, Reporting and Conformance）和其他电邮安全协议的美好初衷一样，主要目的是识别并拦截钓鱼邮件，使钓鱼邮件不再进入用户邮箱中（收件箱or垃圾箱），减少邮箱用户打开/阅读到钓鱼邮件的可能性，从而保护用户的帐号密码等个人信息安全。
DMARC原理
DMARC协议基于现有的SPF和DKIM两大主流电子邮件安全协议，由邮件发送方在DNS里声明自己采用该协议，当邮件接收方（其MTA需支持DMARC协议）收到邮件时进行DMARC校验，若校验失败发送一封report到指定URI（通常是一个邮箱地址）。
DMARC验证过程
发送端
正确配置SPF和DKIM。
发布_dmarc的TXT记录。
– 接收端
1. 查询_dmarc记录
2. 验证SPF
3. 验证DKIM
4. 验证DMARC
5. 按策略处理，同时发送通知邮件
DMARC配置
RFC 7489规范
常用参数
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=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com“
解读：协议版本为DMARC1，收件方对所有(100%，默认100%)进行检查，当检测到邮件伪造时收件方拒绝(reject)该邮件，并且将一段时间的汇总报告到`postmaster@dmarcdomain.com`。
查看DMARC记录：
安全性问题
不安全配置导致问题
比如，在初期测试阶段会将DMARC记录配置为”p=none”，但在生产中未修改到reject活着quarantine，则相当于未起到任何作用，所有的欺诈邮件都会被通过，即使配置了SPF和DKIM。
摘自:https://www.dazhuanlan.com/2019/10/13/5da2112ca6e7a/