郵箱安全入門：SPF / DKIM / DMARC 是什麼（2026）
一句話結論：SPF 查發信伺服器是否在名單上，DKIM 驗郵件簽名是否完好，DMARC 把前兩者的結果與發件人域名對齊並決定處置；三者都靠 DNS 記錄釋出，收緊要按 none、quarantine、reject 的順序來。
三者分工：各查一件事
發件人域名在 DNS 釋出三類記錄，收信方按記錄檢查。SPF 回答“這臺伺服器有沒有資格替這個域名發信”，DKIM 回答“郵件是否發信方簽過且未被改過”，DMARC 回答“結果與發件人域名是否一致，不一致時怎麼處置”。DMARC 本身不認證，建立在 SPF 與 DKIM 的結果之上。
| 機制 | 查什麼 | 記錄位置 |
|---|---|---|
| SPF | 發信伺服器的 IP 是否在授權名單上 | 域名根部的 TXT 記錄，只能有一條 |
| DKIM | 簽名能否驗過、內容是否被改過 | 選擇器加 _domainkey 子域的 TXT 記錄 |
| DMARC | SPF/DKIM 是否透過且對齊；失敗時如何處置 | _dmarc 子域的 TXT 記錄 |
SPF：發信伺服器名單，查的是信封發件人
SPF 是一條 TXT 記錄，列出哪些伺服器可以替這個域名發信，收信方比對發信伺服器 IP 與名單。查的是信封發件人（SMTP 的 MAIL FROM，即退信地址），不是收件人看到的發件人地址，兩者可以不同，這正是 DMARC 要補的缺口。語法示例（須按自家發信服務填寫，不可照抄）：v=spf1 include:_spf.google.com ~all，意思是授權 Google 發信、其餘按軟失敗處理，只適用於僅用 Google Workspace 發信的情形。記錄以 v=spf1 開頭，~all 表示軟失敗，-all 表示硬失敗。一個域名只能有一條 SPF 記錄，多條會讓郵件服務無法正常工作；有其他服務時，把授權合併進同一條。
SPF 有一條硬上限：按 RFC 7208 第 4.6.4 節，單次檢查中觸發 DNS 查詢的項最多 10 次，超過就返回永久錯誤（PermError），收信方按失敗處理。計入上限的是 include、a、mx、ptr、exists 與 redirect，每項計 1 次，巢狀查詢也計入；不計入的是 ip4、ip6 與 all。每加一個發信服務，先數查詢次數再發布。Google 幫助頁稱最多 10 個 include 標籤，協議原文算的是查詢次數（含巢狀），以協議原文為準。
DKIM：簽名驗真偽，選擇器定位公鑰
DKIM 用一對金鑰工作：私鑰儲存在發信伺服器上，給每封發出的郵件加簽名；公鑰釋出在 DNS 的 TXT 記錄裡，收信方取公鑰驗證。簽名覆蓋郵件頭與正文摘要，驗證透過說明確由持私鑰一方發出且未被改過；改動簽名覆蓋的內容，驗證就失敗。選擇器（selector）用來定位公鑰：多把金鑰各對應一個選擇器，公鑰記錄掛在“選擇器._domainkey”子域下。Google Workspace 的預設選擇器是 google，記錄形如 google._domainkey；Cloudflare 轉發服務的選擇器以 cf2024-1 開頭（複用域名郵箱實操文章口徑）。收信方從 DKIM-Signature 頭讀出選擇器與簽名域名（d= 標籤），再取公鑰驗證；換金鑰用新選擇器發新公鑰，舊記錄保留一段時間再刪。DKIM 只證明簽名有效，域名關係留給 DMARC 對齊檢查。
DMARC：對齊與處置，收緊要按順序
DMARC 記錄掛在 _dmarc 子域，以 v=DMARC1 開頭，p 標籤寫策略。Google 幫助頁（核查 2026-11-13）定義三檔策略：none 只觀察，不改變投遞，把結果記入每日報告；quarantine 把未透過的郵件標記為垃圾郵件，送入垃圾資料夾；reject 拒收郵件，收信伺服器通常會向發信伺服器發退信通知。策略是建議，最終處置由收信方決定。
| 策略 | 未透過時的處置 | 在收緊順序裡的位置 |
|---|---|---|
| p=none | 照常投遞，只記錄並報告 | 起點：先觀察 |
| p=quarantine | 送入垃圾資料夾 | 中間：確認透過後再收緊 |
| p=reject | 拒收 | 終點：隔離跑乾淨後再收緊 |
DMARC 透過的條件：SPF 透過且對齊，或 DKIM 透過且對齊，通一條即可。對齊指認證域名與發件人域名相符：SPF 對齊比較信封發件人域名，DKIM 對齊比較簽名域名（d= 標籤）。aspf 與 adkim 兩個標籤分別控制對齊模式，預設都是寬鬆模式：子域名與組織域名相符即可透過；嚴格模式要求完全相同。收緊順序複用域名郵箱實操文章口徑：先用 p=none 觀察報告幾周，確認 SPF 與 DKIM 都已對齊，再收緊到隔離、拒絕；Google 幫助頁建議一致，並要求 SPF 與 DKIM 至少執行 48 小時後再啟用 DMARC。pct 標籤控制策略適用的未透過郵件比例，從小比例起步、逐步提高到 100，取值 1 至 100 的整數，不寫則適用於全部郵件。rua 標籤寫報告接收郵箱，報告量大，Google 建議用專門的郵箱或群組接收。v 與 p 兩個標籤須排在最前面。
轉發為什麼會破認證，ARC 一筆帶過
轉發會破壞認證：轉發伺服器再次發出郵件，收信方看到的發信伺服器變了，SPF 可能失敗；轉發方改動內容，DKIM 也可能失效；兩項都失敗，DMARC 也失敗。ARC（Authenticated Received Chain，RFC 8617，實驗性規範）的做法是，各中間方把當時看到的認證結果簽名封存，收信方據此判斷郵件進入轉發鏈之前是否透過認證；ARC 不修復簽名，也不替代 DMARC，是否採信由各家自定。轉發處理細節見域名郵箱實操文章。
Gmail 代發與對齊：先看時效註記
用 Gmail 代發域名地址時，發件人域名與實際發信服務不一致，對齊按代發服務配置走，否則 DMARC 可能失敗。時效註記：Google 已公告，2027 年 1 月起 Gmail 不再支援第三方郵箱地址的代發，Workspace 別名與本人擁有的其他 Gmail 地址不受影響；2026 年第三至第四季度為過渡期，可能限制新配置。域名地址按官方文字理解屬於第三方地址，同樣在終止範圍內，不要把長期發信押在這條路上。發信方案見域名郵箱實操文章與Gmail 海外使用文章。
如何自查：只用 DNS 記錄與郵件頭
站內規則只推薦實測過的工具，本文不推薦任何檢測工具。第一步，查 DNS：域名根部是否只有一條 SPF 記錄，_dmarc 子域的 DMARC 記錄是否存在、p 值是什麼，DKIM 選擇器子域的記錄是否存在、名稱是否與發信服務給出的一致；缺失或寫錯先補記錄，再等 DNS 傳播，DKIM 校驗最長等待 48 小時，期間不要反覆改記錄。第二步，看驗證結果：給自己發測試信，在收信郵箱裡開啟郵件原文，看 Authentication-Results 頭的 spf、dkim、dmarc 三項；全透過仍進垃圾資料夾時，問題在域名信譽或內容上。第三步，讀彙總報告：rua 郵箱的報告列出各發信來源與認證結果，核對合法來源是否對齊，收緊前先修好未對齊的來源。
侷限與未核實清單
本文未實測，核查日期 2026-11-13，各服務商可能隨時調整。未能核實：各收信方的實際處置細節；各發信服務商的具體記錄值，須按自家文件填寫；ARC 在各收信方的採信程度；DMARC 新版規範的實施進度，各來源說法不一，本篇按 RFC 7489 口徑寫；Gmail 代發在自定義域名地址上的完整表現。配置前以官方文件為準，先用非關鍵地址測試。
2026-11-13：首發
相關：郵箱與電話號碼 · 域名郵箱實操 · Gmail 海外使用 · 海外郵箱對比 · 方法論