首页›指南›电子邮件安全
电子邮件安全 · 了解
SPF声明哪些服务器可以代表某个域名发信，DKIM为邮件签名，DMARC则验证两者之一是否与“发件人”栏显示的域名一致，并规定验证失败时如何处理。三者结合，可以防止陌生人使用与您完全相同的域名。它们不阅读正文：相似域名、具有欺骗性的显示名称或被入侵的账户都会被放行。
RFC 7208的出发点是这样一个事实：邮件协议本身并不阻止服务器声称使用任意发件地址。SPF允许域名所有者在DNS中发布获准以其名义发信的服务器列表，并允许收件服务器核实这一授权。
有两点说明至关重要：
一个域名只能发布一条SPF记录。所有发信来源都必须列入其中：邮件系统、开票软件、电子报工具、CRM、扫描后发送邮件的复印机。
根据RFC 6376，DKIM允许签名域名的所有者通过加密签名，声明对某封邮件承担一定责任。公钥发布在DNS中。验证签名可以确认被签名的部分自签名以来未发生变化。
签名随邮件一同传输。因此，只要中继不修改主题或正文，它在经过中继或转发时比SPF更能保持有效。而在邮件底部添加注记的邮件列表会破坏签名。
根据同一RFC，DKIM不做以下事情：它不加密邮件；验证失败并不要求拒收；签名域名也不必是“发件人”栏中显示的域名。而这正是DMARC所填补的漏洞。
RFC 7489将DMARC定义为域名所有者在域名层面表达策略的一种方式。该机制以对齐为基础：“发件人”栏显示地址的域名，必须与经SPF或DKIM验证的域名一致。如果两者都未对齐，DMARC验证即失败。
此时，域名会发布其希望的处理方式：
DMARC还规定了报告机制：汇总报告，概括哪些服务器以该域名名义发信及其验证结果；以及逐封邮件的失败报告。正是这些报告，让您发现某个被遗忘、却仍在以您名义发信的工具，或者有人冒用您的域名。
| 机制 | 验证内容 | 不检查的内容 |
|---|---|---|
| SPF | 投递邮件的服务器是否获得信封域名的授权 | 显示的地址、内容 |
| DKIM | 经签名的邮件未被篡改；某个域名对其承担责任 | 显示的地址、内容是否真实 |
| DMARC | 显示的域名与SPF或DKIM对齐；失败时的处理策略 | 相似域名、显示名称、正文 |
它能阻止一部分域名冒用，而不是所有网络钓鱼。RFC 7489对此有明确说明：DMARC不处理视觉上相似的域名，也不处理显示名称的滥用，内容分析也不在其范围之内。它并不试图解决欺诈邮件的所有问题。
具体而言，DMARC看不到：
这些情况需要其他分析手段：域名相似度、信誉、内容、行为。请参阅垃圾邮件、网络钓鱼、恶意软件与被入侵账户。
转发往往会导致SPF失效，修改邮件的邮件列表会导致DKIM失效，于是一封合法邮件也会未通过DMARC验证。RFC 8617（实验性标准）描述的ARC，允许每个中间环节证明其所观察到的认证结果。最终收件服务器可以选择是否采信。
这是两个经常被混淆的话题。
举例说明。一家事务所将DMARC设为“none”并阅读了最初的报告。它从中发现了三个来源：自己的邮件系统，已正确对齐；开票软件，以事务所的域名发送账单但未做DKIM签名；以及一台位于国外的未知服务器，以其名义发送了数百封邮件。事务所修正了开票软件，等待一个干净的报告周期后，切换到“quarantine”：执行DMARC的收件方从此将该未知服务器发出的邮件视为可疑邮件。
更换邮件系统时，这些记录应在更改MX之前准备好。不中断业务的邮件系统迁移指南介绍了这一环节，此处不再赘述。
不能。它只是通过报告进行观察。保护从“quarantine”或“reject”开始。
最常见的原因是：转发、邮件列表，或某个代您发信的服务既未在SPF中声明，也未进行DKIM签名。
部署在发信路径上的网关可以代为签名。请参阅保护您现有的邮件系统。
在邮件头中。对于Klytic MTA，请参阅查看并导出过滤器的判定。
Klytic MTA可部署在任何邮件系统前端，同时处理这两个话题：
DMARC只是其中一层：Klytic MTA还增加了对仿冒域名、显示名称和诈骗情景的检测，详见身份冒用与冒充高管诈骗。
如果您使用Klytic Mail，您的域名已配置SPF、DKIM和DMARC：这属于对发信域名的保护。而Klytic MTA无论是否使用Klytic Mail都可以订阅。
查阅于2026年10月。
