用 Gmail 寄開發信前，先把 SPF、DKIM、DMARC 確認清楚

很多業務主管以為只要用公司網域的 Google Workspace 信箱寄信，收件人就一定看得到。實際上 Gmail 對寄件人驗證的要求逐年提高，沒有正確設定 spf dkim dmarc gmail 紀錄的網域，就算內容再客製化，也可能整批被歸到垃圾信夾。這篇文章用實務角度說明三項紀錄怎麼設、怎麼確認、以及哪些設定錯誤最常讓開發信白寄。

為什麼 Gmail 對未驗證的寄件人越來越不客氣

過去幾年 Gmail 逐步把寄件人驗證從「建議」變成事實上的門檻，即使是每天只寄幾十封的 B2B 開發信，只要網域沒有完整的 SPF、DKIM、DMARC 紀錄，系統就會把這視為風險訊號之一，連同內容、寄送節奏、收件人互動一起計算網域信任分數。

對做 B2B 開發信的團隊來說，這代表一個常見誤解：內容寫得再客製化、再有誠意，如果 spf dkim dmarc google 這一層基礎沒打好，信件很可能連被打開的機會都沒有，因為它從一開始就進了垃圾信夾或直接被拒收。

這不是「防止被判定為濫發垃圾郵件的技巧」，而是任何一封從公司網域寄出的商務信件本來就該有的基本配置，就像公司網站需要有效的 SSL 憑證一樣。

SPF、DKIM、DMARC 三項紀錄各自負責什麼、怎麼設定

這三項紀錄分工不同，但都要設定並且互相搭配，才能讓 Gmail 判斷一封信「真的是這個網域授權寄出的」。

SPF（Sender Policy Framework）是在網域的 DNS 加一筆 TXT 紀錄，列出哪些伺服器有權以這個網域名義寄信。用 Google Workspace 寄信時，這筆紀錄至少要包含 Google 的寄件伺服器，例如「v=spf1 include:_spf.google.com ~all」，如果公司還有其他寄信系統（例如 CRM 或行銷工具），也要一併列入同一筆 SPF 紀錄，因為一個網域只能有一筆 SPF TXT 紀錄。

DKIM（DomainKeys Identified Mail）是幫每封信加上一組加密簽章，讓收件方能驗證信件內容在傳輸過程中沒有被竄改。在 Google 管理控制台的「應用程式 → Google Workspace → Gmail → 驗證電子郵件」中產生金鑰，並把系統給的 TXT 紀錄加到 DNS，之後回到管理控制台按下啟用。

DMARC（Domain-based Message Authentication）則是告訴收件方伺服器：如果一封信自稱來自這個網域，卻沒通過 SPF 或 DKIM 驗證，該怎麼處理，並把結果回報到指定信箱。建議新網域先用「v=DMARC1; p=none; rua=mailto:網域管理者的信箱」觀察一到兩週的報表，確認沒有誤判之後，再逐步把政策收緊為 quarantine，最後才是 reject。

• SPF：DNS 加一筆 TXT 紀錄，列出所有有權寄信的伺服器
• DKIM：在 Google 管理控制台產生金鑰並加到 DNS，再回控制台啟用
• DMARC：先用 p=none 觀察報表，確認正常後再逐步收緊政策
• 三項紀錄的網域對齊（From 網域與實際寄送網域一致）也要一起檢查

設定完成後，如何確認 spf dkim dmarc 真的生效

加完 DNS 紀錄不代表已經生效，DNS 傳播需要時間，設定語法也很容易有小錯誤（例如多了一個空格、include 寫錯網域），所以一定要實際驗證，而不是設定完就假設沒問題。

最直接的方式是用 Google 提供的 Admin Toolbox（Check MX / Check SPF 等工具）逐項確認，也可以寄一封測試信到自己的 Gmail 信箱，打開信件的「顯示原始郵件」，查看 Authentication-Results 這一行，裡面會清楚寫出 spf=pass、dkim=pass、dmarc=pass 或 fail，這是最接近 google spf dkim dmarc checker 實際判斷結果的方式。

另外強烈建議註冊 Google Postmaster Tools，把寄送網域加進去，它能顯示網域信譽、垃圾信回報率、IP 信譽等指標，是持續監控 spf dkim dmarc check google 是否穩定運作的免費工具，也是判斷是否可以逐步提高寄送量的依據。

常見錯誤：讓驗證紀錄形同虛設的做法

看過不少團隊其實三項紀錄都「有設」，但因為幾個細節沒處理好，等於白設定。

最常見的問題是網域下同時存在兩筆 SPF TXT 紀錄（例如舊系統的紀錄沒刪掉），DNS 標準規定一個網域只能有一筆 SPF 紀錄，兩筆並存時驗證結果通常直接判定失敗，比完全沒設定更糟。

• 同一網域有多筆 SPF TXT 紀錄，互相衝突
• DKIM 金鑰只在測試網域啟用，正式寄送網域忘記啟用
• DMARC 直接設 p=reject，卻沒有先觀察報表，導致合法信件也被擋
• From 顯示的網域跟實際寄送伺服器不對齊（例如用第三方工具但 From 填公司網域）
• 用個人 Gmail 帳號（非 Google Workspace 網域信箱）大量寄送開發信，這種帳號本來就沒有網域層級的 SPF／DKIM／DMARC 可言

在台灣做 B2B 開發信，個資法怎麼看待這件事

驗證紀錄解決的是「技術上這封信是不是合法網域寄出的」，但收件人對這封信的觀感、以及公司在個人資料保護法下的義務，是另一個層面的問題，兩者都要顧到才算完整。

依據個人資料保護法第二十條規定，非公務機關利用個人資料行銷時，如果當事人已表示拒絕接受行銷，就必須停止利用其個人資料繼續行銷；因此每一封 B2B 開發信都應該提供明確的退出方式，收到退出要求後也要確實從名單中移除，這件事跟 SPF、DKIM、DMARC 設定得再完善都無關，是獨立的法遵要求。

從公開商業資訊（公司官網、名片、公開職稱）取得的商務聯絡窗口資料，用於個案化的 B2B 業務接觸，通常屬於合理的特定目的範圍內利用；但仍建議在信件內容中清楚說明寄件目的與退出方式，這也是收件人判斷「這是正常業務接觸」還是「可疑群發信」的重要線索。

LDM 在正式寄送前怎麼做這道檢查

在幫客戶啟動任何一波 B2B 開發信之前，LDM 會先確認寄送網域的 SPF、DKIM、DMARC 是否完整設定並且互相對齊，如果客戶是新網域或新的 Google Workspace 帳號，會建議先安排一段暖身期，用漸增的小量寄送讓網域累積正常寄件紀錄，而不是一開始就大量寄出。

同時會持續追蹤 Google Postmaster Tools 的信譽指標與退信率，一旦發現異常（例如某天退信率突然升高），會先暫停該網域的寄送，排查原因後再繼續，而不是硬著頭皮繼續寄，讓問題擴大到整個網域信譽。

常見問題