為什麼 SPF、DKIM 與 DMARC 缺一不可
SPF、DKIM 與 DMARC 是三種 DNS 記錄，讓其他郵件系統能確認來自您網域的電子郵件確實出自您。每一種都補足另外兩種留下的缺口，因此一個網域需要三者齊備。
與工程師談談 知識庫
為什麼這對企業很重要
電子郵件本身沒有內建的寄件者查核機制。沒有這些記錄，任何人都能把您的網域填進 From 欄位，於是假發票可能看起來像是來自您的會計團隊。
反過來的情況也會發生。大型服務商不信任未經驗證的郵件，因此正常的回信會被歸入垃圾郵件。自 2024 年起，Google 與 Yahoo 已要求大量寄件者進行驗證。
各自的作用
- SPF：列出獲准代表您網域寄信的伺服器。
- DKIM：為每封郵件簽章，證明由哪個網域簽署，以及郵件在途中沒有被更動。
- DMARC：檢查 SPF 或 DKIM 是否針對 From 地址中的網域通過，在兩者皆未通過時告訴收件方該如何處理，並寄報告給您。
單靠任何一種都不夠。SPF 與 DKIM 可能是針對讀者所見網域以外的網域而通過，而且兩者都不會要求收件方封鎖任何東西。DMARC 需要其中一種正常運作，而 SPF 在轉寄的郵件上會失敗，因此 DKIM 是備援。
| 記錄 | 檢查內容 | 存放位置 | 做不到的事 |
|---|---|---|---|
| SPF | 寄件伺服器在您的清單上 | 網域上的一筆 TXT 記錄 | 保護 From 地址，或在轉寄後仍然有效 |
| DKIM | 郵件未被更動，以及由誰簽署 | 每個寄件服務在各自選擇器下各有一筆記錄 | 說明對未簽章或已損毀的郵件該怎麼做 |
| DMARC | SPF 或 DKIM 與 From 網域相符 | 位於 _dmarc 的一筆 TXT 記錄 | 在沒有 SPF 或 DKIM 的情況下運作 |
常見錯誤
- 兩筆 SPF 記錄：為新服務另外加了第二筆記錄，會讓您所有郵件的 SPF 都失敗。
- 沒人加入的寄件者：行銷平台或開立發票的系統以您的網域名義寄信，卻從未取得 SPF 項目或 DKIM 金鑰。
- DMARC 永遠停在 none：政策從不調整，偽造的郵件仍然會被投遞。
- 直接跳到 reject：在閱讀報告之前就強制執行，會把您自己的郵件連同偽造郵件一起擋掉。
設定的順序
- 列出每個寄件者：您的郵件服務商，以及每個以您網域名義寄信的服務。
- 發布一筆 SPF 記錄，涵蓋所有寄件者。
- 在每個寄件服務中啟用 DKIM。
- 以 none 發布 DMARC並附上報告地址，然後閱讀報告。
- 待報告中只剩下您自己的服務後，改為 quarantine，再改為 reject。
這三者都放在您的 DNS 中。其餘的設定請見我們的企業電子郵件指南。
KawaConnect 如何處理電子郵件驗證
當我們設定、遷移或管理 Microsoft 365 時，SPF、DKIM 與 DMARC 記錄是工作的一部分，與負責郵件路由的 MX 記錄一併處理。對於我們代管的網站，會寄信的聯絡表單也會一併加入同樣的記錄。
相關服務
瞭解更多
- 維基百科上的電子郵件驗證用於驗證電子郵件來源的各種方法概述。
- Cloudflare 上的 DMARC、DKIM 與 SPF三種記錄的逐步說明。
- dmarc.org 上的 DMARC 概述來自該標準官方網站，說明 DMARC 如何建立在 SPF 與 DKIM 之上。
- Google 電子郵件寄件者指南Gmail 對寄件者所期待的驗證。
- Microsoft 365 中的電子郵件驗證Microsoft 針對 Microsoft 365 說明這三者的指南。
