电子邮件身份验证的最佳实践 — 部署SPF、DKIM和DMARC的最佳方法

简介

本指南介绍目前使用的三种主要电子邮件身份验证技术 — SPF、DKIM和DMARC，并讨论其实施的各个方面。讨论了几个实际电子邮件架构情况，以及在思科电子邮件安全产品集上实施这些情况的指导原则。由于这是实践最佳实践指南，因此将省略一些更复杂的材料。必要时，可以简化或压缩某些概念，以便便于理解所介绍的内容。

产品知识要求

本指南是高级文档。为了贯彻所提供的材料，读者应具备思科邮件安全设备的产品知识，达到思科邮件安全现场工程师认证级别。此外，读者应该对DNS和SMTP及其操作有强大的命令。了解SPF、DKIM和DMARC的基本知识是一个好消息。

电子邮件身份验证 — 简短概述

发件人策略框架(SPF)

发件人策略框架最初于2006年发布，作为RFC4408。当前版本在RFC7208中指定，并在RFC7372中更新。实际上，它为域所有者使用DNS向接收者通告其合法电子邮件源提供了一种简单的方法。虽然SPF主要对返回路径(MAIL FROM)地址进行身份验证，但规范建议（并提供机制）也对SMTP HELO/EHLO参数（在SMTP会话期间传输的发件人网关的FQDN）进行身份验证。

SPF使用语法非常简单的TXT类型DNS资源记录：

spirit.com       text = "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ~all"

上述Spirit Airlines记录允许来自@spirit.com地址的电子邮件来自特定/24子网、由FQDN标识的两台计算机和Microsoft Office365环境。末端的“~all”限定符指示接收器将任何其他源视为软故障（SPF的两种故障模式之一）。请注意，发件人不会指定接收方应如何处理失败邮件，而只是指定接收方将失败到何种程度。

另一方面，Delta采用不同的SPF方案：

delta.com文本= "v=spf1 a:smtp.hosts.delta.com包括：_spf.vendor.delta.com -all"

为了最大限度地减少所需的DNS查询数，Delta创建了一条“A”记录，列出其所有SMTP网关。它们还在“_spf.vendor.delta.com”中为其供应商提供单独的SPF记录。它们还包括Hard Fail(硬故障)说明，所有未通过SPF（“ — all”限定符）身份验证的消息。 我们可以进一步查看供应商的SPF记录：

_spf.vendor.delta文本= "v=spf1 include:_spf-delta.vrli.com包括：_spf-ncr.delta.spf.niceondemand.com包括：_spf.qemailserver.com包括：skytel.com包括：epsl1.com."

因此，发件人@delta.com的电子邮件可以合法地从法航的电子邮件网关发送。

而United则使用更简单的SPF方案：

united.com文本= "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.93 ip4:74.209.251.0/24 mx ~all"

除了自己的公司邮件网关，他们还包括其电子邮件营销提供商("usa.net"和"enviaremails.com.br")、传统大陆航空网关，以及MX记录（"MX"机制）中列出的所有内容。 请注意，MX(域的传入邮件网关)可能与传出不同。对于小型企业，它们通常是相同的，而大型企业则有单独的基础架构来处理传入邮件，并单独处理传出邮件。

此外，值得注意的是，上述所有示例都广泛使用其他DNS推荐（“包括”机制）。 但是，由于性能原因，SPF规范将检索最终记录所需的DNS查找总数限制为10。任何具有10个以上DNS递归级别的SPF查找都将失败。

域密钥识别邮件(DKIM)

RFC 5585、6376和5863中规定的DKIM是两个历史性建议的合并：雅虎的DomainKeys和思科识别的互联网邮件。它为发件人提供了一种简单的方法来对传出邮件进行加密签名，并将签名（以及其他验证元数据）包含在邮件报头(“DKIM-Signature”)中。 发件人在DNS中发布其公钥，因此任何接收方都可以轻松检索密钥并验证签名。DKIM不对物理邮件的源进行身份验证，但它依赖于以下事实：如果源拥有发件人组织的私钥，则它被隐式授权代表发件人发送电子邮件。

