電子郵件驗證最佳作法 - 部署 SPF、DKIM 和DMARC 的絕佳方法

簡介

本指南說明當前使用的三種主要電子郵件驗證技術 – SPF、DKIM 和 DMARC，並探討三者實作的不同層面。其中將探討多個實際電子郵件架構情況，並提供適用於在 Cisco Email Security 產品組合中實作這些驗證的指南。由於此為實作最佳作法指南，因此部分較複雜的資料將會省略。必要時，特定概念可能會經過簡化或濃縮，以便理解所述的內容。

產品知識需求

本指南為進階文件。為徹底瞭解所述的資料內容，讀者應具備 Cisco Secure Email Appliance 的產品知識，達到 Cisco Secure Email 現場工程師認證的程度。此外，讀者應充分掌握 DNS 與 SMTP 及其運作方式。熟悉 SPF、DKIM 及 DMARC 的基礎知識尤佳。

電子郵件驗證 – 簡短概觀

寄件者原則架構 (SPF)

寄件者原則架構 (SPF) 首次於 2006 年發佈，文件編號為 RFC4408。目前版本係於 RFC7208 中指定並於 RFC7372 中更新。基本上，SPF 為網域擁有者提供簡單方式，可將其合法的電子郵件來源通告至使用 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       text = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"

為有效減少所需之 DNS 查詢的數量，Delta 已建立單一「A」記錄，其中列出所有的 SMTP 閘道。他們亦在「_spf.vendor.delta.com」中為其廠商提供個別的 SPF 記錄。他們也加入指示，以便將所有未經 SPF 驗證的郵件（「-all」限定詞）視為封鎖性失敗。我們可進一步查詢廠商的 SPF 記錄：

_spf.vendor.delta.com  text = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all"

因此，寄件者 @delta.com 的電子郵件可以合法方式來自 Air France（舉例）的電子郵件閘道。

另一方面，United 會使用較為簡易的 SPF 方案：

united.com     text = "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.71.93 ip4:74.209.251.0/24 mx ~all"

除自家企業郵件閘道外，他們亦納入其電子郵件行銷供應商（「usa.net」和「enviaremails.com.br」）、舊版 Continental Air Lines 閘道，以及 MX 記錄中所列的所有閘道（「MX」機制）。請注意，MX（網域的內送郵件閘道）可能不會與外寄郵件閘道相同。雖然對於中小企業而言，兩者可能會相同，但大型企業可能會有個別的基礎架構處理內送郵件，以及個別的基礎架構處理外寄傳遞。

此外，值得注意的是，以上所有範例均廣泛使用其他 DNS 轉介（「包含」機制）。但是，由於效能原因，SPF 規範會將擷取最終記錄需要之 DNS 查詢的總數限制為十。任何超過 10 個 DNS 遞迴層級的 SPF 查詢將會失敗。

網域金鑰識別郵件 (DKIM)

RFC 5585、RFC 6376 及 RFC 5863 指定的 DKIM 為兩個歷史提案的合併：Yahoo 的 DomainKeys 和思科的 Identified Internet Mail。DKIM 可為寄件者提供簡易方式，以加密方式簽署外寄郵件，並在電子郵件標頭（「DKIM-Signature」）中加入簽章（與其他驗證中繼資料）。寄件者會在 DNS 中發佈公開金鑰，讓任何收件者得以輕鬆擷取金鑰並驗證簽章。DKIM 不會驗證實際郵件的來源，而是憑藉以下方式：如果郵件來源擁有寄件者組織的私密金鑰，則會取得隱含授權代表他們傳送電子郵件。

若要實作 DKIM，傳送組織會產生一或多個公開金鑰配對，並會在 DNS 中發佈該公開金鑰作為 TXT 記錄。每個金鑰配對會受到「選取器」參照，使 DKIM 驗證者可區別金鑰。外寄郵件會獲得簽署，並且會插入 DKIM-Signature 標頭：

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; 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+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYqT01rEwL0V8MEY1MzxTrzijkLPGqt/sK1WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=

