SPF、DKIM 與 DMARC 設定教學：陌生開發信的逐步指南

如果您用自己的網域寄陌生開發信，有三筆 DNS 記錄會決定收件伺服器是否相信這封信真的是您寄的：SPF、DKIM 和 DMARC。 少了它們，即使是寫得再好的第一封信，也可能在有人讀到之前就被過濾掉。

本指南適合使用類似 you@yourcompany.com 這種地址、通常透過 Google Workspace 寄出開發信的創業者與業務團隊。我們（Outreach）會依照您該設定的順序逐一說明每一筆記錄，完全照 Google 說明頁面和 RFC 公布的格式展示記錄，並指出那些讓記錄看起來沒問題、卻悄悄失效的錯誤。

您不必是 DNS 專家。您需要能存取網域的 DNS 設定（在您的網域註冊商或 DNS 代管服務），而 DKIM 還需要 Google Workspace 的管理員權限。

SPF、DKIM 和 DMARC 各用一句話說明是什麼？

SPF 列出獲准代表您的網域寄信的伺服器，DKIM 加上一個加密簽章來證明郵件沒有被偽造或竄改，而 DMARC 則告訴收件方，當郵件沒通過這些檢查時該怎麼處理。 這三者都是以 TXT 記錄的形式，發布在您網域的 DNS 中。

它們是一起運作的。SPF 和 DKIM 各自只證明很窄的一件事；DMARC 則把這些證明，和人們在 From 欄位實際看到的地址綁在一起。

寄陌生開發信真的必須設定這些記錄嗎？

是的——寄給 Gmail 和 Yahoo 的每一位寄件者，至少都要有 SPF 或 DKIM，而大量寄件者三個都需要。 這不是最佳實務的建議，而是寫在兩家服務商公布的寄件者規定裡。

Google 的電子郵件寄件者規範指出，所有寄件者都必須「為您的寄件網域設定 SPF 或 DKIM 電子郵件驗證」。一天寄給 Gmail 帳號「超過 5,000 封郵件」的寄件者，還必須「設定 SPF 和 DKIM」，以及「為您的寄件網域設定 DMARC 電子郵件驗證」，而且 From 網域必須與 SPF 或 DKIM 網域對齊。這些規定自 2024 年 2 月 1 日起生效。

Yahoo 的 Sender Hub 最佳實務也一致：每一位寄件者至少都必須「實作 SPF 或 DKIM」，而大量寄件者必須「同時實作 SPF 和 DKIM」，並「發布有效的 DMARC 政策，至少為 p=none」。

小規模的陌生開發信計畫，可能永遠不會達到一天 5,000 封。無論如何，三個都設定吧：不需要任何費用，只要花一個下午，而且您永遠不必去摸索那條界線在哪裡。

該怎麼設定 SPF？

請在您的根網域新增一筆 TXT 記錄，以 v=spf1 開頭，列出所有替您寄信的服務，並以 ~all 結尾。 如果網域只透過 Google Workspace 寄信，Google 的 SPF 設定頁面提供的記錄就是這一筆：

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

步驟：

1. 登入您的網域代管服務的 DNS 設定。
2. 建立一筆 TXT 記錄。在主機或名稱欄位，如果是新增到根網域而不是子網域，Google 說要輸入 @。
3. 把記錄貼上作為值，然後儲存。
4. 請等待。Google 指出「SPF 驗證功能最多可能要 48 小時才會開始運作」。

如果還有其他服務也從您的網域寄信——例如電子報工具、客戶關係管理（CRM）系統、交易郵件服務——每一個都需要在同一筆記錄裡加上自己的 include:。Google 的頁面提供了這些合併後的範例：

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

請使用各寄信服務自己在文件中公布的 include 值；不要自己猜。

SPF 記錄結尾該用 ~all 還是 -all？

Google 的設定指南使用 ~all，而在您還在找出所有替您寄信的服務期間，這是安全的預設值。 這兩種結尾在 SPF 標準 RFC 7208 中的意義不同：

• ~all（softfail，軟性失敗）的意思是「發布記錄的管理網域（ADMD）所做的較弱聲明，表示該主機可能未獲授權」。
• -all（fail，失敗）的意思是「明確聲明該用戶端未獲授權，不得以指定的身分使用該網域」。

使用 -all 時，您忘了列入的寄信服務會被直接判定為嚴格失敗。一旦 DMARC 就位，且它的報告顯示每一個合法的寄信來源都通過了，SPF 的結尾就沒那麼重要，因為收件方會改為遵循 DMARC 的政策。

