SPF、DKIM、DMARC 是什麼？企業郵件防偽冒設定與檢查方法

SPF、DKIM、DMARC 是什麼？企業郵件防偽冒設定與檢查方法

2026/10/29 資訊安全 9 次瀏覽 閱讀約 8 分鐘

SPF、DKIM、DMARC 是三種寫在 DNS 的郵件驗證機制：SPF 列出哪些伺服器可以代表公司網域寄信，DKIM 用數位簽章證明信件來自網域且未被竄改，DMARC 則告訴收件端驗證失敗時要放行、隔離還是拒收，並把結果回報給網域擁有者。三者一起設定，才能有效阻止別人冒用公司網域寄信。

很多中小企業是在客戶收到「公司寄來的匯款通知」後，才發現網域早被冒用。這篇以 Google Workspace 與 Microsoft 365 為例，說明三筆紀錄怎麼設、DMARC 怎麼從觀察模式逐步收緊，以及怎麼自行檢查。網域防護之外，員工能不能辨認冒名郵件同樣重要，這部分可以透過 社交工程演練服務 實際量測。

為什麼公司網域會被冒用？

公司網域會被冒用，是因為電子郵件協定原本不會驗證寄件者：任何人都能把寄件人欄位寫成 finance@貴公司網域，只要收件端沒有檢查，這封信就會出現在客戶的收件匣。攻擊者最常用這招冒充財務或主管，要求客戶改匯款帳號，也就是 BEC 詐騙 的典型手法。

Gmail 已把郵件驗證列為寄件門檻。Google 的寄件者規範要求，自 2024 年 2 月 1 日起，所有寄信到 Gmail 的寄件者至少要設定 SPF 或 DKIM；每天寄送超過 5,000 封的大量寄件者，則必須同時設定 SPF、DKIM 與 DMARC，且寄件人網域要與 SPF 或 DKIM 的網域對齊。未通過驗證的信可能被標為垃圾郵件，或直接被拒收。

沒有完成 SPF DKIM DMARC 設定的公司有兩個損失：網域可被任意冒用，自己的正常郵件也更容易進垃圾信匣。

SPF 是什麼？列出誰可以代表你寄信

SPF（Sender Policy Framework）是一筆 DNS TXT 紀錄，列出被授權代表網域寄信的伺服器或服務；收件端收到信時，會比對寄信來源是否在名單上。規格定義在 RFC 7208。

一筆 SPF 紀錄長這樣：v=spf1 include:spf.protection.outlook.com -all。include 代表授權某個服務，結尾的 -all 表示名單外一律失敗，~all 表示名單外標記為可疑。Google 建議 Workspace 網域使用 ~all；Microsoft 則建議 Microsoft 365 網域搭配 DKIM 與 DMARC 時使用 -all。

SPF 最常出錯的兩件事：一個網域只能有一筆 SPF 紀錄，多一筆就會讓驗證直接失敗；SPF 的 DNS 查詢次數上限是 10 次，電子報、CRM、客服系統一家一家加進去，很容易超過。Microsoft 建議把第三方寄信服務改用子網域，讓主網域的紀錄保持簡單。

SPF DKIM DMARC 三種郵件驗證示意圖，寄信來源名單、數位簽章與處置政策
名單、簽章、處置規則各司其職

DKIM 是什麼？用簽章證明信沒有被改過

DKIM（DomainKeys Identified Mail）由寄信伺服器用私鑰在每封信加上數位簽章，收件端再用公布在 DNS 的公鑰驗證，確認信件確實由該網域授權寄出，內容在傳送途中沒有被竄改。規格定義在 RFC 6376。

和 SPF 相比，DKIM 的優點是信件被轉寄後通常仍能通過驗證。金鑰長度方面，Google 要求至少 1024 位元，並建議在 DNS 業者支援時使用 2048 位元。

DMARC 是什麼？決定驗證失敗時怎麼處理

DMARC（Domain-based Message Authentication, Reporting, and Conformance）是發布在 _dmarc.貴公司網域 的 TXT 紀錄，要求寄件人網域必須與 SPF 或 DKIM 的網域對齊，並指定失敗時的處置：p=none 只觀察、p=quarantine 放進垃圾信匣、p=reject 直接拒收。它也讓收件端每天寄回彙總報告，讓您看到誰在用公司網域寄信。

2026 年 5 月，IETF 以 RFC 9989、9990 與 9991 取代 2015 年的 RFC 7489，DMARC 從資訊性文件升為標準追蹤文件。紀錄仍以 v=DMARC1 開頭，現有設定不必重寫；但原本用來逐步收緊的 pct 標籤已被移除，改由 t=y 表示測試中，收件端會套用比指定政策低一級的處置。

Google Workspace 與 Microsoft 365 設定步驟

兩大平台的設定順序相同：先設 SPF，再啟用 DKIM，最後發布 DMARC。順序不能反過來，否則 DMARC 一上線，正常的信也可能被拒收。下表是三筆紀錄的設定與檢查清單：

