SPF、DKIM、DMARC 是什麼？網店寄電子報必懂的三筆紀錄

為什麼收件端要檢查這三筆紀錄#

任何人都能在寄件人欄位填上任何地址。一封自稱來自 ninefold.example 的信，是不是真的由 Ninefold 寄出，收件端就是靠 SPF、DKIM 和 DMARC 判斷。三者都是發布在你網域上的 DNS 紀錄，各自回答不同的問題。

對網店來說，最直接的影響是電子報能不能進收件匣。Google 要求所有寄件者設定 SPF 或 DKIM，每天寄超過 5,000 封到個人 Gmail 帳戶的寄件者則必須三項都有 ^S4。Yahoo 對大量寄件者也訂了相同的基本要求 ^S5。即使寄送量沒到這個門檻，通過驗證的信件也會替你自己的網域累積寄件人信譽；有了 DMARC 紀錄，別人也更難冒用你的名義寄釣魚信。

三筆紀錄各自做什麼#

SPF：哪些伺服器可以替你寄信

SPF 是一筆 TXT 紀錄，列出允許代表該網域寄信的伺服器。收件伺服器會拿連線進來的 IP 位址和這份清單比對。SPF 檢查的是信封寄件人（傳送過程中使用的 MAIL FROM 地址，也是接收退信的地址），不是顧客看到的寄件人地址 ^S1。同時使用公司信箱和電子報平台的網店，紀錄通常長這樣：

v=spf1 include:spf.mailbox.example include:spf.mailservice.example ~all

每個 include 會引入另一家服務商的清單。結尾說明其他來源該怎麼處理：-all 代表失敗（fail），~all 代表軟失敗（softfail），收件端不應只因軟失敗就拒收 ^S1。

DKIM：每封信上的數位簽章

DKIM 會在信件標頭加上一組加密簽章。簽章裡寫明簽署網域（d=）和選擇器（s=），收件端再到 selector._domainkey.domain 這筆 DNS 紀錄取得公鑰 ^S2。如果傳送途中被簽署的標頭或內文遭到更動，驗證就會失敗。單看 DKIM，簽署網域不必和寄件人地址相同 ^S2，這正是需要 DMARC 的原因。

DMARC：把前兩者綁到顧客看得到的寄件人地址

DMARC 是發布在 _dmarc.yourdomain 的 TXT 紀錄。它要求收件端確認 SPF 或 DKIM 是以「和寄件人地址相符的網域」通過，告訴收件端如何處理驗證失敗的信（none、quarantine 或 reject），並指定報告寄送的位置 ^S3。第一筆紀錄可以短到只有 v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example。

三者如何搭配：對齊#

SPF 和 DKIM 都可能以「錯的網域」通過。電子報平台可能用自己的退信網域通過 SPF、用自己的名義做 DKIM 簽章，而寄件人欄位寫的卻是 ninefold.example。這兩個結果都無法證明信件和 Ninefold 有關。

DMARC 用「對齊」補上這個缺口。只要 SPF 以和寄件網域對齊的網域通過，或 DKIM 以和寄件網域對齊的網域通過，信件就通過 DMARC ^S3。預設是寬鬆對齊，所以 mail.ninefold.example 的 DKIM 簽章，可以和 ninefold.example 的寄件地址對齊；嚴格對齊則要求網域完全相同 ^S3。Gmail 和 Yahoo 對大量寄件者的規定一致：寄件網域必須和 SPF 網域或 DKIM 網域對齊 ^S4S5。

DKIM 對齊比 SPF 對齊更重要。信件被轉寄時，轉寄伺服器會用自己的 IP 位址連線，原網域的 SPF 往往因此失敗 ^S1。只要信件內容沒有被修改，DKIM 簽章就能保留下來。

網店需要發布哪些紀錄#

動 DNS 之前，先列出所有「以你的網域當寄件地址」寄信的服務。以 Ninefold 這樣的小型服飾品牌為例，通常包括公司信箱、電商平台寄出的訂單與出貨通知、客服系統，以及寄 EDM 的電子報工具。每一項都要涵蓋到。

