DMARC 完整教學 2026：SPF、DKIM、DMARC 三件套設定

DMARC 是一筆放在 _dmarc.<你的網域> 的 DNS TXT 記錄，用來告訴收件端「這個網域寄出的信如果沒通過 SPF 或 DKIM，你要怎麼處理」。沒有這筆記錄，2026 年 11 月起 Outlook 系列信箱會開始退你的信。

這不是演算法更新，也不是要你換寄信服務。它是一筆幾十個字元的 DNS 記錄，加上兩個你大概已經有、但很可能設錯的舊記錄。問題是，全台灣有大量中小企業與個人品牌根本沒設，而且因為只有部分信件被退，所以幾乎不會被發現。

先看懂事件：為什麼現在每個人都該檢查

第三列才是這次的重點：它沒有門檻、沒有公告、沒有明確失敗清單。資安服務商 MailRoute 從自家外送日誌最早看到這批退信，並指出被退的網域多半 SPF 正常、有些連 DKIM 都正常，缺的就是「把兩者綁到 From 位址」的那筆 DMARC。

更麻煩的是它只退一部分。同一批信，一封進得去、下一封被退，重寄又可能成功。寄件人看到一串縮寫就當成偶發錯誤，收件人則根本不知道有信來過。發票沒到、預約確認沒到、回信看起來像已讀不回——這些都不會進到任何監控儀表板。

三件套各自負責什麼

新手最常卡住的地方，是把三個縮寫當成同義詞。它們檢查的東西完全不同：

三個記錄的關係可以用一句話記住：SPF 管「誰可以寄」，DKIM 管「內容有沒有被動過」，DMARC 管「這兩個結果跟畫面上顯示的寄件人是不是同一個網域」。

最後那句是關鍵。很多公司 SPF、DKIM 都設了，DMARC 卻一直沒過，就是因為兩者驗的網域跟 From 網域不一樣——這叫對齊（alignment）問題。

對齊：最容易設錯的一步

DMARC 通過的條件只有一個：

SPF 通過 且 信封寄件網域與 From 網域對齊，或 DKIM 通過 且 d= 網域與 From 網域對齊。

「對齊」有兩種模式：嚴格（strict，網域必須完全相同）與寬鬆（relaxed，只要組織網域相同即可，例如 mail.example.com 對齊 example.com）。預設是寬鬆，除非你在記錄裡寫 adkim=s 或 aspf=s。

來看一個真實例子，本站網域 2026-11-08 的實際查詢結果：

這組設定很典型，也剛好示範了兩個最常見的誤解：

1. SPF 設在子網域，不等於 From 網域有 SPF。 寄信服務用 send.most.tw 當信封寄件者（DKIM selector 命名為 resend），SPF 通過的是 send.most.tw；但信件的 From 是 @most.tw，兩者組織網域相同，所以寬鬆模式下「算對齊」。如果哪天改了寄信服務、信封網域變成別人的網域，這個對齊就會斷。
2. 真正讓信送得出去的是 DKIM，不是 SPF。 根網域沒有 SPF，但 DKIM 的 d=most.tw 與 From 對齊，於是 DMARC 仍然通過。這正好說明為什麼「信都收得到」不能當成設定正確的證據——p=none 之下，就算兩個都不過，收件端也不會擋你。

而 p=none 又沒有 rua，代表沒有人會收到失敗回報。掛著一個沒有回報地址的 DMARC，等於在門口裝了一台沒有接電的監視器：形式上有，實際上什麼都不知道。

SPF 怎麼寫

最小可用版本長這樣（~all 是軟失敗，-all 是硬失敗）：

v=spf1 include:_spf.google.com include:amazonses.com ~all

幾個實務規則：

估算查詢次數最快的方法，是把所有會觸發 DNS 查詢的機制列出來數一遍。上面那筆範例是 2 個 include，加上每一層 include 內部展開的查詢（Google 的 _spf.google.com 自己就包含多層），實務上很容易在「多加一個 SaaS 服務」時悄悄爆表。每次新增寄信服務，都要重數一次。

