嗨，我是凱文大叔。
上一期講了 MX、SPF、DKIM、DMARC 各自在回答什麼問題。
但知道它們在做什麼，跟「設定真的有生效」是兩件事。
這幾個設定有個很麻煩的特性：它們壞掉的時候不會很大聲。 沒有錯誤訊息、沒有退信、後台照樣顯示 sent，信也照樣寄得出去。你唯一會察覺的時機，是某天發現開信率掉了一半。
今天講三件事：兩個最常見的無聲失效、一個最多人卡住的判定規則，以及三分鐘的自我檢查。
陷阱一：SPF 只能有「一筆」
這是最常見也最致命的。
網域上可以有很多筆 TXT 紀錄——Google 驗證碼、各種服務的驗證字串都是 TXT，這完全沒問題。但其中只能有一筆是 v=spf1 開頭的。
如果有兩筆，收件方會回報 PermError，結果是兩筆都不算數——不是取第一筆，不是取比較嚴格的，是整個失效。
❌ 錯誤示範
TXT @ v=spf1 include:_spf.google.com ~all
TXT @ v=spf1 include:sendgrid.net ~all
✅ 正確做法：合併成一筆
TXT @ v=spf1 include:_spf.google.com include:sendgrid.net ~all
所以每次新增寄信服務，你要做的是「編輯既有那一筆」，不是「新增一筆」。
問題是，很多服務商的說明文件就是寫「請新增一筆 TXT 紀錄」。如果你的網域上已經有 SPF，照做就爆了。
我自己的網域就這樣中過招：加了一個收信轉寄服務，照著它的文件操作，結果原本用來寄信的 SPF 被蓋掉了。而因為信還是寄得出去，完全沒有徵兆——直到我自己去查才發現。
順便講一下結尾那個符號
SPF 最後的 all 前面有個符號，決定「不在名單上的寄件者」怎麼處理：
-all（Fail）：不在名單上的，一律當偽造~all（SoftFail）：可疑，但先別直接丟掉?all（Neutral）：不表態，幾乎等於沒設+all：誰都可以用我的網域寄信——絕對不要用
建議從 ~all 開始，確認沒漏掉任何合法來源之後，再改成 -all。
直接上 -all 的風險是：你可能忘記某個系統也在用這個網域寄信——客服系統、發票系統、CRM、監控告警——一改就全部消失。
工商時間不講Hahow線上課了，大家都已經被轟炸好幾天 |