本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 遵守 Amazon SES 中的 DMARC 身份驗證協議
<a name="send-email-authentication-dmarc"></a>

以網域為基礎的訊息身分驗證、報告和一致性 (DMARC) 是一種電子郵件身分驗證通訊協定，使用寄件者政策架構 (SPF) 和 DomainKeys 識別郵件 (DKIM) 來偵測電子郵件詐騙和網路釣魚。為了符合 DMARC，訊息必須透過 SPF 或 DKIM 進行驗證，但理想情況下，當兩者都與 DMARC 搭配使用時，您將確保電子郵件傳送盡可能獲得最高層級的保護。

讓我們簡單地檢閱每個 執行哪些操作，以及 DMARC 如何將它們串連在一起：
+  **SPF** – 識別允許哪些郵件伺服器透過 DNS TXT 使用的 DNS TXT 記錄，代表您自訂的「寄件人」網域傳送郵件。收件人郵件系統參考 SPF TXT 記錄，以判斷來自自訂網域的訊息是否來自授權的訊息伺服器。基本上，SPF 旨在協助防止詐騙，但有一些詐騙技巧在實務上容易受到 SPF 影響，因此您還需要使用 DKIM 和 DMARC。
+  **DKIM** – 將數位簽章新增至電子郵件標頭中的傳出訊息。接收電子郵件系統可以使用此數位簽章來協助驗證傳入電子郵件是否由網域擁有的金鑰簽署。不過，當接收電子郵件系統轉送訊息時，訊息的信封會以使 SPF 身分驗證失效的方式變更。由於數位簽章會保留電子郵件訊息，因為它是電子郵件標頭的一部分，因此即使訊息已在郵件伺服器之間轉送 （只要訊息內容尚未修改），DKIM 仍會運作。
+  **DMARC** – 確保網域與至少一個 SPF 和 DKIM 一致。單獨使用 SPF 和 DKIM 不會確保寄件者地址已驗證 （這是收件人在其電子郵件用戶端中看到的電子郵件地址）。SPF 只會檢查「寄件人」地址中指定的網域 （收件人看不到）。DKIM 只會檢查 DKIM 簽章中指定的網域 （收件者也不會看到）。DMARC 透過要求 SPF 或 DKIM 上的網域對齊正確來解決這兩個問題：
  + 若要讓 SPF 傳遞 DMARC 對齊，寄件人地址中的網域必須與「寄件人」地址中的網域相符 （也稱為「傳回路徑」和「信封」地址）。這在轉送的郵件中很少可行，因為它會被剔除，或透過第三方大量電子郵件供應商傳送電子郵件時，因為退信路徑 (MAIL FROM) 用於供應商 (SES) 使用他們擁有的地址追蹤的退信和投訴。
  + 若要讓 DKIM 傳遞 DMARC 對齊，DKIM 簽章中指定的網域必須與寄件人地址中的網域相符。如果您使用代您傳送郵件的第三方寄件者或服務，這可以透過確保第三方寄件者已正確設定 DKIM 簽署，且您已在網域中新增適當的 DNS 記錄來完成。然後，接收郵件伺服器將能夠驗證第三方傳送給他們的電子郵件，就好像是由獲授權使用網域內地址的人員所傳送的電子郵件一樣。

**全部與 DMARC 整合**  
我們上述討論的 DMARC 對齊檢查顯示 SPF、DKIM 和 DMARC 如何一起運作，以提高對網域的信任，並將您的電子郵件交付至收件匣。DMARC 透過確保收件人看到的寄件者地址通過 SPF 或 DKIM 驗證來完成此操作：
+ 如果其中一個或兩個所描述的 SPF 或 DKIM 檢查通過，則訊息會傳遞 DMARC。
+ 如果所述的 SPF 或 DKIM 檢查都失敗，則訊息會失敗 DMARC。

因此，對於 DMARC 而言，SPF 和 DKIM 都是必要的，才能有最佳機會為您的已傳送電子郵件進行身分驗證，而透過利用這三種方法，您將協助確保您擁有完全受保護的傳送網域。

