跳至主要內容
ITD網站資安平台
ITD
搜尋

名詞解釋

#郵件認證#SPF#DMARC

SPF / DKIM / DMARC 是什麼：保護你的網域免遭冒名郵件的三項 DNS 設定

SPF、DKIM、DMARC 是三項 DNS 設定，讓收件方能夠驗證以你的網域發出的郵件是否「真實」。沒有它們，冒用你名義的釣魚郵件就無法被攔截。本文用圖解說明三者各自的作用，並給出安全的設定步驟（DMARC 從 p=none 開始），通俗易懂。

發布於 2026-06-08 更新於 2026-10-06 閱讀時間 4 分鐘
本頁內容

釣魚郵件可能在你不知情時以你網域的名義發出。能阻止這件事的，正是 SPF / DKIM / DMARC。本文通俗講解三者的作用與安全的設定步驟。

三者的作用

設定作用（一句話）
SPF用 DNS 聲明「允許傳送本網域郵件的伺服器就是這些」
DKIM給郵件加上電子簽章，證明「傳輸途中未被竄改、來自正規寄件源」
DMARC聲明 SPF/DKIM 失敗時如何處理的原則，並接收報告（把三者結合起來的設定）

三者都是 DNS 中的文字（TXT）記錄。以 example.com 為例，大致如下（值為範例）。

設定放在哪裡值的範例
SPFexample.comv=spf1 include:_spf.mail-service.example ~all
DKIMselector._domainkey.example.comv=DKIM1; k=rsa; p=(寄信服務發給你的公鑰)
DMARC_dmarc.example.comv=DMARC1; p=none; rua=mailto:dmarc@example.com

SPF 的 include: 請使用郵件寄送服務指定的值。DKIM 的公鑰也由寄信服務發出，不需要自己產生。

是如何被驗證的（原理）

收件方（Gmail 等）會對收到的郵件檢查 SPF 與 DKIM，再把結果對照 DMARC 的原則，決定「放行／隔離／拒絕」。

收到的郵件（以你的網域名義）
↓ 收件方驗證
SPF：寄件伺服器是否已許可？
DKIM：簽章是否正確？有無竄改？
↓ 將結果對照 DMARC 原則
DMARC：若失敗則 放行 / 隔離(quarantine) / 拒絕(reject)
收件方確認 SPF/DKIM，並按 DMARC 原則做最終判斷。三者都要具備才能生效。

也就是說，僅有 SPF 和 DKIM 時往往是「做了判定卻什麼都不做」，只有配上 DMARC 的原則，「攔截冒充」的效力才會真正顯現。

容易被忽略的部分：網域對齊

DMARC 判定的關鍵在於網域是否一致。只有當收件人在郵件 App 中看到的寄件者網域（From 標頭），與 SPF 或 DKIM 驗證過的網域一致時，DMARC 才會通過。

SPF 檢查的不是看得到的寄件者，而是投遞時在背後使用的信封寄件者的網域。所以攻擊者可以用自己的網域通過 SPF，同時只在 From 欄位寫上你的網域。如果 SPF 通過但與 From 網域不一致，DKIM 也沒有提供一致的網域，DMARC 就會判定該郵件失敗。正是對這種一致性的檢查，讓 DMARC 能阻止 From 位址的冒充。

安全的設定步驟

1

SPF 只設一條且正確

把用於寄信的正規伺服器（自有、郵件投遞服務等）無遺漏地全部許可。SPF 記錄在一個網域上彙總為一條（多條容易失效）。

2

啟用 DKIM 簽章

在所使用的郵件傳送平台上啟用 DKIM，並把公鑰登記到 DNS，使正規郵件帶上簽章。

3

DMARC 從 p=none 開始

不要一上來就拒絕。先用 p=none（僅監控）＋接收報告，確認正規郵件是否會被誤攔。

4

逐步加嚴

透過報告補齊正規投遞的遺漏後，再從 p=quarantine → p=reject。最終實現「冒充一律拒絕」。

步驟 1 的「只設一條」來自規格。RFC 7208 規定，若一個網域有多條 SPF 記錄，結果為 permerror（永久錯誤）。同一規格也把 include 等造成的 DNS 查詢限制在整個評估過程中最多 10 次；超過同樣是 permerror。新增郵件服務時，請在既有的那一條記錄上追加，而不是再新增一條。

常見的錯誤

錯誤會發生什麼修正
兩條 SPF 記錄SPF 回傳 permerror合併成一條
巢狀的 include 太多DNS 查詢超過 10 次 → permerror移除未使用服務的 include
寄信服務沒有啟用 DKIM來自該服務的郵件在 DMARC 失敗在服務中啟用 DKIM 並發布到 DNS
DMARC 一直停在 p=none冒充郵件持續送達查看報告並提升到 reject
不寄信的網域什麼都沒設無法阻止以這個閒置網域名義的冒充發布 v=spf1 -all 與 DMARC p=reject

