SPF、DKIM 與 DMARC 如何防止電郵偽冒？三項機制運作全解

問題根源：電郵協定不驗證發件人

電郵傳送協定在設計之初以互通為首要目標，並未包含發件人身份驗證。結果是任何一台伺服器都可以在信封與郵件標頭上填寫任意網域，聲稱代表某間公司發信，而收件伺服器沒有內建方法判斷真偽。收件人在郵件軟件上通常只看到顯示名稱與地址，兩者都可以任意填寫。

三項驗證機制正是為補上這個缺口而先後出現，並且各自針對不同層面：SPF 處理「哪些伺服器可以代表這個網域發信」，DKIM 處理「郵件在傳送途中有否被改動、是否由持有該網域密鑰者簽發」，DMARC 則處理「驗證失敗時收件方應該怎麼做，以及如何把結果回報給網域擁有人」。三者互為補充，缺一都會留下可被利用的空隙。

SPF：核對發送伺服器是否獲授權

SPF 由 RFC 7208 定義。網域擁有人在網域名稱系統中發布一段記錄，列出獲授權代表該網域發送郵件的伺服器位址或服務。收件伺服器在接收郵件時，取得信封發件網域，查詢該網域的 SPF 記錄，再與實際連線過來的伺服器位址比對，得出通過、失敗或其他中間結果。

SPF 的優點是實作簡單、只需發布一段記錄。局限亦相當明確：它驗證的是信封層的發件網域，與收件人在郵件軟件上看到的地址並非同一個欄位，攻擊者可以令兩者不一致；同時郵件經郵寄清單或自動轉寄後，最終連線的伺服器並非原本獲授權的伺服器，驗證便會失敗。此外，SPF 記錄對查詢次數有上限，把過多服務層層引用會令記錄失效，這是實務上常見的故障原因。

DKIM：以數位簽名保證未被改動

DKIM 由 RFC 6376 定義，採用公開密鑰簽名。發送方以私鑰對郵件內容及選定的標頭欄位計算簽名，並把簽名寫入郵件標頭；公鑰則發布在網域名稱系統中。收件方取得公鑰驗證簽名，若通過即可確認兩件事：郵件確實由持有該網域私鑰的一方簽發，而且被簽署的部分在傳送途中沒有被修改。

與 SPF 相比，DKIM 的簽名附在郵件本身，因此經轉寄後通常仍然有效，這是它的主要優勢。不過 DKIM 本身只證明「有人以某個網域簽了名」，並不要求該網域與收件人看到的發件地址一致，因此攻擊者可以用自己控制的網域正確簽名，同時把顯示名稱偽裝成目標公司。這個對齊問題正是 DMARC 要解決的部分。

DMARC：對齊、政策與報告

DMARC 由 RFC 7489 定義，建立在 SPF 與 DKIM 之上，加入三項關鍵能力。第一是對齊要求：驗證通過的網域必須與收件人所見的發件網域相符，僅此一項便封住了前述兩種繞過方式。第二是政策宣告：網域擁有人可指示收件方在驗證失敗時如何處理，由僅作監察、隔離到直接拒收。第三是報告機制：收件方會把驗證結果匯總回報，令網域擁有人首次得以掌握有誰在以自己的網域名義發信。

機制	規範文件	驗證對象	經轉寄後	主要局限
SPF	RFC 7208	發送伺服器位址是否獲授權	通常失效	不涵蓋收件人所見地址，查詢次數有上限
DKIM	RFC 6376	簽名有效性與內容完整性	通常仍有效	不要求簽名網域與顯示地址一致
DMARC	RFC 7489	對齊、失敗處理政策	依賴前兩者其中之一通過	對相似網域與帳戶被盜無作用

部署次序：先看清楚，再逐步收緊

盤點所有發送來源——列出郵件伺服器、雲端郵件平台、會計與發票系統、電子報服務、客戶關係系統、網站表單、監控警報等所有會以公司網域發信的來源。
建立 SPF 記錄——把已確認的合法來源納入記錄，並留意引用其他網域會消耗查詢次數，避免層層嵌套。
為各來源啟用 DKIM 簽名——在每個支援簽名的平台生成密鑰並發布公鑰，逐一驗證簽名是否正確。
以監察政策發布 DMARC——先採用不影響投遞的監察級別，同時指定接收匯總報告的地址。
分析報告並補漏——從報告找出被遺漏的合法來源與被偽冒的情況，逐一修正記錄。
逐級收緊政策——確認合法郵件全部通過後，先收緊至隔離級別觀察，最後才進入拒收級別。
納入變更流程——新增系統或更換服務供應商時，同步檢視驗證記錄，避免日後突然斷發。

常見錯誤與誤解

① 一次跳到拒收

未經監察期便直接宣告拒收，遺漏的代發系統會即時斷發，發票與通知郵件全部消失，影響往往在數天後才被察覺。

② 發布多段 SPF 記錄

同一網域出現多段獨立的 SPF 記錄會令驗證結果無效，所有授權來源必須合併在同一段記錄內。

③ 忽略子網域

只保護主網域，攻擊者便可能改用未受保護的子網域發信，政策設定時需一併考慮子網域的處理方式。