簽章的格式相當簡單明瞭。「a」標籤表示用於簽署的演算法、「c」表示使用的標準化方案 [1]、「s」為選取器或金鑰參照、「d」為簽署網域。此 DKIM-Signature 標頭的其餘部分為郵件專用：「h」會列出簽署的標頭、「i」會列出簽署使用者的身分識別；最後，標頭會以兩個獨立雜湊結尾：「bh」為簽署標頭的雜湊，而「b」為郵件內文的雜湊值。

接收到 DKIM 簽署郵件後，收件者將會透過建構下列 DNS 查詢，來查詢公開金鑰：

<selector>._domainkey.<signing domain>

（如 DKIM-Signature 標頭中所指定）。如為上述範例，我們的查詢可能會是「united._domainkey.news.united.com」：

united._domainkey.news.united.com  text = "g=*\; k=rsa\; n=" "Contact" "postmaster@responsys.com" "with" "any" "questions" "concerning" "this" "signing" "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35hO4v6dTy5Qmxcuv5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB2IBwIDAQAB\;"

傳回的 DNS 記錄會包含金鑰，以及其他選用參數。[2]

DKIM 的主要問題為初始規範不允許通告寄件者使用 DKIM。因此，如果郵件是在未使用簽章的情況下傳入，收件者將難以知道其是否應已經簽署，且在此情況下，該郵件很可能不會是真的。由於單一組織可（且大多通常會）使用多個選取器，因此「猜測」網域是否已啟用 DKIM 並非易事。為解決此問題，相關人員開發出個別標準「作者網域簽署最佳作法」，但由於使用率低和其他問題於 2013 年淘汰，且無後續版本。

網域型郵件驗證、報告和一致性 (DMARC)

DMARC 為本文介紹之三項電子郵件驗證技術中的最新技術，是專為解決 SPF 和 DKIM 的缺點而開發的技術。與其他兩者不同之處在於，此技術會驗證郵件的「標頭來源」，並連結至其他兩者先前執行的檢查項目。DMARC 是在 RFC7489 中指定。

相較於 SPF 和 DKIM，DMARC 的附加值包括：

• 確保所有可用的身分識別（HELO、MAIL FROM 及/或 DKIM 簽署網域）符合（完全符合或隸屬於）「寄件者標頭」。
• 為寄件者網域擁有者提供方法，使其可針對收件者必須如何處理失敗郵件部分指定原則。
• 為寄件者網域擁有者提供意見回饋設施，使其可接收任何失敗郵件的通知，從而輕鬆識別網路釣魚活動或 SPF/DKIM/DMARC 原則指派中的錯誤。

DMARC 亦會使用簡易的 DNS 型原則發佈機制：

_dmarc.aa.com     text = "v=DMARC1\; p=none\; 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（使用 POST 方法的 mailto: 或 http:// URL）以傳送有關所有聲稱來自特定網域之失敗郵件的每日彙總報告。「ruf」會指定 URL 以提交有關每個失敗郵件的即時詳細失敗報告。

根據規範，收件者必須遵循通告原則。如未遵循該原則，則他們必須以彙總報告通知寄件者網域擁有者。

DMARC 的核心概念即所謂的識別碼對照。識別碼對照會定義郵件可通過 DMARC 驗證的方法。SPF 和 DKIM 識別碼會採用個別方式對照，且郵件必須通過任一識別碼才可整體通過 DMARC。然而，即使其中一個對照通過，但另一個對照失敗，DMARC 原則選項仍可讓寄件者請求產生失敗報告。我們可在以上範例中發現此情形，其中「fo」標籤設定為「1」。

以下提供適用於郵件的兩種遵循 DKIM 或 SPF 識別碼對照的方法：嚴格和寬鬆。嚴格遵循表示「標頭來源」的 FQDN 必須完全符合 DKIM 簽章的「簽署網域 ID」（「d」標籤）或 SPF 之 MAIL FROM SMTP 命令的 FQDN。另一方面，寬鬆遵循可讓「標頭來源」FQDN 成為前述兩者的子網域。   委派電子郵件流量至第三方時，此遵循方法將具有重要影響，詳情稍後將會在本文件中探討。

