Live Direct Marketing
首頁 → 部落格 → 郵件到達率

如何在 GoDaddy 幫網域加上 SPF、DKIM、DMARC，讓冷開發信穩定送達收件匣

2026年7月12日 · 9 分鐘閱讀 · 指南: 郵件到達率

許多台灣中小企業用 GoDaddy 註冊網域，但從沒碰過 DNS 後台的 SPF、DKIM、DMARC 設定，直到冷開發信開始大量落入垃圾匣才發現問題。這三組記錄是收件伺服器判斷「這封信是不是真的來自這個網域」的依據，設定錯誤或完全沒設，Gmail、Outlook 等主流信箱會直接調降信譽分數。本文用實際 GoDaddy 後台操作順序說明怎麼設，以及設定完後該注意什麼。

重點整理
  • SPF、DKIM、DMARC 是網域層級的 DNS 記錄，缺一項都會拉低冷開發信的到達率
  • GoDaddy 後台新增記錄的入口是「我的產品 → DNS → 管理區域」，都是 TXT 或 CNAME 型態
  • 同一網域只能有一筆 SPF TXT 記錄，多寄件服務要合併寫在同一行，不能各加一筆
  • 看到 dmarc policy not enabled 警示代表 _dmarc 子網域完全沒有 TXT 記錄，不是政策設錯而是根本沒設
  • DMARC 政策要從 p=none 監控期開始，逐步收緊到 quarantine、reject，直接上 reject 容易誤殺正常信件

為什麼 GoDaddy 網域沒設驗證記錄，冷開發信會進垃圾匣

冷開發信通常量小、個人化、一封一封發給特定聯絡人，理論上比群發電子報更容易通過垃圾郵件過濾。但收件伺服器判斷寄件人身分時看的不是寄信量，而是網域有沒有可驗證的憑證。GoDaddy 註冊網域時只給你網域名稱和基本的 DNS 區域，SPF、DKIM、DMARC 這三筆記錄要自己手動加，沒加的話寄信服務商（Google Workspace、Microsoft 365 或第三方寄信 API）寄出的信在收件端看起來就像「誰都可以冒充這個網域寄信」。

這三者分工不同：SPF 記錄告訴收件伺服器「哪些伺服器有權代表這個網域寄信」；DKIM 是幫每封信加上一組加密簽章，證明信件內容從寄出到送達沒被竄改；DMARC 則是告訴收件伺服器「SPF 或 DKIM 驗證失敗時該怎麼處理這封信」，同時把驗證結果彙整成報告寄回給你。三項一起設定，才算完整的寄件人驗證。

在 GoDaddy 後台新增 SPF 記錄的步驟

登入 GoDaddy 帳號後，進入「我的產品」，找到要設定的網域，點選旁邊的「DNS」或「管理 DNS」，會進到該網域的 DNS 區域管理頁面。這裡就是新增 spf godaddy 記錄的地方，操作邏輯跟一般 DNS 面板一樣：新增一筆記錄，選型態、填主機名稱、填數值。

SPF 記錄一律用 TXT 型態，主機名稱填「@」（代表根網域），數值以 v=spf1 開頭，後面接你實際會用來寄信的服務商，例如 Google Workspace 用 include:_spf.google.com，用 LDM 平台寄信則加上平台提供的 include 值，最後以 -all 或 ~all 結尾。TTL 保持預設的 1 小時即可。GoDaddy 網域最容易出的錯是重複新增：如果原本就有一筆 TXT 記錄裡有 v=spf1，千萬不要再加第二筆，而是編輯既有那一筆，把所有 include 合併寫在同一行，同網域出現兩筆 SPF TXT 記錄，收件伺服器會直接判定驗證失敗。

設定 DKIM：先在寄信服務商產生金鑰，再貼回 GoDaddy

DKIM 沒辦法自己憑空填一組數值，必須先在寄信服務商（Google Workspace 管理控制台、Microsoft 365 系統管理中心，或 LDM 這類寄信平台）產生一組公私鑰，服務商會給你一個選擇器名稱（例如 google 或 selector1）和對應的 TXT 或 CNAME 數值。

拿到這組資料後回到 GoDaddy DNS 區域管理頁面新增記錄：主機名稱通常是「選擇器._domainkey」這種格式，例如 google._domainkey，型態依服務商指示選 TXT 或 CNAME，數值原封不動貼上。加完之後回到寄信服務商後台按「驗證」，如果顯示失敗，最常見原因是主機名稱多打了網域本身（GoDaddy 的主機名稱欄位不用重複打完整網域，只填子網域部分）。DKIM 生效通常需要幾分鐘到幾小時的 DNS 傳播時間，別急著判定失敗就重設一次金鑰。

設定 DMARC：解決 dmarc policy not enabled 警示