DKIM 怎麼做（含實際輸出）

DKIM 需要一對金鑰：私鑰留在寄信端簽章，公鑰放到 DNS 讓收件端驗章。用 openssl 產 2048 位元金鑰：

openssl genrsa -out dkim.key 2048
openssl rsa -in dkim.key -pubout -outform PEM

實際執行後，公鑰的 base64 內容（去掉 PEM 標頭尾）長度是 392 字元，組成完整記錄後總長 410 字元：

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArWJfRdUY...

DNS 的 TXT 記錄有「單一字串 255 位元組」的限制，所以 410 字元必須拆成兩段（實測 255 + 155），多數 DNS 供應商會自動幫你拆，但自架 BIND 或用 API 寫入時要自己處理：

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArWJfRdUY...(前 255 字元)"
"(剩下的 155 字元)"

記錄名稱是 <selector>._domainkey.<網域>，selector 自己取（default、google、resend、s1 都常見）。寄信端簽章時的 s= 必須跟 selector 完全一致，不然收件端查不到公鑰。

簽完之後怎麼確認真的有效？用 Python 的 dkimpy 實際跑一次（簽章用剛產生的私鑰，驗章用 DNS 函式回傳同一把公鑰）：

簽章標頭長這樣（h= 列出被納入簽章的標頭，bh= 是內文雜湊）：

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com;
 i=@example.com; q=dns/txt; s=demo; t=1794168144; h=from : to : subject : date; bh=...

True / False 這一組對照是 DKIM 存在的意義：它證明的是「內容沒被改」，不是「寄件人是你」。所以偽造者如果偷到你的私鑰，DKIM 一樣會通過——這也是為什麼 2048 位元、定期輪替、私鑰不進 git 是三件必須同時做到的事。RFC 8301 的規定是簽章金鑰至少 1024 位元、建議 2048 位元；本站目前那把解析出來是 1024 位元，屬於「能用但不理想」的等級。

DMARC 怎麼寫

最小版本就是一行：

v=DMARC1; p=none; rua=mailto:dmarc@example.com

常用標籤：

三個實務細節：

• rua 一定要設。 沒有回報的 p=none 完全沒有資訊價值，你會不知道自己有多少信被擋、被誰擋。
• 記錄只能有一筆。 放在 _dmarc.<網域>，TXT 型別；實務上也不要用 CNAME 轉址，部分驗證器不支援，而且多一層查詢鏈就多一個失敗點。
• p=reject 不是終點，是結果。 前提是 SPF 與 DKIM 都對齊、而且所有寄信來源（官網、客服系統、電子報、會計系統、人資系統）都盤點過。

上線順序：照 Google 官方建議走最安全

Google Workspace 的官方文件（2026-10-26 更新）把 rollout 寫得很具體，值得直接照抄：

第 1 階段那一週是最有價值的時間。你會第一次看到「原來行銷部門還在用一個沒人記得的平台寄信」——這種寄信來源如果直接上 p=reject，等於親手把自己的通知信擋掉。

怎麼驗證（可直接執行）

Authentication-Results 那行是唯一的權威。DNS 記錄設得再漂亮，只要收件端顯示 dmarc=fail，就是沒過。

常見錯誤對照表

誰需要、誰可以晚點做

最後那一列常被忽略：一個「不寄信」的網域，正是最容易被人拿來偽造寄件人的網域。設 p=reject 的成本是零，收益是別人不能再拿你的品牌名去釣魚。

站內延伸閱讀

• DNS 紀錄大解密：12 種 DNS 記錄完整指南
• Cloudflare Tunnel 完整教學 2026
• AdGuard Home 完整教學 2026：自架 DNS、DoH／DoT 加密

（本文為技術整理，未接受任何廠商贊助；文中所有查詢結果為 2026-11-08 實際執行所得。）