SPF 部署注意事項

適用於收件者的 SPF

在 Cisco Email Security Appliance 或 Cloud Email Security 虛擬設備中設定 SPF 驗證相當簡單。在本文件的剩餘內容中，任何提及 ESA 的部分亦會包含 CES。

SPF 驗證會在「郵件流程原則」中設定，最簡單的全域執行方式為在適當之接聽程式的「預設原則參數」區段中開啟。如果您正在針對內送和外寄郵件收集使用相同的接聽程式，請確保「RELAYED」郵件流程原則的 SPF 驗證已設為「關閉」。

由於 SPF 不允許採取原則動作規範，因此 SPF 驗證（與稍後將探討的 DKIM）僅會驗證郵件，並針對每個執行的 SPF 檢查插入一組標頭：

Received-SPF: Pass（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: None（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

請注意此郵件，兩個「identity」皆經過 SPF 驗證：規範要求的「mailfrom」，以及規範同樣建議的「helo」。由於僅前者與 SPF 法規遵循相關，因此該郵件將會正式通過 SPF，但部分收件者亦可能會批准未包含其 HELO 身分識別的 SPF 記錄。因此，將外寄郵件閘道的主機名稱納入 SPF 記錄可說是良好的作法。

當「郵件流程原則」驗證郵件後，即可由本機管理員設定可採用的動作。本機管理員可設定使用「郵件篩選器」規則 SPF-status() [3]；或透過建立「內送內容篩選器」使用相同規則，並將其套用至適當的「內送郵件原則」。

圖 1：SPF 驗證內容篩選器條件

建議的篩選器動作為捨棄「失敗」（SPF 記錄中的「-all」）的郵件，以及隔離「原則隔離」中非封鎖性失敗（SPF 記錄中的「~all」）的郵件；不過，根據您的安全性需求，其中可能有所差異。部分收件者僅會標示失敗郵件，或不採取明顯動作，但向管理員報告。

近期 SPF 的熱門程度已大幅遽增，但許多網域仍會發佈不完整或不正確的 SPF 記錄。為安全起見，您可能希望隔離所有 SPF 失敗郵件，並暫時監控隔離區，以確保其中沒有任何「誤報」。

如果您提供適用於其他網域或第三方的電子郵件服務

如果您為第三方提供電子郵件傳遞或託管服務，他們將需要新增您用於將郵件傳遞至其 SPF 記錄的主機名稱和 IP 位址。最簡單的達成方法即讓供應商建立「umbrella」SPF 記錄，並要求客戶在其 SPF 記錄中使用「包含」機制。

suncountry.com    text = "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.exacttarget.com ~all"

如您所見，Sun Country 自行控制其部分電子郵件，但其行銷電子郵件者則外包給第三方處理。展開參考的記錄即會顯示其行銷郵件服務供應商目前使用的 IP 位址清單。

cust-spf.exacttarget.com      text = " 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 descriptive text "v=spf1 include:_spf.qualtrics.com ?all

JetBlue 會使用 Qualtrics 分析服務，而他們唯一需要做的，就是納入 Qualtrics 的正確 SPF 記錄。同樣地，大部分的其他 ESP 會提供 SPF 記錄，以納入其客戶的記錄。

如果 ESP 或電子郵件行銷人員未提供 SPF 記錄，您將需要直接在自己的記錄中列出其外寄郵件閘道。但是，您必須負責確保此類記錄正確，且如果供應商新增其他閘道或變更 IP 位址或主機名稱，可能會危及您的郵件流程。