紀錄主機名稱Google WorkspaceMicrosoft 365設定後要確認
SPF（TXT）網域本身（@）v=spf1 include:_spf.google.com ~allv=spf1 include:spf.protection.outlook.com -all只有一筆、已含所有第三方寄信服務、DNS 查詢不超過 10 次
DKIMGoogle：google._domainkey（TXT）；Microsoft：selector1._domainkey、selector2._domainkey（CNAME）管理控制台「應用程式 > Google Workspace > Gmail > 驗證電子郵件」產生金鑰，加到 DNS 後按「開始驗證」在 Microsoft Defender 入口網站的電子郵件驗證設定啟用，依畫面提供的兩筆 CNAME 加到 DNS寄一封測試信，檢查信件標頭 dkim=pass
DMARC（TXT）_dmarcv=DMARC1; p=none; rua=mailto:dmarc@貴公司網域同左開始收到彙總報告、主網域與子網域政策正確

沒有用來寄信的閒置網域也要設定，SPF 寫成 v=spf1 -all，DMARC 直接設 p=reject，避免被拿去冒用。

DMARC 從 none 到 reject，要怎麼分階段導入？

DMARC 不要一次設成 reject，應該先觀察、再隔離、最後拒收，每一階段都根據報告確認合法的寄信來源已全部通過驗證。實務上常需一到數個月，視第三方寄信服務多寡而定。

  1. 觀察期：設定 p=none 並開啟 rua 報告，至少觀察數週，列出所有用公司網域寄信的服務，例如電子報、CRM、電子發票、招募系統。
  2. 修補期：把報告中合法但驗證失敗的來源補進 SPF，或請服務商啟用 DKIM 簽章。
  3. 隔離期：改為 p=quarantine，可先搭配 t=y 測試；持續看報告，確認沒有正常信件被誤判。
  4. 拒收期：改為 p=reject，之後每季檢查一次報告，新增寄信服務時先完成驗證再上線。

我們在協助客戶導入時最常遇到的卡關點，是業務或行銷部門自行申請的寄信工具，IT 並不知道它存在。觀察期的報告往往就是第一次完整盤點這些服務的機會。

DMARC 導入階段示意圖，從 none 觀察、quarantine 隔離到 reject 拒收
先觀察，再隔離，最後拒收

怎麼檢查 SPF DKIM DMARC 設定是否正確？

SPF DKIM DMARC 設定完成後，最直接的檢查方式有三種：用 DNS 查詢工具確認三筆紀錄存在且語法正確、寄一封信到外部信箱並查看信件標頭的驗證結果，以及定期閱讀 DMARC 彙總報告。Google 提供免費的 Admin Toolbox 可以檢查網域的 DNS 紀錄。

在 Gmail 收到的信中，點「顯示原始郵件」就能看到 SPF、DKIM、DMARC 是 PASS 或 FAIL；任何一項 FAIL，就回到上面的清單逐項比對。DMARC 報告是 XML 檔，重點看三件事：有沒有不認識的寄信來源、合法來源是否都通過、失敗量有沒有突然增加。

閱讀 DMARC 彙總報告示意圖，IT 人員分辨合法與可疑的寄信來源
報告會告訴你誰在冒用網域

設好三筆紀錄之後，還要做什麼？

DNS 紀錄只能擋住「冒用你網域」的信，擋不住長得很像的假網域，例如把字母 l 換成數字 1；也擋不住員工信箱密碼被盜後寄出的信。下一步是讓員工習慣核對網域與回撥確認付款變更，並了解常見的 社交工程 手法。

如果想確認公司網域的三筆紀錄是否完整、DMARC 該怎麼排導入時程，可以 從一場 30 分鐘的諮詢開始。

SPF、DKIM、DMARC 常見問題

SPF、DKIM、DMARC 三個都要設定嗎？

要。SPF 與 DKIM 各自只驗證一部分，DMARC 則負責要求網域對齊並決定失敗時的處置，少了 DMARC，冒名信即使驗證失敗，收件端也可能照樣收下。Google 對每天寄送超過 5,000 封到 Gmail 的寄件者，已明訂三者都必須設定。一般企業即使寄信量不大，也建議三者一次到位。

設定 DMARC 會讓信寄不出去嗎？

p=none 只收集報告，不影響投遞；會造成正常信件被擋的是在還沒確認所有寄信來源前，就直接設成 quarantine 或 reject。依觀察、修補、隔離、拒收的順序推進，並在每個階段檢查報告，就能避免誤擋。新增電子報或 CRM 等寄信工具時，也要先完成 SPF 與 DKIM 再開始寄送。

怎麼看 DMARC 報告？

DMARC 彙總報告由各大信箱業者每天寄到 rua 指定的信箱，內容是 XML 格式，列出寄信來源 IP、寄出數量，以及 SPF、DKIM 與對齊的結果。看報告時先找出不認識的來源，再確認合法服務是否都通過；報告量大時，可以使用 DMARC 報告分析服務轉成圖表。

參考資料

  1. RFC 7208：Sender Policy Framework (SPF) – SPF 規格與 10 次 DNS 查詢上限。IETF · 2014 年 4 月
  2. RFC 6376：DomainKeys Identified Mail (DKIM) Signatures – DKIM 規格。IETF · 2011 年 9 月
  3. RFC 9989：Domain-Based Message Authentication, Reporting, and Conformance (DMARC) – 取代 RFC 7489，移除 pct 標籤。IETF · 2026 年 5 月
  4. Email sender guidelines – Gmail 寄件者驗證要求。Google
  5. Set up SPF for your Microsoft 365 domain – SPF 紀錄範例與查詢次數限制。Microsoft Learn

相關文章

查看更多