要实施DKIM，发送组织将生成一个或多个公钥对，并将DNS中的公钥作为TXT记录发布。每个密钥对都由“选择器”引用，因此DKIM验证器可以区分密钥。将对传出邮件进行签名，并插入DKIM签名报头：

DKIM签名：v=1;a=rsa-sha1;c=放松/放松；s=united;d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:To:From:Reply-To:Subject:List-Unsubscribe:Message-ID;i=MileagePlus@news.united.com;bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=;

b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4mKhH1mmtyYgwYqT01rEwL0V8MEY1MzxTrzijkLPGqt/sK1WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=

签名的格式相当简单。"a"标记指定用于签名的算法，"c"指定使用的规范化方案[1],"s"是选择器或密钥引用，"d"是签名域。此DKIM签名报头的其余部分是邮件特定的：“h”列出签名的报头，“i”列出签名用户的身份，最后报头以两个单独的哈希结尾：“bh”是签名报头的哈希值，而“b”是消息正文的哈希值。

当接收DKIM签名的消息时，接收方将通过构建以下DNS查询来查找公钥：

<selector>._domainkey.<signing domain>

在DKIM签名报头中指定。在上例中，我们的查询是“united._domainkey.news.united.com”：

united._domainkey.news.united.com文本= "g=*\;k=rsa\;n=" "联系" "postmaster@responsys.com" "带" "任何" "问题" "关于" "此" "签名" "\;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35hWglo4v6dTy5Qmxcuv5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB2IBwIDAQAB\;"

返回的DNS记录包含密钥以及其他可选参数。[2]

DKIM的主要问题是初始规范不允许发送方使用DKIM的广告。因此，如果消息没有签名，接收方就很难知道该消息应该已签名，在这种情况下，它很可能不是真实的。由于单个组织可以（而且通常会）使用多个选择器，因此“猜测”域是否启用了DKIM并不简单。制定了单独的标准“作者域签名实践”来涵盖这一内容，但由于使用率较低以及其他问题在2013年被淘汰，没有后继。

基于域的消息身份验证、报告和一致性(DMARC)

DMARC是涵盖的三种电子邮件身份验证技术中最年轻的一种，专为解决SPF和DKIM的缺点而开发。与其他两种不同，它验证消息的报头，并链接到之前由另外两种执行的检查。RFC7489中指定了DMARC。

DMARC相对于SPF和DKIM的增值包括：

• 确保所有可用标识（HELO、MAIL FROM和/或DKIM签名域）与From标头对齐（完全匹配或从属）
• 为发送方域所有者提供一种方法，以便为接收方指定必须如何处理失败消息的策略
• 为发件人域所有者提供反馈工具，以便其获知任何失败邮件，从而便于识别网络钓鱼活动或SPF/DKIM/DMARC策略分配中的错误

DMARC还使用基于DNS的简单策略分配机制：

_dmarc.aa.com文本= "v=DMARC1\;p=无\;fo=1\;ri=3600\;rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\;ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com

 DMARC策略规范中唯一的必需标记是“p”，指定对失败邮件使用的策略。它可以是以下三项之一：无，隔离，拒绝。