DMARC 也可讓您指示電子郵件伺服器在透過您設定的政策進行 DMARC 身分驗證失敗時，如何處理電子郵件。這將在下一節中說明，[對您的網域設定 DMARC 政策](#send-email-authentication-dmarc-dns)其中包含如何設定 SES 網域的相關資訊，以便您傳送的電子郵件同時透過 SPF 和 DKIM 遵守 DMARC 身分驗證通訊協定。

## 對您的網域設定 DMARC 政策
<a name="send-email-authentication-dmarc-dns"></a>

若要設定 DMARC，您必須修改您網域的 DNS 設定。您網域的 DNS 設定應該包含指定網域 DMARC 設定的 TXT 記錄。將 TXT 記錄新增到您 DNS 組態的程序取決於您使用的 DNS 或託管提供者。如果您使用 Route 53，請參閱 *Amazon Route 53 開發人員指南*中的[使用記錄](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)。如果使用其他提供者，請參閱您提供者的 DNS 組態文件。

您建立的 TXT 記錄名稱應該是 `_dmarc.example.com`，其中 `example.com` 為您的網域。TXT 記錄的值包含套用到您網域的 DMARC 政策。以下為包含 DMARC 政策的 TXT 記錄範例：


| 名稱 | 類型 | Value | 
| --- | --- | --- | 
| \$1dmarc.example.com | TXT | "v=DMARC1;p=quarantine;rua=mailto:my\$1dmarc\$1report@example.com" | 

在上述 DMARC 政策範例中，此政策會指示電子郵件供應商執行下列動作：
+ 對於身分驗證失敗的任何訊息，請將其傳送到政策參數 指定的垃圾郵件資料夾`p=quarantine`。其他選項包括使用 不採取任何動作`p=none`，或使用 直接拒絕訊息`p=reject`。
  + 下一節討論如何使用和何時使用這三個政策設定 - *在錯誤的時間使用錯誤的政策設定可能會導致您的電子郵件無法交付，*請參閱 [實作 DMARC 的最佳實務](#send-email-authentication-dmarc-implement)。
+ 依報告參數 (*rua* 代表報告彙總報告的 URI) 所指定，傳送摘要中身分驗證失敗的所有電子郵件報告 `rua=mailto:my_dmarc_report@example.com`（亦即彙總特定期間內資料的報告，而不是傳送每個事件的個別報告）。電子郵件提供者通常每天會傳送一次這些彙總報告，但這些政策因提供者而異。

若要進一步了解為您的網域設定 DMARC，請參閱 DMARC 網站的 [概觀](https://dmarc.org/overview/)。

如需 DMARC 系統的完整規格，請參閱[網際網路工程任務小組 (IETF) DMARC 草稿](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/)。

## 實作 DMARC 的最佳實務
<a name="send-email-authentication-dmarc-implement"></a>

最好以漸進和分階段的方式實作 DMARC 政策強制執行，以免中斷郵件流程的其餘部分。建立並實作遵循這些步驟的推展計劃。請先使用每個子網域執行這些步驟，最後使用組織中的最上層網域，再繼續進行下一個步驟。

1. 監控實作 DMARC 的影響 (p=無）。
   + 從子網域或網域的簡單監控模式記錄開始，該記錄會請求郵件接收組織將他們使用該網域看到的訊息統計資料傳送給您。監控模式記錄是 DMARC TXT 記錄，其政策設為無 `p=none`。
   + 透過 DMARC 產生的報告將提供通過這些檢查的訊息數量和來源，而不是未通過這些檢查的訊息。您可以輕鬆查看它們涵蓋或未涵蓋多少合法流量。您將會看到轉送的跡象，因為如果修改內容，轉送的訊息將會失敗 SPF 和 DKIM。您也會開始看到有多少詐騙訊息正在傳送，以及它們的傳送來源。
   +  此步驟的目標是了解當您實作以下兩個步驟之一時，哪些電子郵件會受到影響，並讓任何第三方或授權寄件者使其 SPF 或 DKIM 政策保持一致。
   + 最適合現有網域。

1. 請求外部郵件系統隔離未通過 DMARC 的郵件 (p=隔離）。
   + 當您認為所有或大部分的合法流量傳送的網域都與 SPF 或 DKIM 一致，而且您了解實作 DMARC 的影響時，您可以實作隔離政策。隔離政策是 DMARC TXT 記錄，其政策設定為隔離 `p=quarantine`。透過這樣做，您要求 DMARC 接收者將失敗 DMARC 的網域訊息放入垃圾郵件資料夾的本機對等資料夾中，而不是客戶的收件匣。
   + 最適合在步驟 1 期間轉換已分析 DMARC 報告的網域。

1. 請求外部郵件系統不接受失敗 DMARC (p=reject) 的訊息。
   + 實作拒絕政策通常是最後一個步驟。拒絕政策是 DMARC TXT 記錄，其政策設定為拒絕 `p=reject`。當您這樣做時，您要求 DMARC 接收者不要接受未通過 DMARC 檢查的訊息，這表示他們甚至不會被隔離到垃圾郵件或垃圾郵件資料夾，但將被直接拒絕。
   + 使用拒絕政策時，您會確切知道哪些訊息未通過 DMARC 政策，因為拒絕會導致 SMTP 退信。透過隔離，彙總資料會提供電子郵件傳遞或失敗 SPF、DKIM 和 DMARC 檢查百分比的相關資訊。
   + 最適合經過前兩個步驟的新網域或現有網域。

## 透過 SPF 來遵循 DMARC
<a name="send-email-authentication-dmarc-spf"></a>

若要讓電子郵件遵循以 SPF 為基礎的 DMARC 驗證，需符合下列條件：
+ 訊息必須根據要發佈至自訂「寄件人」網域 DNS 組態的有效 SPF （類型 TXT) 記錄，傳遞 SPF 檢查。
+ 電子郵件標頭的寄件者地址中的網域必須與 MAIL FROM 地址中指定的網域或子網域對齊 （符合）。為了讓 SPF 與 SES 保持一致，網域的 DMARC 政策不得指定嚴格的 SPF 政策 (aspf=s)。

為了符合這些要求，請完成以下步驟：
+ 完成 [使用自訂「寄件人」網域](mail-from.md) 中的步驟以設定自訂的「寄件人」網域。
+ 請確任您的傳送網域對 SPF 採取寬鬆政策。如果您尚未變更網域的政策對齊，預設會使用寬鬆政策，SES 也是如此。
**注意**  
若要判定網域對於 SPF 採取的 DMARC 符合度，可於命令列輸入下列命令，以 `example.com` 取代您的網域：  

  ```
  dig TXT _dmarc.example.com
  ```
在此命令輸出檔的 **Non-authoritative answer (非授權答案)** 下，尋找以 `v=DMARC1` 開頭的記錄。若此記錄包含 `aspf=r` 字串，或如果 `aspf` 字串完全未顯示，那麼您的網域就是對於 SPF 採取寬鬆的符合度。若記錄包含 `aspf=s` 字串，那麼您的網域就是對於 SPF 採取嚴格的符合度。您的系統管理員將需自網域中 DNS 組態的 DMARC TXT 記錄移除此標籤。  
或者，您可以使用 Web 型 DMARC 查詢工具，例如來自 dmarcian 網站的 [DMARC Inspector](https://dmarcian.com/dmarc-inspector/)，或來自 MxToolBox 網站的 [DMARC Check Tool](https://mxtoolbox.com/dmarc.aspx)，來判斷您網域的 SPF 政策一致性。

## 透過 DKIM 來遵循 DMARC
<a name="send-email-authentication-dmarc-dkim"></a>

若要讓電子郵件遵循以 DKIM 為基礎的 DMARC 驗證，需符合下列條件：
+ 訊息必須具有有效的 DKIM 簽章，並通過 DKIM 檢查。
+ DKIM 簽章中指定的網域必須與寄件者地址中的網域對齊 （相符）。如果網域的 DMARC 政策指定 DKIM 的嚴格一致性，這些網域必須完全相符 (SES 預設使用嚴格的 DKIM 政策）。

為了符合這些要求，請完成以下步驟：
+ 請完成 [Amazon SES 中的 Easy DKIM](send-email-authentication-dkim-easy.md) 中的程序以設定 Easy DKIM。使用 Easy DKIM 時，Amazon SES 自動簽署電子郵件。
**注意**  
除了使用 Easy DKIM 外，您也可以[手動簽署郵件](send-email-authentication-dkim-manual.md)。不過，若您選擇採取此方法，則必須謹慎處理，因為 Amazon SES 不會驗證您所建構的 DKIM 簽章。因此，我們強烈建議您使用 Easy DKIM。
+ 確保 DKIM 簽章中指定的網域與寄件者地址中的網域對齊。或者，如果從寄件者地址中的網域子網域傳送，請確定您的 DMARC 政策設定為寬鬆對齊。
**注意**  
若要判定網域對於 DKIM 採取的 DMARC 符合度，可於命令列輸入下列命令，以 `example.com` 取代您的網域：  

  ```
  dig TXT _dmarc.example.com
  ```
在此命令輸出檔的 **Non-authoritative answer (非授權答案)** 下，尋找以 `v=DMARC1` 開頭的記錄。若此記錄包含 `adkim=r` 字串，或如果 `adkim` 字串完全未顯示，那麼您的網域就是對於 DKIM 採取寬鬆的符合度。若記錄包含 `adkim=s` 字串，那麼您的網域就是對於 DKIM 採取嚴格的符合度。您的系統管理員將需自網域中 DNS 組態的 DMARC TXT 記錄移除此標籤。  
或者，您可以使用 Web 型 DMARC 查詢工具，例如來自 dmarcian 網站的 [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) 或來自 MxToolBox 網站的 [DMARC Check Tool](https://mxtoolbox.com/dmarc.aspx)，來判斷網域的 DKIM 政策一致性。