如何檢查自己的網域

  1. 把網域輸入 SPF / DKIM / DMARC 檢查工具，確認三條記錄是否存在、有什麼問題
  2. 想從命令列直接查看，可執行 dig +short TXT example.com（SPF）與 dig +short TXT _dmarc.example.com（DMARC）
  3. 從自己的網域寄一封信到 Gmail 地址，用 Gmail 的「顯示原始郵件」確認 SPF、DKIM、DMARC 都是 PASS
  4. DMARC 報告（rua）開始寄來之後，每週檢查有沒有不認得的寄件來源

對已確認所有權的網站，網站安全健檢會連同 Web 端的設定一起檢查這些項目。

實際案例：「從自己的地址」寄來的冒充郵件

「收到一封從自己的地址寄給自己的恐嚇郵件」是日本 IPA 等機構多次提醒的典型案例。這些多數不是帳號被盜，只是寄件者欄位被改寫了。因為寄件者欄位可以寫任何內容，對 DMARC 尚未提升到 reject 的網域，這類郵件可能送進收件匣。如何分辨與如何處理，請見：

規格更新（2026 年 5 月）

DMARC 在 2026 年 5 月修訂為 RFC 9989，取代了先前的 RFC 7489。三種原則——p=none、p=quarantine、p=reject——沒有改變。改變的是：移除了 pct 標籤（套用的比例），改以表示測試模式的 t 標籤取代，並新增了針對不存在之子網域原則的 np 標籤。既有的記錄不會一夕之間失效，但撰寫新記錄時請不要使用 pct。

本站視角：你守護的也是「你的使用者」

SPF/DKIM/DMARC 不只是為了讓自己的郵件能送達，也是保護你的使用者免遭冒用你網域的釣魚的機制。釣魚說到底就是竊取認證憑證或金鑰的手段。現實中，許多網域只停留在 SPF/DKIM，並未把 DMARC 提升到強制(reject)。不要滿足於 p=none，要查看報告、逐步把原則一路加嚴到 reject，才能真正見效。

出處（一手資料）

  • IETF RFC 7208, "Sender Policy Framework (SPF)" — datatracker.ietf.org（每個網域一條記錄；DNS 查詢最多 10 次）
  • IETF RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures" — datatracker.ietf.org
  • IETF RFC 9989, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)"（2026 年 5 月；取代 RFC 7489）— datatracker.ietf.org
  • Google, "Email sender guidelines" — support.google.com（2024 年 2 月 1 日起的要求；每天 5,000 封以上寄件者的要求）

接下來閱讀

分類編號

CWE 對造成漏洞的弱點類型進行分類，MITRE ATT&CK 對攻擊者的技術進行分類。兩者皆由 MITRE 維護，廣泛用於標註漏洞資訊與偵測規則。

ATT&CK（攻擊技術）

© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ATT&CK Terms of Use

FAQ

QSPF / DKIM / DMARC 是為了什麼？
A

為了讓收件方（Gmail 等）能夠驗證以你的網域發出的郵件是否「真實」。沒有它們，第三方就能冒用你名義傳送冒充郵件（釣魚），且無法被攔截，網域的信譽也會受損。

Q三者有什麼區別？
A

SPF 聲明「允許傳送本網域郵件的伺服器」，DKIM 是「證明未被竄改的電子簽章」，DMARC 則是「當 SPF/DKIM 失敗時如何處理的原則＋接收報告」。DMARC 綜合 SPF/DKIM 的結果，讓它們能被實際執行。

Q設定時要注意什麼？
A

先把正規投遞（郵件投遞服務等）無遺漏地全部許可後，再加嚴。尤其是 DMARC，如果一上來就設為拒絕(p=reject)，可能連正規郵件也被攔截，因此應先用 p=none（僅監控）查看報告，再按 p=quarantine→p=reject 逐步提升。

QDMARC 的 p=none 是什麼意思？
A

它要求收件方對認證失敗的郵件不做特別處理。它無法阻止冒充，但你會收到報告（rua），看到誰在以你網域的名義寄信。確認所有正規寄件來源後，再提升到 p=quarantine（垃圾郵件匣），接著到 p=reject（拒收）。

QSPF 的「-all」和「~all」有什麼不同？
A

兩者都放在 SPF 記錄的結尾，表示如何處理未列出之伺服器寄來的郵件。-all 表示「未被授權」（fail）；~all 表示「大概未被授權」（softfail）。在已設定 DMARC 的情況下，最終處理由 DMARC 原則決定，所以在確認所有正規寄件來源之前先用 ~all 也沒關係。

QSPF 的「10 次 DNS 查詢上限」是什麼？
A

SPF 規格（RFC 7208）把 include、a、mx、ptr、exists 與 redirect 修飾詞造成的 DNS 查詢，限制在整個評估過程中最多 10 次。超過時結果為 permerror（永久錯誤），SPF 會被視為失敗。用 include 列出多個郵件服務時很容易超過；請移除已不再使用之服務的 include。

QGmail 要求 SPF、DKIM 與 DMARC 嗎？
A

自 2024 年 2 月 1 日起，Google 要求所有寄信給個人 Gmail 帳號的寄件者設定 SPF 或 DKIM。每天寄送 5,000 封以上的寄件者，必須同時設定 SPF 與 DKIM、DMARC（p=none 原則也可以），並讓 From 網域與 SPF 或 DKIM 的網域一致（對齊）。