為什麼 include 太多會讓 SPF 失效？

因為一次 SPF 檢查最多只能觸發 10 次 DNS 查詢；超過之後，整個結果就會變成錯誤。 RFC 7208 第 4.6.4 節指出，實作時「在 SPF 評估期間，必須把這些項目的總數限制在 10 個」，而且「如果超過這個限制，實作必須回傳『permerror』」。

會計入的項目有 include、a、mx、ptr、exists 和 redirect 修飾詞。關鍵在於，計算涵蓋整個評估過程——所以本身又包含更多 include 的 include:，會用掉您 10 次額度中的好幾次。Google 自己的頁面把這一點寫成「SPF 記錄最多可以有 10 個 include: 標記」；RFC 的解讀更嚴格，因為巢狀的查詢也會計入。

如果您多年來陸續加入了好幾個業務和行銷工具，請在新增 include 之前，先移除不再使用的那些。

一個網域有兩筆 SPF 記錄會怎樣？

SPF 會因錯誤而失敗——兩筆記錄會被視為設定損壞，而不是兩份可以合併的清單。 RFC 7208 指出，當一個網域存在不只一筆 v=spf1 記錄時，檢查會「產生『permerror』結果」。

常見的成因是：有人為了新工具另外新增第二筆 TXT 記錄，而不是修改既有的那一筆。解決方法是把它們合併成一筆有多個 include: 項目的記錄，就像上面的範例那樣。

如何在 Google Workspace 開啟 DKIM？

在 Google 管理控制台產生一組金鑰，把它發布為位於 google._domainkey 的 TXT 記錄，然後按一下「開始驗證」。 Google 的 DKIM 設定頁面說明了完整的路徑：

1. 在 Google 管理控制台中，前往 應用程式 > Google Workspace > Gmail > 驗證電子郵件。（您需要具備 Gmail 設定管理員權限）
2. 選擇網域，並產生新的記錄。
3. 選擇金鑰長度。Google 表示，「如果您的網域供應商支援 2048 位元金鑰」，就選擇 2048，因為「較長的金鑰比較短的金鑰更安全」；只有「如果您的網域代管服務不支援 2048 位元金鑰」，才選擇 1024。
4. 保留預設的前置字元選取器 google——Google 稱它是 Workspace 的「建議選項」。
5. Google 會顯示一個 DNS 主機名稱 google._domainkey，以及一個以 v=DKIM1 開頭的 TXT 值。請把兩者都複製到您 DNS 代管服務上的新 TXT 記錄中。
6. 回到管理控制台，按一下 開始驗證。

Google 產生的 TXT 值長這樣（金鑰本身是一長串您網域專屬的字串）：

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

時間：Google 表示，加入金鑰之後，「DKIM 驗證功能最多可能要 48 小時才會開始運作」。如果您才剛為新網域設定 Gmail，Google 指出您「必須等待 24 至 72 小時」，DKIM 金鑰才會出現在管理控制台中。

如果有其他服務替您寄信，它會提供自己的 DKIM 記錄和自己的選取器。請也把它發布出來——不同選取器的多把 DKIM 金鑰可以並存，這點和 SPF 不同。

如何設定 DMARC 又不會擋掉自己的郵件？

請先在 _dmarc.yourcompany.com 發布一筆 p=none 的 TXT 記錄，讀過報告之後，才收緊政策。 Google 的 DMARC 設定頁面寫道：「開始使用 DMARC 時，我們建議把政策選項（p）設為 none」。它也建議您「在設定 SPF 和（或）DKIM 之後，等待 48 小時再設定 DMARC」。

Google 的頁面提供了這個完整的範例記錄：

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

這個範例呈現的是已完成、最嚴格的狀態。第一筆記錄只要用相同格式，搭配監控用的政策和一個報告地址就夠了——例如 v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com。rua 標籤會把彙總報告寄到那個信箱；Google 建議使用專用的信箱或群組，因為報告可能大量湧入。

DMARC 規範中定義的三個政策值：

一個網域只能有一筆 DMARC 記錄。依據 RFC 9989，如果回傳了多筆 DMARC 記錄，「它們全部都會被捨棄」——也就是完全不適用任何政策。

「對齊」是什麼意思？為什麼 SPF 通過了 DMARC 卻失敗？

只有當 SPF 或 DKIM 是針對與人們所見的 From 地址相符的網域通過時，DMARC 才會通過。 SPF 可能是針對您寄信服務自己的網域通過，而 From 欄位顯示的卻是您的網域——這時 DMARC 還是會失敗，因為通過的那個網域沒有對齊。