未具備 SPF 意識之第三方的其他風險來自於共用資源：如果 ESP 使用相同 IP 位址傳遞多個客戶的電子郵件，則就技術上來說，其中一位客戶有可能會產生 SPF 有效的郵件，假冒其他客戶透過相同的介面進行傳遞。因此，在設定任何 SPF 限制前，您應調查 MSP 的安全性原則，以及其電子郵件驗證意識。如果客戶無法回答您的問題，考慮到SPF是網際網路上最基本的信任機制之一，強烈建議您重新考慮您對MSP的選擇。這不僅僅關乎安全性- SPF、DKIM、DMARC和MSP使用的其他發件人最佳做法[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」標頭：

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 運用 – 如此可讓他們以大規模方式進行簽署，而非需要與個別客戶的 DNS 空間互動 [5]。
2. 為您簽署的個別網域建立個別簽署設定檔。如此會使得初始組態變得更加複雜，但未來會提供您更多彈性。為個別網域建立金鑰配對、在「設定檔使用者」區段建立指定單一網域（與其子網域）的設定檔，以及在該特定網域的 DNS 區域發佈相關的公開金鑰。

雖然第 1 個選項是較容易開始使用的方法，但請記住，此方法最後可能會破壞 DMARC。由於 DMARC 會要求簽署網域 ID 符合標頭來源，因此您的識別碼與 DKIM 的對照將會失敗。如果您正確設定 SPF，或許可以避免此問題，並且仰賴 SPF 識別碼對照通過 DMARC 驗證。

但是，若從開始即實作第 2 個選項，則無須擔憂 DMARC 問題，且可非常容易撤銷或重新設定單一網域的簽署服務。 此外，如果您為第三方網域提供部分電子郵件服務，非常可能需要從其中取得可使用的金鑰（並將其匯入您的 ESA）。由於該金鑰為網域專用，因此您將需要建立個別設定檔。

如果您使用第三方電子郵件服務

一般來說，如果您使用 DKIM 簽署，並將部分電子郵件處理（例如，行銷電子郵件）交給第三方負責，則您必然不會希望他們使用您在生產期間所使用的相同金鑰。這就是 DKIM 中存在選取器的主要原因之一。反之，您應該產生新的金鑰配對、在 DNS 區域中發佈公開部份，並將秘密金鑰提供給對方。如此亦可讓您在發生問題時快速撤銷該特定金鑰，同時確保您的生產 DKIM 基礎架構不受影響。

雖然此動作對於 DKIM 並非必要（相同網域的郵件可使用多個不同金鑰簽署），但針對任何由第三方處理的電子郵件提供個別子網域乃是良好的作法。此作法可讓您更輕鬆追蹤郵件，並可讓您在日後實現更簡潔的 DMARC 實作。作為範例，我們透過 Lufthansa 多個郵件的五個 DKIM-Signature 標頭進行思考：

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa; d=newsletter.milesandmore.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com

DKIM-Signature：v=1；a=rsa-sha1；c=放鬆/放鬆；s=漢莎航空5；d=fly-lh.lufthansa.com；  

我們可以發現 Lufthansa 會使用五個不同的金鑰（選取器），分散用於兩個主要生產網域（lufthansa.com 和 milesandmore.com）的五個獨立子網域。如此表示，每個金鑰皆可獨立控制，且均可外包給不同的訊息服務供應商。

DMARC 部署注意事項

適用於收件者的 DMARC

ESA 的 DMARC 驗證係以設定檔為基礎，但與 DKIM 的不同之處在於，您必須編輯預設設定檔，才可使其符合規範。ESA 的預設行為係永不捨棄任何郵件（除非客戶明確指示），因此預設的 DMARC 驗證設定檔會將所有動作設定為「無動作」。此外，若要啟用正確的報告產生功能，您將需要編輯「郵件原則」之 DMARC 區段的「全域設定」。

完成設定檔配置後，郵件流程原則的「預設原則設定」區段中亦已設定 DMARC 驗證（如同其他兩者）。請務必核取方塊，以傳送彙總意見回饋報告 – 對寄件者而言，這正是最重要的 DMARC 功能。寫入時，ESA 不支援產生每封郵件的失敗報告（DMARC 原則的「ruf」標籤）。

由於 DMARC 原則動作係由寄件者所建議，因此與 SPF 或 DKIM 不同之處在於，設定檔組態外部沒有可設定的特定動作。您不需要建立任何內容篩選器。

DMARC 驗證會將其他欄位新增至 Authentication-Results 標頭：

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 識別碼對照完成驗證，且寄件者請求原則為「無」。如此表示，兩者目前皆處於 DMARC 部署的「監控」階段。

如果您提供適用於其他網域或第三方的電子郵件服務

ESP 對於 DMARC 法規遵循方面的最大疑慮，在於達成正確的識別碼對照。規劃 DMARC 時，請確保您已正確設定 SPF ，使所有其他相關網域在您的 SPF 記錄中皆具有外寄閘道，且未提交任何會使對照失敗（主要針對 MAIL FROM 和標頭來源身分識別使用不同的網域）的郵件。此錯誤通常是由傳送通知或警告的應用程式造成，因為應用程式作者多半不會意識到電子郵件身分識別不一致所導致的後果。

如前所述，請務必針對每個網域使用不同的 DKIM 簽署設定檔，並確保您的簽署設定檔已正確參照您要簽署的網域（如同標頭來源中所使用的一般）。如果要使用自己的子網域，您可以使用單一金鑰進行簽署，但請確保在 DMARC 原則中，將 DKIM 遵循設定為寬鬆 ("adkim="r")。

一般來說，如果您要為更多的第三方（您對其沒有直接控制權）提供電子郵件服務，針對如何提交最有可能傳遞的電子郵件，編寫指南文件是個良好的作法。由於使用者對使用者的電子郵件通常表現正常，因此該文件通常係作為上述範例中之應用程式作者專用的原則文件。

如果您使用第三方電子郵件服務

如果您使用第三方傳遞部分電子郵件流量，則理想方式係將獨立子網域（或完全不同的網域）委派給第三方供應商。如此他們可在必要時管理 SPF 記錄、擁有獨立 DKIM 簽署基礎架構，且不會干擾您的生產流量。此外，外包電子郵件的 DMARC 原則可能會與內部電子郵件不同。如前所述，若考慮使用第三方傳遞電子郵件，請務必確認您的識別碼保持一致，且 DMARC 原則中的 DKIM 和 SPF 遵循皆已正確設定。

無電子郵件流量的（子）網域

其他針對先前電子郵件驗證技術的 DMARC 改善為處理子網域的方式。依預設，特定網域的 DMARC 原則適用於所有其子網域。擷取 DMARC 原則記錄時，如果您無法在標頭來源 FQDN 層級找到任何記錄，則收件者必須判斷寄件者的組織網域 [6]，並查看其中的原則記錄。

但是，組織網域的 DMARC 原則亦可指定適用於任何子網域（未發佈明確的 DMARC 原則）的獨立子網域原則（DMARC 記錄的「sp」標籤）。

在先前 SPF 章節中探討的情境中，您將：

1. 針對屬於合法電子郵件來源的任何子網域，發佈明確的 DMARC 記錄。
2. 在組織網域原則記錄中，發佈「reject」的子網域原則，以自動拒絕假冒非傳送網域的任何電子郵件。

此類建構電子郵件驗證的方式，可為您的基礎架構和品牌提供最佳的保護。

DMARC 特有的問題

DMARC 具有多項潛在問題，皆來自於其所仰賴之其他驗證技術的性質和缺點。問題在於，DMARC 已曾透過主動推播原則拒絕所有電子郵件，以及將郵件中所有不同的寄件者識別碼進行關聯，來揭露此類問題。

大多數問題皆發生於郵件清單與郵件清單管理軟體。當電子郵件傳送至郵件清單後，會重新分配給所有其收件者。但是，使用原始寄件者之地址產生的電子郵件，將透過郵件清單管理工具的託管基礎架構傳遞，因此無法通過標頭來源的 SPF 檢查（大部分的郵件清單管理工具會使用清單位址作為信封來源 (MAIL FROM)，以及使用原始寄件者的地址作為標頭來源）。

由於 DMARC 會無法通過 SPF 檢查，因此我們可能會仰賴 DKIM，但大多數郵件清單管理工具也會將頁尾新增至郵件，或使用清單名稱標記主旨，以致於破壞 DKIM 簽章驗證。

DKIM 作者已針對該問題提出多項解決方案建議，所有解決方案均歸結郵件清單管理工具必須使用所有寄件者地址中的清單位址，以及透過其他方法指出原始寄件者地址。

類似問題會發生於僅透過經由 SMTP 將原始郵件複製到新收件者所轉寄的郵件。但是，現今大多數使用中的郵件使用者代理程式，將會以正確方式編寫新的郵件，然後以內嵌或作為附件方式將轉寄郵件納入新郵件。如果轉寄使用者通過，則以此方式轉寄的郵件將會通過 DMARC 驗證（當然，原始郵件的真實性無法確定）。

實作電子郵件驗證的範例行動計畫

雖然技術本身相當簡單，但實作完整電子郵件驗證基礎架構的過程可能相當漫長而曲折。對於小型組織和使用受控郵件流程的組織，實作完整的電子郵件驗證基礎架構相當簡單，而對於大型環境而言可能會發現其極具挑戰性。對於大型企業而言，聘請顧問協助管理實作專案的情況相當常見。

步驟 1：DKIM

由於未簽署郵件不會遭到任何拒絕，因此 DKIM 相對不具侵擾性。在實際實作之前，請將前述的所有重點列入考量。請聯絡您可能委派簽署的任何第三方、確保您的第三方支援 DKIM 簽署，並考量您的選取器管理策略。部分組織可能會為不同組織單位保存不同金鑰（選取器）。您可能需要考量定期輪換金鑰獲得額外安全性 – 但在所有傳輸中的郵件完成傳遞前，請勿刪除舊金鑰。

您應特別考量金鑰大小。雖然一般來說「數大便是美」，但您必須考量到按每封郵件（包括標準化等）建立兩個數位簽章是相當耗費 CPU 使用量的工作，且可能影響外寄郵件閘道的效能。由於運算負荷的緣故，2048 位元為可使用的最大實用金鑰大小，但對於大部分部署而言，1024 位元金鑰則在效能和安全性之間取得良好的平衡。

為成功進行 DMARC 的後續實作，您應該：

1. 識別您所傳送的所有網域（包括子網域）
2. 針對每個網域產生 DKIM 金鑰並建立簽署設定檔
3. 向任何第三方提供相關私密金鑰
4. 在相關的 DNS 區域中發佈所有公開金鑰
5. 確認第三方已準備好開始簽署
6. 針對所有 ESA，在 RELAYED 郵件流程原則中開啟 DKIM 簽署功能
7. 通知第三方開始簽署

步驟 2：SPF

正確實作 SPF 可能是任何電子郵件驗證基礎架構實作方面，最耗費時間與繁瑣的部分。由於電子郵件非常容易使用和管理，且從安全性和存取觀點來看完全具有開放性，因此許多組織過去未曾針對使用的對象和方式強制執行嚴格的原則。導致如今大部分的組織無法全面瞭解來自內部和外部之各種不同的電子郵件來源。實作 SPF 最大的一個問題，在於要探索目前正代表您合法傳送電子郵件的對象。

要尋找的對象：

1. 明顯目標 ─ Exchange 或其他群體軟體伺服器或外寄郵件閘道
2. 可能會產生外部通知的任何 DLP 解決方案或其他電子郵件處理系統
3. 傳送資訊與客戶互動的 CRM 系統
4. 會傳送電子郵件的不同第三方應用程式
5. 會傳送電子郵件的實驗伺服器、測試伺服器或其他伺服器
6. 經設定可直接傳送外部電子郵件的個人電腦和裝置

由於許多組織具有不同環境，因此以上清單並不完整，但應視為關於要尋找之對象的一般指南。當您的（大多數）電子郵件來源經識別後，您可能會希望退後一步，與其授權每一個現有的來源，不如清理清單。理想上來說，所有外寄電子郵件皆應透過外寄郵件閘道傳遞，但有一些合理的例外。如果您具有自己的閘道，或使用第三方行銷郵件解決方案，則應使用獨立的基礎架構，而非生產電子郵件閘道。如果您的郵件傳遞網路極其複雜，您可以持續在 SPF 中記錄目前的狀況，但在未來確實需要時間來清理這種情況。

如果您透過相同的基礎架構提供多個網域，可會希望建立單一通用 SPF 記錄，並且使用「包含」機制在個別網域中參照。確保您的 SPF 記錄不會過於廣泛；舉例來說，如果 /24 網路中僅有五台電腦傳送 SMTP，請將這五個獨立 IP 位址新增至您的 SPF，而非整個網路。目的在於使您的記錄儘可能明確，以有效降低惡意電子郵件盜用您身分識別的任何機會。

從不符合之寄件者（「~all」）的非封鎖性失敗選項開始。只有在您非常確定已識別出全部的電子郵件來源時，才可將其變更為封鎖性失敗 (-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 原則設定為「無」與鑑識選項，以傳送任何失敗之檢查的報告（「fo=1」）– 如此將可快速探索 SPF 和 DKIM 中的任何錯誤，而不會影響流量。當您對於提交的報告內容感到滿意後，請根據您的安全性原則和偏好設定，將原則變更為「quarantine」或「reject」。此外，確保您具有操作員可持續分析收到的 DMARC 報告，尋找是否有任何誤報。

完整和正確實作 DMARC 絕非小型工作或簡短工作。雖然部分結果（與 DMARC 的正式「實作」）可透過發佈不完整的記錄集和「none」原則取得，但為了寄件組織和網際網路雙方整體的利益，所有人都要進行實作以充分發揮其功能。

有關時間軸部分，以下為適用於典型專案之極粗略的個別步驟大綱。此外，由於每個組織都有所差異，因此這些步驟並非完全準確：

1. DKIM計畫和準備	2 至 4 週
2. DKIM測試運行	2 周
3. SPF -合法的發件人標識	2 至 4 週
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
• Trusted Domain Project 經營的 DMARC 主要網站：http://www.dmarc.org
• dmarcian – DMARC 的其中一位作者 Tim Draegen 經營的說明和資源網站。請務必造訪「工具」區段：http://www.dmarcian.com
• Online Trust Alliance 的 Record Validator 工具：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
• 2014 年思科現場簡報 BRKSEC-3770「Don’t Be A Phish: Deep Dive Into Email Authentication Techniques」（別成為網路釣魚的受害者：深入探索電子郵件驗證技術）：https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1] 標準化超出本文件討論的範圍。如需有關 DKIM 標準化的進一步資訊，請參閱「其他參考資料」一節。

[2] DKIM DNS 記錄參數亦超出本文件討論的範圍。

[3] 建立郵件篩選器超出本文件討論的範圍。如需協助，請參閱 AsyncOS for Email 使用者指南。

[4] M3AAWG 定義的卓越最佳作法集，受到大多數產業的應用與認可。該組織所發佈的「Sender Best Common Practices」（常見寄件者最佳作法）文件連結如下：https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf

[5] 此行為利用原本 DKIM 完全不會驗證 MAIL FROM 或標頭來源中所述的郵件來源。該行為僅會驗證簽署網域 ID（DKIM 簽章的「d」參數和簽署設定檔中的「Domain Name」參數是否確實託管用於簽署郵件之配對的公開金鑰。寄件者的確實性係透過完成簽署「寄件者」標頭作為表示。請確保您已在「設定檔使用者」區段列出簽署的任何及所有網域（與子網域）。

[6] 通常為 TLD 或相關 ccTLD 首碼之下的第一層網域（.ac.uk、.com.sg 等）