1. 一筆 SPF 紀錄，把所有以你的網域寄信的服務都 include 進來。
2. 在上述每個服務中開啟 DKIM，並以你自己的網域作為簽署網域。每個服務會給你各自的紀錄與選擇器，因此多筆 DKIM 紀錄可以同時存在。
3. 一筆 DMARC 紀錄，先從 p=none 加上報告地址開始，在正式執行政策前先看清楚有誰用你的名義寄信。DMARC 設定指南會一步步說明如何調整到 quarantine 和 reject。

身分驗證只是信箱服務商要求的其中一部分。他們也會看是否支援一鍵取消訂閱，以及你的垃圾郵件檢舉率；其餘項目請見寄信到達率入門。

常見的設定錯誤#

• 同時有兩筆 SPF 紀錄。一個網域只能有一筆以 v=spf1 開頭的紀錄；有兩筆時，每封信的 SPF 都會回傳永久錯誤（permerror）^S1。請合併成一筆。
• DNS 查詢次數太多。include、a、mx、ptr、exists、redirect 每一個都會產生一次 DNS 查詢，超過 10 次 SPF 就會出錯 ^S1。與其一直疊加 include，不如移除已經不用的服務。
• DKIM 用服務商的網域簽署。簽章雖然通過，卻和你的寄件地址不對齊。請在每個工具裡改用自己的網域設定 DKIM。
• 一開始就設 p=reject。被遺漏的寄件來源，例如電商平台寄出的訂單確認信，會在沒人察覺的情況下開始被拒收。請從 p=none 開始，先讀報告。
• 沒有設定報告地址。DMARC 紀錄少了 rua，你就拿不到任何可以判斷的資料。Yahoo 強烈建議在設定期間加上可正常收信的 rua 標籤 ^S5。

如何檢查紀錄是否設定正確#

用 DNS 查詢可以看到你發布了什麼；讀一封實際收到的信，則能看到收件端實際的判斷結果。

• 用終端機：dig +short TXT ninefold.example 會顯示 SPF 紀錄，dig +short TXT _dmarc.ninefold.example 會顯示 DMARC，知道選擇器後，dig +short TXT selector._domainkey.ninefold.example 會顯示 DKIM 公鑰。
• 用瀏覽器：任何能查詢 TXT 紀錄的 DNS 查詢工具，都能得到相同的結果。
• 用實際信件：寄一封測試信到 Gmail 信箱，打開後點選「更多」，再點選「顯示原始郵件」^S6。標頭會列出這封信的 SPF、DKIM 和 DMARC 結果，以及各自是以哪個網域通過。

DMARC 現在已列入 IETF 標準軌道：2026 年 5 月發布的 RFC 9989 取代了 RFC 7489 ^S3S7。紀錄仍然以 v=DMARC1 開頭，所以依舊規則寫的紀錄可以繼續使用 ^S3。

在 Claude 或 ChatGPT 裡用 Tellnod 完成驗證設定#

Tellnod 是一個 MCP 連接器，讓你在 Claude 或 ChatGPT 裡撰寫、預覽並寄出行銷信。第一天就能從 Tellnod 共用網域上以店名命名的地址寄信（例如 hello@yourshop.tellnodmail.com），不用改 DNS，限制為每檔最多 500 位收件人、每月最多 1,000 封。驗證自有網域後即解除這些限制，這也是我們建議的設定方式。

要驗證網域，在對話中這樣說就可以：「把 ninefold.example 設為我的寄件網域。」Tellnod 會給你 SPF、DKIM 和 DMARC 紀錄，並替你檢查。如果 DNS 由別人管理，可以說：「幫我們的網站工程師建立設定連結。」對方不必註冊帳號，使用支援的 DNS 服務商時可一鍵新增紀錄，也可以複製紀錄自行設定；網域驗證通過後，你會在對話中及透過 Email 收到通知。DNS 變更通常幾分鐘內生效，最長可能需要 48 小時。

完成驗證不會改變發送流程：每一檔活動都會顯示桌機與手機預覽，你在核准卡片上按下 Confirm 之前，什麼都不會寄出。每一次發送都由你核准。先把 Tellnod 連接到 Claude 或 ChatGPT；免費方案與付費方案列在價格頁面。

常見問題#