最常用的可选参数与报告有关：“rua”指定URL(邮件地址：或http:// URL（使用POST方法），以发送有关声称来自特定域的所有失败邮件的每日汇总报告。“ruf”指定URL，以提交有关每条失败消息的即时详细失败报告。

根据规范，接收方必须遵守通告的策略。否则，它们必须在聚合报告中通知发件人域所有者。

DMARC的核心概念是所谓的标识符对齐。标识符对齐定义邮件如何通过DMARC验证。SPF和DKIM标识符分别对齐，消息需要传递任何标识符才能整体传递DMARC。但是，有一个DMARC策略选项，发件人可以在其中请求生成失败报告，即使一个对齐通过，但另一个对齐失败。我们可以在上例中看到，“fo”标记设置为“1”。

消息遵循DKIM或SPF标识符对齐有两种方式，严格和放松。严格遵循性意味着报头发件人的FQDN必须完全匹配SPF的DKIM签名的签名域ID（“d”标记）或MAIL FROM SMTP命令的FQDN。另一方面，“放松”允许“来自FQDN的报头”成为前面提到的两个子域。  这在将电子邮件流量委托给第三方时具有重要意义，本文档稍后将讨论此问题。

SPF部署注意事项

接收器的SPF

在思科邮件安全设备或云邮件安全虚拟设备上配置SPF验证非常简单。在本文档的其余部分，对ESA的任何引用也将包括CES。

SPF验证在邮件流策略中配置 — 全局运行它的最简单方法是在适当侦听程序的默认策略参数部分将其打开。 如果对传入和传出邮件集合使用同一侦听程序，请确保“RELAYED”邮件流策略的SPF验证设置为“关闭”。

由于SPF不允许指定要执行的策略操作，因此SPF验证（以及DKIM，如后面所述）只验证消息，并为执行的每个SPF检查插入一组报头：

Received-SPF:通过(mx1.hc4-93.c3s2.smtpi.com:域

  united.5765@envfrm.rsys2.com指定12.130.136.195为

  允许的发件人)identity=mailfrom;

  client-ip=12.130.136.195;receiver=mx1.hc4-93.c3s2.smtpi.com;

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="united.5765@envfrm.rsys2.com";

  x-conformance=sidf_compatible;x-record-type="v=spf1"

Received-SPF:无(mx1.hc4-93.c3s2.smtpi.com:无发件人

  可从域获得的真实性信息

  postmaster@omp.news.united.com)identity=helo;

  client-ip=12.130.136.195;receiver=mx1.hc4-93.c3s2.smtpi.com;

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="postmaster@omp.news.united.com";

  x-conformance=sidf_compatible

请注意，对于此消息，SPF验证了两个“身份”：“mailfrom”是规范规定的，“helo”是规范建议的。该消息将正式通过SPF，因为只有前者与SPF合规性相关，但某些接收方可能会批准不包含SPF记录的发件人的HELO身份。因此，最好将传出邮件网关的主机名包含在SPF记录中。

一旦邮件流策略验证邮件，本地管理员就可以配置要执行的操作。这是使用邮件过滤器规则SPF-status()[3]完成的，或者使用该规则创建传入内容过滤器并将其应用于适当的传入邮件策略。

图1:SPF验证内容过滤器条件

建议的过滤器操作是丢弃Fail（SPF记录中的“ — all”）邮件，并隔离策略隔离区中Softfail（SPF记录中的“~all”）邮件，但这可能因您的安全要求而异。有些接收方只标记失败消息，或者不采取可见操作，但会向管理员报告。

最近，SPF的普及率大幅飙升，但许多域发布的SPF记录不完整或不正确。要处于安全状态，您可能需要隔离所有SPF故障邮件，并监控隔离一段时间，以确保没有“误报”。

如果您为其他域或第三方提供电子邮件服务

如果您为第三方提供电子邮件传送或托管服务，则他们必须添加主机名和IP地址，以便将邮件传送到自己的SPF记录。最简单的方法是提供商创建“伞”SPF记录，并让客户在其SPF记录中使用“include”机制。

suncountry.com文本= "v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.109.66.68 ip4:198.179.134.238 ip4:107.20.247.57 ip4:207.87.182.66 ip4:199.66.248.0/22 include:cust-spf.exactarget.com ~all"

我们可以看到，Sun Country有一些电子邮件由他们自己控制，但他们的营销电子邮件被外包给第三方。扩展引用的记录可显示其营销邮件服务提供商使用的当前IP地址列表：

cust-spf.exacttarget.com文本= " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:13.111.0.0/18 -all"

这种灵活性使电子邮件服务提供商能够扩展，而无需联系每个客户修改其DNS记录。

如果您使用第三方电子邮件服务

与前一段类似，如果您使用任何第三方电子邮件服务，并且希望建立完全经SPF验证的邮件流，则必须在您的邮件中包含他们自己的SPF记录。

jetblue.com描述性文本“v=spf1 include:_spf.qualtrics.com ?all”

JetBlue使用Qualtrics分析服务，他们唯一需要做的就是提供Qualtrics的正确SPF记录。同样，大多数其他ESP提供要包含在其客户记录中的SPF记录。

如果您的ESP或电子邮件营销人员不提供SPF记录，您必须直接在您的中列出其传出邮件网关。但是，您有责任保持这些记录的准确性，如果提供商添加了其他网关或更改了IP地址或主机名，您的邮件流可能会受到威胁。

对SPF不敏感的第三方的额外危险来自共享资源：如果ESP使用相同的IP地址来传送多个客户的电子邮件，从技术上讲，一个客户可以生成假装是通过同一接口传送的另一个客户的SPF有效消息。因此，在设置任何SPF限制之前，您应调查MSP的安全策略和对电子邮件身份验证的感知。如果他们没有回答您的问题，考虑到SPF是Internet上信任的基本机制之一，强烈建议您重新考虑您选择的MSP。  它不仅涉及安全性 — MSP采用的SPF、DKIM、DMARC和其他发件人最佳实践[4]是保证可交付性的保证。如果您的MSP不遵守他们的指示或不正确地遵循他们的指示，将降低大型接收系统的可信度，并可能延迟甚至阻止您的消息。

（子）无邮件流量的域

如今，大多数组织都拥有多个用于营销目的的域，但只主动将一个域用于企业电子邮件流量。即使SPF在生产域上正确部署，恶意攻击者仍然可以使用其他域来欺骗组织的身份，而这些域并非主动用于电子邮件。SPF可以防止通过特殊的“拒绝所有”SPF记录发生此情况 — 对于不生成邮件流量的任何域（和子域！），在DNS中发布“v=spf1 -all”。openspf.org是SPF理事会的网站，这是一个很好的例子。

由于SPF委派仅对单个域有效，因此也必须发布“拒绝所有”SPF记录，以用于您可能正在使用但不会生成电子邮件的任何子域。即使您的生产域有“常规”SPF记录，也要付出额外的努力，在没有流量的子域中添加“拒绝所有”记录。同样，不要忘记接收并不等同于发送：域很可能正在接收电子邮件，但永远不会是源。对于短期营销域（例如，事件、有限时间促销、产品发布……）而言，这一点非常正确，传入这些域的电子邮件将传送到您的生产域，对这些电子邮件的任何回复都将从生产域传送。这些短期域将具有有效的MX记录，但应具有SPF记录，该记录也将其标识为没有电子邮件来源。

DKIM部署注意事项

DKIM，用于接收器

在ESA上配置DKIM验证类似于SPF验证。在邮件流策略的默认策略参数中，只需将DKIM验证设置为“打开”。同样，由于DKIM不允许任何策略规范，这只需验证签名并插入“Authentication-Results”报头：

身份验证结果：mx1.hc4-93.c3s2.smtpi.com;dkim=pass（经签名验证）header.i=MileagePlus@news.united.com

任何基于DKIM验证结果的操作都必须由内容过滤器执行：

图2:DKIM验证内容过滤条件

与SPF不同，DKIM操作实际消息文本，因此某些参数可能会受到限制。或者，您可以创建DKIM验证配置文件，并将不同的验证配置文件分配给不同的邮件流策略。它们允许您限制您将接受的签名的密钥大小、设置密钥检索失败操作和配置DKIM验证的深度。

当消息通过多个网关时，可以多次签名，从而携带多个签名。要通过DKIM验证的消息，需要验证任何签名。默认情况下，ESA将验证最多五个签名。

由于SMTP和电子邮件的历史开放性以及整个互联网不愿适应（积极的）变化，DKIM签名可能合法地失败，例如邮件列表管理器直接转发但修改邮件，或者直接转发邮件而不是作为新邮件的附件转发邮件。因此，通常来说，对于DKIM失败的邮件，最佳做法仍然是隔离或标记，而不是丢弃它们。

准备使用DKIM签名

在RELAYED邮件流策略中启用DKIM签名之前，您需要生成/导入密钥，创建DKIM签名配置文件，并在DNS中发布公钥。

如果您是为单个域签名，则过程非常简单。生成密钥对，在邮件策略的域密钥部分创建您的单个签名配置文件，并在配置文件就绪后点击“DNS文本记录”下的“生成”选项。发布在DNS中生成的密钥。最后，在邮件流策略中打开DKIM签名。

如果您要为多个不同的域签名，则会变得更加复杂。在这种情况下，您有两个选项：

1. 使用单个签名配置文件对所有域进行签名。您将（单个）公钥存储在“主”域的DNS区域中，您的DKIM签名将引用该公钥。此技术过去常被ESP采用 — 它允许ESP大规模登录，而不必与单个客户的DNS空间进行交互[5]。
2. 为您登录的每个域创建单独的签名配置文件。这会使初始配置更加复杂，但在未来提供更大的灵活性。为每个域创建密钥对，在“配置文件用户”(Profile Users)部分创建仅指定一个域（及其子域）的配置文件，并在该特定域的DNS区域发布相关公钥。

尽管选项#1更易于开始，但请记住它最终会破坏DMARC。由于DMARC要求签名域ID与标头自对齐，因此您与DKIM的标识符对齐将失败。如果正确配置SPF，并依靠SPF标识符对齐来通过DMARC验证，则您可能可以避开它。

但是，通过从一开始实施选项#2，您无需担心DMARC，并且很容易撤销或重新配置仅针对单个域的签名服务。 此外，如果您为第三方域提供一些电子邮件服务，则最可能需要从它们获取要使用的密钥（并将其导入ESA）。 该密钥将特定于域，因此您需要创建单独的配置文件。

如果您使用第三方电子邮件服务

通常，如果您使用DKIM签名并将某些电子邮件处理（例如营销电子邮件）卸载到第三方，则您不希望他们使用您在生产中使用的相同密钥。这是DKIM中存在选择器的主要原因之一。相反，您应生成新密钥对，在DNS区域中发布公共部分，并将密钥传送给对方。这还允许您在出现故障时快速撤销该特定密钥，同时保持生产DKIM基础设施不变。

虽然DKIM（同一域的邮件可以用多个不同的密钥签名）不是必需的，但最好为第三方处理的任何邮件提供单独的子域。它将使跟踪邮件更简单，并使DMARC的实施更加简洁。例如，考虑来自汉莎航空的多封邮件的以下五个DKIM签名信头：

DKIM签名：v=1;a=rsa-sha1;c=放松/放松；s=汉莎；d=newsletter.milesandmore.com;

DKIM签名：v=1;a=rsa-sha1;c=放松/放松；s=lufthana2;d=newsletter.lufthansa.com;

DKIM签名：v=1;a=rsa-sha1;c=放松/放松；s=lufthansa3;d=lh.lhuntha.com;

DKIM签名：v=1;a=rsa-sha1;c=放松/放松；s=lufthansa4;d=e.milesandmore.com

DKIM签名：v=1;a=rsa-sha1;c=放松/放松；s=lufthansa5;d=fly-lh.lhuntha.com;  

我们可以看到，汉莎航空使用五个不同的键（选择器），这些键（选择器）分割到两个主要生产域（luftha.com和milesandmore.com）的五个独立子域。 这意味着，这些服务都可以独立控制，并且每个都可以外包给不同的消息服务提供商。

DMARC部署注意事项

DMARC接收器

ESA上的DMARC验证基于配置文件，但与DKIM不同，必须编辑默认配置文件以符合规范。ESA的默认行为是除非客户明确指示，否则绝不会丢弃任何邮件，因此默认DMARC验证配置文件将所有操作设置为“无操作”。此外，要启用正确的报告生成，您需要编辑“邮件策略”的DMARC部分的“全局设置”。

配置文件设置后，DMARC验证（与另外两个一样）将在邮件流策略的默认策略设置部分设置。确保选中此框以发送汇总反馈报告 — 这可以说是DMARC对发件人最重要的功能。在撰写本文时，ESA不支持生成每封邮件失败报告（DMARC策略的“ruf”标签）。

由于DMARC策略操作由发送方提供建议，因此与SPF或DKIM不同，在配置文件配置之外没有可配置的特定操作。无需创建任何内容过滤器。

DMARC验证将在Authentication-Results标题中添加其他字段：

身份验证结果：mx1.hc4-93.c3s2.smtpi.com;dkim=pass（经签名验证）header.i=MileagePlus@news.united.com;dmarc=pass(p=none dis=none)d=news.united.com

在上例中，我们看到DMARC是基于DKIM标识符对齐方式验证的，发件人请求策略“none”。这表示他们当前处于DMARC部署的“监控”阶段。

如果您为其他域或第三方提供电子邮件服务

ESP对DMARC合规性的最大关注点是实现正确的标识符调整。在规划DMARC时，请确保正确设置SPF，确保所有相关的其他域在您的SPF记录中都有您的传出网关，并且它们不会提交将会失败的对齐邮件，主要是通过为MAIL FROM和Header From身份使用不同的域。此错误通常由发送电子邮件通知或警告的应用程序执行，因为应用程序编写者大多不知道其电子邮件身份不一致的后果。

如前所述，请确保对每个域使用单独的DKIM签名配置文件，并且您的签名配置文件正确引用您正在为其签名的域，如Header From中所用。如果您使用自己的子域，则可以使用单个键进行签名，但请确保将您对DKIM的遵守情况设置为在DMARC策略("adkim="r")中放松。

一般来说，如果您为大量您没有直接控制权的第三方提供电子邮件服务，则最好编写一份指南文档，说明如何提交最可能发送的电子邮件。由于用户到用户电子邮件通常性能良好，因此在上述示例中，这主要是作为应用程序编写者的策略文档。

如果您使用第三方电子邮件服务

如果您使用第三方来传送某些电子邮件流量，最佳方法是将一个单独的子域（或完全不同的域）委托给第三方提供商。这样，他们可以根据需要管理SPF记录，具有单独的DKIM签名基础设施，并且不会干扰您的生产流量。然后，外包电子邮件的DMARC策略可能与内部策略不同。如前所述，在考虑第三方发送的电子邮件时，请务必确保您的标识符保持一致，并在DMARC策略中适当设置您对DKIM和SPF的遵守情况。

（子）无邮件流量的域

DMARC相对于以前的电子邮件身份验证技术的另一个改进是它如何处理子域。默认情况下，特定域的DMARC策略适用于其所有子域。在检索DMARC策略记录时，如果在FQDN级别的报头中找不到记录，则接收方必须确定发送方的组织域[6]并查找该处的策略记录。

但是，组织域的DMARC策略还可以指定单独的子域策略（DMARC记录的“sp”标记），该策略将应用于未发布明确DMARC策略的任何子域。

在前面SPF章节讨论的场景中，您将：

1. 为属于合法电子邮件源的任何子域发布显式DMARC记录。
2. 在组织域策略记录中发布“拒绝”的子域策略，以自动拒绝欺骗非发送域的任何电子邮件

这种电子邮件身份验证结构可为您的基础设施和品牌提供尽可能最好的保护。

DMARC特定问题

DMARC存在几个潜在问题，所有这些问题都源于它所依赖的其他身份验证技术的性质和缺陷。问题在于，DMARC主动推送策略来拒绝电子邮件，并将邮件中所有不同的发件人标识符关联起来，从而将这些问题暴露在外。

邮件列表和邮件列表管理软件大多出现问题。当电子邮件发送到邮件列表时，它会重新分发给所有收件人。但是，生成的包含原始发件人的发件人地址的电子邮件将由邮件列表管理器的托管基础设施传送，因此SPF无法检查“发件人”(大多数邮件列表管理器将列表地址用作“发件人”(MAIL FROM)，将原始发件人的地址用作“发件人”(Header From)。

由于SPF的DMARC将失败，我们可能依赖DKIM，但是，大多数邮件列表管理器也会在邮件中添加页脚，或用列表名称标记主题，从而中断DKIM签名验证。

DKIM的作者建议了解决该问题的几种方法，所有这些都归结于邮件列表管理器必须在所有发件人地址中使用列表的地址，并通过其他方式指示原始发件人地址。

类似的问题也源于仅通过SMTP将原始邮件转发到新收件人的邮件。但是，目前使用的大多数邮件用户代理将正确形成新邮件，并将转发的邮件内联或作为新邮件的附件。如果转发用户通过（当然，无法确定原始邮件的真实性），以这种方式转发的邮件将通过DMARC。

实施电子邮件身份验证的示例行动计划

虽然技术本身很简单，但实施完整的电子邮件身份验证基础架构的道路可能漫长而曲折。对于较小的组织和那些邮件流受控的组织而言，这将相当简单，而较大的环境可能会发现它极具挑战性。大型企业雇用咨询帮助来管理实施项目的情况并不少见。

步骤 1：DKIM

DKIM相对不干扰，因为未签名的邮件不会产生任何拒绝。在实际实施之前，请考虑前面提到的所有要点。联系您可能委托签署的任何第三方，确保您的第三方支持DKIM签署，并考虑选择器管理策略。某些组织会为不同的组织单位保留单独的键（选择器）。为了提高安全性，您可以考虑定期轮换密钥，但请确保在传输中的所有邮件都送达之前不删除旧密钥。

应特别考虑关键尺寸。虽然一般来说“更多越好”，但您必须考虑到为每个邮件创建两个数字签名（包括规范化等）是一项非常昂贵的CPU任务，并且可能影响传出邮件网关的性能。由于计算开销，2048位是可使用的最大实际密钥大小，但对于大多数部署，1024位密钥在性能和安全性之间是一个很好的折衷。

要成功实施DMARC，您应：

1. 识别您发送的所有域，包括子域
2. 生成DKIM密钥并为每个域创建签名配置文件
3. 向任何第三方提供相关私钥
4. 在相关DNS区域中发布所有公钥
5. 验证第三方是否已准备好开始签名
6. 在所有ESA上打开DKIM登录RELAYED邮件流策略
7. 通知第三方开始签名

步骤 2：SPF

正确实施SPF可能是任何电子邮件身份验证基础设施实施中最耗时和最麻烦的部分。由于电子邮件的使用和管理非常简单，而且从安全和接入点的角度完全开放，因此组织过去不会针对谁以及如何使用电子邮件实施严格的策略。这导致如今大多数组织无法全面了解所有不同的电子邮件来源，无论是来自内部还是外部。实施SPF的最大问题是发现谁当前代表您合法地发送电子邮件。

需要寻找的：

1. 显而易见的目标 — Exchange或其他组件服务器或外发邮件网关
2. 任何可能生成外部通知的DLP解决方案或其他邮件处理系统
3. CRM系统发送与客户交互的信息
4. 可能发送电子邮件的各种第三方应用
5. 实验室、测试或其他可能发送电子邮件的服务器
6. 配置为直接发送外部电子邮件的个人计算机和设备

上面的列表不完整，因为组织有不同的环境，但应将其视为查找内容的一般指南。一旦（大多数）您的电子邮件源被识别，您可能希望退一步，而不是授权每个现有源，请清理列表。理想情况下，所有传出邮件都应通过传出邮件网关发送，但有一些合理的例外。如果您拥有自己的或使用第三方营销邮件解决方案，则应使用与生产邮件网关不同的独立基础架构。如果邮件传送网络异常复杂，您可以继续在SPF中记录当前状态，但在将来需要一些时间来清理情况。

如果在同一基础设施上为多个域提供服务，则可能希望创建单个通用SPF记录，并使用“include”机制在各个域中引用该记录。确保SPF记录不太宽；例如，如果/24网络中只有五台计算机发送SMTP，请将这五个单独的IP地址添加到SPF，而不是整个网络。希望记录尽可能具体，以最大限度地降低恶意电子邮件危害您身份的可能性。

从非匹配发件人的软失败选项(“~all”)开始。 只有在您100%确定已识别所有电子邮件源后，才将其更改为硬故障(-all)，否则您可能会丢失生产电子邮件。稍后，在实施DMARC并在监控模式下运行一段时间后，您将能够识别您遗漏的任何系统并更新SPF记录以完成。只有这样，才能将SPF设置为硬故障。

步骤 3：DMARC

一旦您的DKIM和SPF设置为尽可能完整，就应该创建DMARC策略。请考虑前几章中提到的所有不同情况，并准备部署多个DMARC记录（如果您有复杂的电子邮件基础架构）。

创建将接收报告的电子邮件别名，或创建可以接收报告的Web应用。没有严格定义的电子邮件地址可用于此目的，但是，如果它们是描述性的，例如rua@domain.com、dmarc.rua@domain.com、mailauth-rua@domain.com等，则会有所帮助。确保您有一个过程，让操作员监控这些地址并适当修改SPF、DKIM和DMARC配置，或在欺骗活动发生时向安全团队发出警报。最初，当您调整记录以涵盖在SPF和DKIM配置期间可能遗漏的任何内容时，工作负载将非常巨大。一段时间后，报告可能只显示欺骗尝试。

最初，将DMARC策略设置为“none”，并将取证选项设置为发送任何失败检查的报告(“fo=1”) — 这将快速发现SPF和DKIM中的任何错误，同时不影响流量。一旦您对已提交报告的内容感到满意，请根据安全策略和首选项将策略更改为“隔离”或“拒绝”。同样，请确保操作员持续分析您收到的DMARC报告是否存在误报。

完全正确地实施DMARC并不是一项小任务或短任务。虽然某些结果（以及DMARC的正式“实施”）可能通过发布不完整的记录集和“无”策略获得，但是，每个人都能充分执行它，这符合发件人组织和整个互联网的最佳利益。

关于时间表，这里非常粗略地概述了典型项目的各个步骤。同样，由于每个组织都不同，因此这些信息远不准确：

1. DKIM规划和准备	2-4周
2. DKIM测试运行	2周
3. SPF — 合法发件人标识	2-4周
四、DMARC政策准备	2周
5. SPF和DMARC记录测试运行	4-8周
6. SPF测试运行硬故障	2周
7.使用隔离/拒绝运行DMARC测试	4周
8.监控DMARC报告并相应地调整SPF/DKIM	连续

小型组织可能会经历更短的步骤，尤其是步骤3和4。无论您认为电子邮件基础结构多么简单，在测试运行期间始终分配充足的时间，并密切监控您可能遗漏的任何内容的反馈报告。

大型组织可能会经历更长的相同步骤持续时间，并有更严格的测试要求。拥有复杂电子邮件基础架构的公司雇用外部帮助的情况并不少见，这不仅涉及电子邮件身份验证实施的技术方面，而且涉及管理整个项目以及跨团队和部门进行协调。

其他参考

• SPF的参考站点：http://www.openspf.org
• DKIM委员会：http://www.dkim.org
• 由受信任域项目运行的DMARC主网站：http://www.dmarc.org
• dmarcian — 由DMARC的作者之一Tim Draegen运营的帮助和资源网站。确保访问“工具”部分：http://www.dmarcian.com
• 在线信任联盟的记录验证工具：https://otalliance.org/resources/spf-dmarc-record-validator
• DMARC Record Assistant — 另一个帮助您创建DMARC记录的有用工具：http://www.kitterman.com/dmarc/assistant.html
• SPF记录测试工具：http://www.kitterman.com/spf/validate.html
• “别是个网瘾：Dep Dive Into Email Authentication Technoligies”（2014年Cisco Live BRKSEC-3770演示）：https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1]规范化不在本文档的范围内。有关DKIM规范化的详细信息，请参阅“其他参考”部分中的材料。

[2] DKIM DNS记录参数也不在本文档中。

[3]创建邮件过滤器不在本文档的范围内。有关帮助，请参阅AsyncOS for Email用户指南。

[4] M3AAWG定义了一套出色的最佳实践，这些最佳实践被业内大多数企业所应用和认可。他们的发件人最佳常见做法文档位于https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf

[5]此行为利用了以下事实：DKIM最初根本不验证MAIL FROM或Header From中所述的消息源。它只验证签名域ID（DKIM签名的“d”参数和签名配置文件中的“域名”参数）是否确实托管用于签名消息的对的公钥。签名“发件人”标头，表示发件人真实性。只需确保在“配置文件用户”部分列出您登录的任何和所有域（和子域）。

[6]通常，域名级别低于TLD或相关ccTLD前缀（.ac.uk、.com.sg等……）