SPF、DKIM 都設好後，最後一步是加 DMARC 記錄。做法一樣是在 GoDaddy DNS 區域新增一筆 TXT 記錄，主機名稱固定填 _dmarc，數值從最寬鬆的監控模式開始，例如 v=DMARC1; p=none; rua=mailto:你的收信地址。p=none 代表先不處理驗證失敗的信件，只把結果彙整成報告寄給你，讓你有機會在正式收緊政策前發現漏設的合法寄件來源。

很多人在檢測工具或 Google Postmaster Tools 看到 dmarc policy not enabled 這個警示會誤以為是「政策設錯」，其實這句話的意思是「_dmarc 子網域完全找不到 TXT 記錄」，也就是根本沒設定。這種情況必須先確認 GoDaddy 那筆記錄的主機名稱是不是精確打成 _dmarc（前面有底線，不能漏打），型態是 TXT 不是別的，儲存後等 DNS 傳播完成再重新檢測。

跑過一到兩週的監控期、確認報告裡沒有意外的驗證失敗來源後，再把政策逐步收緊為 p=quarantine（可疑信件丟垃圾郵件夾），最後視情況調到 p=reject（直接拒收）。直接從 none 跳到 reject 是最常見的失誤，容易連轉寄、部分行銷工具寄出的合法信一起擋掉。

常見錯誤與踩雷排行

GoDaddy 網域驗證記錄設錯的模式其實高度重複，多半集中在幾個固定的坑，抓對這幾點可以省掉大半排查時間。

LDM 怎麼處理新網域的驗證與暖身

在 LDM 平台上串接 GoDaddy 網域寄冷開發信時，系統會先檢查 SPF、DKIM、DMARC 三項記錄是否齊全，缺件會直接標示出來，避免客戶帶著沒驗證的網域就開始寄信。新網域即使記錄全部設對，也需要一段每日逐步增量的暖身期，配合小量、高度個人化的內容，讓收件方的信譽系統慢慢認識這個網域，而不是一開始就衝量。

驗證記錄之外，冷開發信在台灣還要留意《個人資料保護法》第20條第2項的規定：以個人資料進行行銷時，應提供當事人表示拒絕接受行銷的方式，實務上就是每封信都要有清楚的退訂或回覆停止聯絡的管道，且一旦對方表示拒絕，就必須停止再寄。這跟驗證記錄設定是兩件事，但同樣是決定冷開發信能不能長期穩定送達的關鍵。

常見問題

GoDaddy 網域一定要自己設定 SPF、DKIM、DMARC 嗎？

是的，GoDaddy 只負責網域註冊和 DNS 代管，不會自動幫你加上這三項記錄。不論用哪個寄信服務商寄冷開發信，都要回到 GoDaddy 的 DNS 管理頁面手動新增。

看到 dmarc policy not enabled godaddy 這個提示該怎麼處理？

這代表 _dmarc 子網域完全沒有 TXT 記錄，不是政策設錯而是還沒設定。回 GoDaddy DNS 頁面新增一筆主機名稱為 _dmarc、數值以 v=DMARC1; p=none 開頭的 TXT 記錄即可解除這個警示。

SPF 記錄裡的 -all 和 ~all 差在哪裡？

-all 是嚴格模式，未列在 include 清單裡的伺服器寄出的信會直接被判定驗證失敗；~all 是軟性失敗，收件伺服器會放行但標記可疑。新網域或還在調整寄信服務商時建議先用 ~all，穩定後再改成 -all。

DKIM 設定完，收件方還是顯示驗證失敗怎麼辦？

先確認 GoDaddy 那筆記錄的主機名稱有沒有多打網域本身、型態是不是跟服務商要求一致，再等幾小時讓 DNS 傳播完成。若仍失敗，回寄信服務商後台重新產生一組新選擇器的金鑰再貼一次。

DMARC 政策要多久才能從 p=none 調到 p=reject？

沒有固定天數，重點是看 DMARC 報告：連續一到兩週沒有出現非預期的驗證失敗來源，就可以先調到 p=quarantine，再觀察一段時間確認沒有誤殺合法信件後，才調到 p=reject。

GoDaddy 之外還買了其他寄信工具的授權，SPF 要怎麼合併？

所有寄信服務商的 include 值都要寫進同一筆 SPF TXT 記錄裡，用空格分隔，例如 v=spf1 include:_spf.google.com include:寄信平台網域 -all，絕對不能各自新增一筆獨立的 SPF 記錄。

重要：這不是大量群發，也不是垃圾郵件。 我們採取精準外聯：每封訊息都基於正當商業理由，寄給特定公司的特定負責人，每日寄送量少，並針對收件人進行個人化。每封郵件都標明寄件人並提供一鍵取消訂閱；取消訂閱與封鎖名單將無一例外地套用於所有後續活動。

想把這套方法用在你的客戶開發上嗎？

在開始之前，我們會說明這套做法如何套用到你的市場區隔與產品。

與我們聯繫

更多相關主題: 郵件到達率