DMARC 規範指出，只要至少有一種驗證方式「根據對齊的識別碼」產生通過的結果，這封郵件就算通過（RFC 7489，現已由 RFC 9989 接續）。預設的對齊方式是寬鬆（adkim 和 aspf 預設為 r）：mail.yourcompany.com 和 yourcompany.com 因為屬於同一個組織網域，所以算作相符。像 Google 範例那樣的嚴格模式（s），則要求完全相符。

實務上，這就是 DKIM 對陌生開發信如此重要的原因：當您的寄信服務使用您的網域簽署時，即使 SPF 對齊沒通過，DKIM 對齊也會通過。

DMARC 標準在 2026 年有變動嗎？

有。RFC 9989 於 2026 年 5 月以標準追蹤（Standards Track）文件的形式發布，取代了原本的 RFC 7489——而且移除了 pct 標籤。 既有的 v=DMARC1 記錄仍然可以繼續運作。

大多數寄件者會注意到的主要變動是：pct（只對一定比例的失敗郵件套用政策）已經不見了。RFC 說明：「營運經驗顯示，除非指定的值是 0 或 100，否則『pct』標籤通常沒有被準確地套用」。取而代之的是一個測試旗標 t=y，它會請收件方在您測試期間，不要套用您所陳述的政策。

Google 的說明頁面在範例中仍然顯示 pct=100。這不會造成任何問題：RFC 9989 指出「未知的標籤必須被忽略」，所以遺留的 pct 會被直接略過。下次編輯記錄時，您可以把它刪掉。

如何確認一切運作正常？

先查詢您發布的記錄，再寄一封真實的郵件到 Gmail 地址，並讀取它的驗證結果。 兩個快速檢查：

1. 查詢 DNS 記錄。 我們的免費檢查工具會針對您輸入的地址所屬的網域，查詢 SPF、DKIM 和 DMARC 記錄——不需要註冊。它檢查的是 Google 預設的 DKIM 選取器（google._domainkey）；如果您的寄信服務使用不同的選取器，即使 DKIM 已經設定好，檢查工具也會把 DKIM 回報為「未確認」。這個工具提供英文和韓文版本；請輸入您的寄件電子郵件地址。
2. 檢查真實郵件。 寄一封電子郵件到您掌控的 Gmail 帳號，開啟它，選擇「顯示原始郵件」，並找出 SPF: PASS、DKIM: PASS 和 DMARC: PASS。

接著給 DMARC 報告一到兩週的時間。當您使用的每一個合法來源都顯示為通過時，就把 p=none 改為 p=quarantine，之後如果想要最強的防偽冒保護，再改為 p=reject。

哪些錯誤最常讓驗證失效？

兩筆 SPF 記錄、SPF 查詢次數過多、DKIM 產生了卻從未啟動，以及在 SPF 和 DKIM 還沒來得及生效之前就發布了 DMARC。 檢查清單：

• 只有一筆 SPF 記錄，每個寄件來源都以 include: 放在其中，查詢項目不超過 10 個。
• 發布 DKIM 金鑰之後，要按一下「開始驗證」——光有 DNS 記錄是不夠的。
• 在設定 SPF 和 DKIM 之後，先等待約 48 小時再加入 DMARC，並把它發布在 _dmarc，而不是根網域。
• 從您掌控的網域寄信。 您無法為 @gmail.com 地址發布 DMARC。

驗證能讓您的郵件被納入考慮；它不會讓收件者想要收到。垃圾郵件投訴依然會被計算——Google 和 Yahoo 都說要把垃圾郵件比率維持在 0.3% 以下，我們在為什麼陌生開發信會進垃圾郵件匣中有說明。而寄給不存在的地址會產生退信，這也是我們建議您在寄信前先驗證地址的原因。

重點整理

• Google 和 Yahoo 要求每一位寄件者都要有 SPF 或 DKIM，而大量寄件者（一天寄給 Gmail 5,000 封以上）則必須三者齊備，並且要對齊。
• SPF：在 @ 放一筆 TXT 記錄，例如 v=spf1 include:_spf.google.com ~all；DNS 查詢項目不超過 10 個。
• DKIM：2048 位元金鑰，選取器為 google，TXT 放在 google._domainkey，然後按一下 開始驗證。
• DMARC：在 _dmarc 放一筆 TXT 記錄，從 p=none 加上報告地址開始，之後再收緊。RFC 9989（2026 年 5 月）用 t=y 取代了 pct。
• 用我們的免費郵件驗證檢查工具檢查您的記錄，然後在真實郵件上確認。