寄出的行銷信被 Gmail 丟進垃圾郵件、客戶抱怨電子報老是漏收，問題往往不出在文案，而是網域寄信身分沒說清楚啊SPF（Sender Policy Framework）正是讓收件端確認「這封信真的來自我家網域」的第一道關卡，透過 DNS 中的 TXT 紀錄列出授權寄信主機，收件伺服器便能比對寄件來源是否偽造.說真的這年頭沒設真的母湯
邁入 2026 年，Google、Microsoft 與 Yahoo 對大量寄件者的驗證要求只會更嚴，金融與交易通知信件更常因 SPF 缺失而遭攔阻本文從 SPF 的運作原理談起，說明它與 DMARC、DKIM 的分工，並整理SPF 設定時的常見錯誤與查覈方式，協助你守住寄件聲譽
SPF防止網域被偽冒寄信
SPF 到底是什麼？為什麼 2026 年更該在意？
SPF 全名是 Sender Policy Framework，中文常翻成「寄件者政策框架」它是一筆掛在你網域 DNS 上的公開紀錄，用途很單純：告訴全世界「會用我這個網域寄信的伺服器，只有這些喔」當收件端的郵件系統收到一封聲稱來自你網域的郵件時，就會回頭查這筆紀錄，確認寄件來源的 IP 有沒有在名單裡
這項技術問世已經超過二十年，但 2026 年的攻擊生態讓它變得更關鍵現在的釣魚郵件不再是那種一眼就看穿的破綻百出，很多攻擊者會直接偽冒你的網域寄信給你的客戶、供應商，甚至內部員工根據業界普遍觀察，未設定 SPF 的網域被偽冒的機率高出好幾倍，而且一旦出事，連帶影響的是品牌信任度——這年頭誰還敢跟一個會寄釣魚信給你的公司做生意？
更現實的是，主流收件平臺這幾年對「未驗證郵件」的態度越來越硬。沒設 SPF 或設定錯誤的郵件，輕則進垃圾桶，重則直接被拒收這已經不是「有設有保庇」的加分項，而是「沒設就等著出事」的基本門檻
SPF 紀錄實際上就是一行 TXT 紀錄，長得像這樣：
v=spf1 include:_spf.example.com ip4:203.0.113.0/24 -all
拆開來看並不難。v=spf1 是開頭標記，告訴系統「這是一筆 SPF 紀錄」，版本二十年沒變過。include: 是把其他網域的 SPF 紀錄拉進來，這是最常用的機制，尤其你用外部寄信服務時，對方會給你一組 include 語法，照抄就對了。ip4: 直接指定 IPv4 的 IP 或網段，對應的 ip6: 則是 IPv6。a 或 mx 代表「跟這個網域的 A 紀錄或 MX 紀錄相同的伺服器都算數」，算是懶人但有效的寫法。結尾的 -all 意思是「不在上面名單裡的，一律不認」，這是 2026 年最建議的結尾方式
很多人會把結尾寫成 ~all（軟性失敗），想說「先觀察看看」。但現在的情勢是，軟性失敗等於給攻擊者留後門，除非你還在遷移期，否則強烈建議直接用 -all與其讓偽冒郵件有機會鑽過去，不如一次到位。啊說到這個，其實我還想到一件事啦——有些人會想說用 ptr 機制，結果 ptr 這東西又慢又不穩，現在根本沒人敢用厚
設定 SPF 的第一步是盤點所有寄信來源，這也是最容易被忽略的一步你的網域可能透過很多管道寄信：公司自己的郵件主機、官網的表單通知、電子報系統、客服平臺、ERP 系統，甚至某個部門偷偷用的行銷工具。漏掉任何一個，下場就是明明你是合法寄信，卻被收件端判定失敗，信直接消失在黑洞裡，有夠扯ㄟ
接著確認 DNS 管理權限SPF 紀錄是掛在 DNS 上的 TXT 紀錄，你需要網域註冊商或 DNS 服務商的管理權限。如果公司網域的 DNS 是委外給某個知名平臺代管，記得跟對方確認誰有權限新增 TXT 紀錄
把盤點出來的來源轉換成 SPF 語法，常見組合大概長這樣：
v=spf1 mx include:_spf.某寄信服務.com include:_spf.另一平臺.com ip4:203.0.113.10 -all
部署後不是馬上生效，DNS 有快取機制，通常要等個幾十分鐘到幾小時設定完成後一定要驗證，用線上的SPF 檢查工具輸入網域，看看解析出來的紀錄對不對更重要的是持續監控：定期檢查寄信失敗率、查看 DMARC 報告，確認沒有漏掉任何合法來源。
說到地雷，每年都有人中，2026 年還是照樣有人中第一個是超過 10 次 DNS 查詢上限——SPF 規範裡有個「10 次查詢」的天花板，include、a、mx、ptr 這些機制每個都算一次，很多人瘋狂 include 結果爆表，整筆紀錄直接失效，CP 值瞬間歸零。第二個是同時存在多筆 SPF 紀錄，一個網域只能有一筆，如果你有兩筆 v=spf1 開頭的 TXT 紀錄，系統會直接判定錯誤，等於白設。第三個是萬用字元亂用，有人想說「全部放行」比較保險就寫了 +all，這等於告訴全世界「任何人都可以冒充我寄信」，比不設還糟糕第四個是忘記子網域，SPF 不會自動套用到子網域，如果 mail你的網域、shop你的網域 這些子網域在寄信，記得各自處理第五個比較隱晦：include 的目標本身也爆表，你 include 的對象如果自己查詢次數過多，也會拖累你，所以要慎選合作夥伴並定期檢查這種 case 真的 loop 不完啦。
SPF 只驗證寄件伺服器 IP，沒辦法處理郵件轉寄的情境，也無法告訴收件端「驗證失敗時該怎麼辦」2026 年的標準做法是 SPF、DKIM、DMARC 三劍客一起上：SPF 負責比對 IP，DKIM 用數位簽章確認郵件內容沒被竄改，DMARC 則是站在最高處下指令，決定驗證失敗時要隔離、放行還是拒收只設 SPF 就像只鎖了大門卻沒關窗蛤你說只設 SPF 不行喔對啊，真的不行，別鐵齒。
站在 2026 年看，SPF 設定的生態有幾個明顯走向。自動化工具越來越普及，很多 DNS 服務商會主動偵測、提醒甚至一鍵修復 SPF 問題，對中小企業是一大福音。收件端對「未驗證來源」的容忍度趨近於零，過去那種「先觀察三個月再說」的佛系做法已經行不通供應鏈安全意識抬頭，企業開始要求合作夥伴必須提供完整的郵件驗證設定，SPF 成為合約裡的標準條款。還有一個值得注意的點：隨著 IPv6 普及，只寫 ip4 的 SPF 紀錄可能涵蓋不全，很多企業在 IPv6 遷移後忘了更新 SPF，導致部分郵件驗證失敗，這種技術債在 2026 年只會越來越常見喔對，順帶一提，真的有人到現在還不知道自己公司有幾筆 SPF 紀錄啦，扯吧
SPF 不是設定完就沒事的裝飾品，而是一筆需要隨寄信架構同步維護的 DNS 紀錄2026 年寄信來源愈來愈分散，重點只有兩件事：確認 SPF 紀錄完整涵蓋所有合法寄件服務（自家郵件主機、Google Workspace、Microsoft 365、行銷平臺等），並把全部送出網域的 IP 與機制收斂在單一紀錄內，避免多筆 SPF 造成查詢失效搞定 SPF 後，別忘了把它和 DKIM、DMARC 一起對齊，三者協同才能通過收件端檢核。
下一步很明確：現在就登入你的 DNS 管理介面，檢查 TXT 紀錄中是否只有一筆 v=spf1 開頭的 SPF，並逐一比對目前實際在用的寄信服務。若你同時使用多個平臺寄信，建議趁這次盤點一次整合，並設定 DMARC 的 rua 報告信箱，讓後續異常來源無所遁形。厚，真的去檢查一下啦，不要又放到明年捏。