④ 報告無人查看

只發布記錄卻沒有人分析回報，等於放棄了 DMARC 最有價值的部分，偽冒活動與配置遺漏都無法及時發現。

⑤ 以為可防所有詐騙

驗證機制只針對網域偽冒，對相似網域與真實帳戶被盜無效，仍需配合認證強化與流程覆核。

⑥ 密鑰長期不更換

DKIM 密鑰應納入定期更換安排，並在更換期間保留舊公鑰一段時間，避免已發出的郵件驗證失敗。

香港場景：貿易與物流業的付款指示詐騙

香港以貿易、物流與專業服務為主，日常業務高度依賴電郵確認訂單、報價與付款資料，這正是商業電郵詐騙最常見的目標場景。典型手法是攻擊者長期監看往來郵件，待付款階段介入，以極相似的網域或被盜帳戶發出更改收款戶口的指示；由於內容、稱謂與往來脈絡都完全吻合，單憑肉眼極難分辨。若使用被盜的真實帳戶發信，SPF、DKIM 與 DMARC 全部會顯示通過，技術驗證在這種情況下並不能提供保護。

因此實務建議是技術與流程並行。技術方面，先完成三項機制的部署並持續檢視報告，同時為所有郵箱啟用多重認證，減少帳戶被盜的機會；流程方面，訂立任何付款戶口變更必須以電話向既有聯絡人覆核的規則，並禁止僅憑郵件內附的聯絡電話進行核對。中小企亦應留意，香港企業經常同時使用本地郵件服務與雲端平台，兩邊的發送來源都必須納入同一份 SPF 與 DKIM 清單，這是本地環境下最常出現的遺漏。

帳戶層面的配套措施可一併參考企業密碼管理器的推行方式，以及員工入職離職的 IT 帳戶流程，兩者同樣影響電郵帳戶被盜用的風險。

權威資料依據

本文核對資料：RFC 7208（Sender Policy Framework, SPF）；RFC 6376（DomainKeys Identified Mail, DKIM）；RFC 7489（Domain-based Message Authentication, Reporting, and Conformance, DMARC）；Wikipedia：Business email compromise。

常見問題

三項機制是否只需部署其中一項？

三者解決的問題不同，單獨使用都有缺口。SPF 按 RFC 7208 核對發送伺服器的 IP 是否獲網域授權，但郵件經轉寄後發送伺服器改變，驗證便會失敗；DKIM 按 RFC 6376 以數位簽名驗證郵件內容與指定標頭未被改動，可經轉寄仍然有效，但無法阻止攻擊者用自己的網域簽名再偽冒顯示名稱。DMARC 按 RFC 7489 把兩者與收件人所見的發件網域對齊，並定義驗證失敗時的處理方式與報告機制。完整防護需要三項並行。

為何部署後正常郵件反而被退回或進入垃圾郵件？

最常見原因是遺漏了代發服務。企業的郵件往往不只由郵件伺服器發出，還包括會計系統的發票通知、電子報平台、客戶關係系統、監控警報與網站表單，這些來源若未列入 SPF 記錄或未設定 DKIM 簽名，在收緊 DMARC 政策後便會被拒收。正確做法是先以監察模式收集報告，確認所有合法來源都通過驗證，然後才逐步收緊政策。

部署了 DMARC 是否就不會再收到偽冒郵件？

不會完全消除。DMARC 保護的是以本身網域作為發件網域的偽冒，對於使用相似網域、免費郵箱配上相同顯示名稱，或直接盜用真實帳戶發信的攻擊並無作用。商業電郵詐騙的典型手法正是先取得一個真實帳戶的存取權，再從該帳戶發出更改付款指示的郵件，此時所有驗證都會通過。因此電郵驗證需要配合多重認證、付款流程覆核與員工警覺性訓練。

政策應該由哪一級開始，何時可以收緊？

建議由僅監察不處理的政策開始，讓收件方繼續正常投遞但回報驗證結果。收集報告一段時間、確認所有合法發送來源都已涵蓋後，可先收緊至隔離級別觀察影響，最後才進入拒收級別。每次收緊之後都應繼續檢視報告，因為企業新增系統或更換服務供應商時，發送來源會再次變動。

香港中小企最應優先處理哪一環？

先把發送來源清單整理清楚，這是後續一切工作的基礎。香港不少中小企的郵件同時經本地服務供應商、雲端郵件平台與會計或物流系統發出，卻沒有人完整掌握清單，導致 SPF 記錄長期不完整。清單完成後再依序設定 DKIM 簽名與 DMARC 監察政策。由於香港的貿易與物流企業經常以電郵確認訂單與付款資料，屬商業電郵詐騙的高風險行業，同步建立付款指示更改必須另行電話覆核的內部規則，實際效果往往比單純的技術措施更明顯。

需要部署電郵驗證或處理偽冒問題？

我們可協助檢視現有 SPF、DKIM 與 DMARC 記錄、整理所有代發服務、由監察模式逐步收緊政策，並建立報告分析流程，減少偽冒同時避免正常郵件被誤擋。

WhatsApp 免費報價 →

SPF、DKIM與DMARC如何防止電郵偽冒？