Defaults.Exposed

Defaults.Exposed › 修復 › SPF（發件人策略框架）

如何修復 SPF（發件人策略框架）

SPF 是寫在你網域設定裡的一行規則，用來聲明哪些郵件服務有權以你公司的名義發郵件。沒有它，全世界任何人都能冒充你發郵件——而你自己發出的正經郵件，反而更容易被丟進客戶的垃圾箱。

對您業務的關鍵影響： 任何人都能冒充你的公司給你的客戶、員工和供應商發郵件——偽造發票、改收款帳戶，無所不能。與此同時，你真正發出的報價和發票卻更容易被當成垃圾郵件，生意就這樣悄無聲息地黃了。

這會讓您付出什麼代價

為什麼它重要。 偽造郵件的「發件人」地址輕而易舉，攻擊者一分錢都不用花。SPF 是最便宜、最快讓你的網域更難被冒充、並讓你的正經郵件不落入垃圾箱的方法。Gmail 和 Yahoo 現在會主動把未通過身份驗證的網域郵件丟進垃圾箱甚至直接拒收，所以這早已不是可選項——它是郵件能否被送達的基本門檻。

一句話說清楚

眼下，除非你正確設定了 SPF，否則全世界任何人都能發出看似來自你公司的郵件。他們可以給你的客戶發假發票，給你的員工發假付款請求，假冒你給供應商發信——而這些郵件看起來都像真的，因為你的網域上沒有任何東西能證明它們是假的。

SPF（發件人策略框架）就是解藥。它是寫在你網域設定裡的一行文字，列出實際有權以你名義發郵件的郵件服務。收件的郵件服務商——Gmail、Outlook，所有人——在判斷一封郵件是真是假之前，都會先查這份清單。沒有清單，或清單太弱，他們就無從判斷。

本頁講兩件必須同時做對的事：究竟有沒有 SPF 記錄，以及它是否嚴格到足以真正發揮作用。

這會讓你付出什麼代價

下面是缺失或孱弱的 SPF 記錄在現實中一點點蠶食你的金錢與信任的日常方式。我們從不點名任何真實企業——這些都是我們在資料裡反覆看到的套路。

貫穿所有這些的一條線：攻擊者一分錢不花，而代價和罵名都由你的公司來扛。

它到底是什麼

當一封郵件抵達時，收件郵件伺服器只想知道一件事：這封郵件真的來自它所聲稱的那個人嗎？ SPF 回答了這個問題的一部分。

你在網域的 DNS 設定裡發布一行簡短的文字——一條「TXT 記錄」——列出獲准代你發信的郵件服務。大致長這樣：

v=spf1 include:_spf.google.com include:sendgrid.net -all

用大白話說就是：「我們真正的郵件來自 Google 的伺服器和 SendGrid 的伺服器——其他任何冒充我們的郵件，一律拒收。」

對你的評分而言，關鍵有兩點：

  1. 記錄存在嗎？ 這是大頭（在所有單項郵件檢查中權重最高）。沒有記錄，收件方就沒有清單可對照，冒充門戶大開。這裡還藏著一個隱蔽的失敗模式：如果你的網域有兩條或更多SPF 記錄，規則規定它們全部無效——所以你實際上等於完全沒有 SPF，儘管表面看上去有。

  2. 策略夠嚴格嗎？ 記錄可以存在，卻毫無牙齒。結尾——那個「all」機制——就是給收件方的指令：

    • -all（硬失敗）——拒收清單之外的一切。最強。滿分。
    • ~all（軟失敗）+ DMARC 設為 reject——如今推薦的現代設定。保護力等同硬失敗，又沒有合法轉發郵件被退回的風險。滿分。
    • ~all + DMARC 設為 quarantine——可接受，略弱；把 DMARC 改成 reject 才能獲得完整保護。
    • 單獨的 ~all（無 DMARC 強制執行）——弱。它的意思是「大概是假的，但還是收下吧」。偽造郵件照樣能進。這正是許多企業自以為受到保護卻落入的陷阱。
    • ?all（中立）——不提供任何保護。
    • +all——主動作死：它告訴全世界任何人都可以冒充你發信。永遠別用。

還有一個隱形的失敗：SPF 被評估時，最多只允許觸發 10 次 DNS 查詢。堆疊太多 include: 條目就會超出這個上限，此時收件方會把整條記錄當作失效——你又回到了毫無保護的狀態。對那些使用大量行銷和 SaaS 工具的企業來說，這是個常見而隱蔽的問題。

「好」長什麼樣： 有且僅有一條 SPF 記錄，列出所有合法以你名義發信的服務，以 -all 結尾（或用 ~all 搭配 p=reject 的 DMARC），並且舒舒服服地保持在 10 次查詢的上限以內。

如何修復（免費，約 10 分鐘）

把這一節交給管理你網域或網站的人——並請注意修復是免費的。 這是改一個 DNS 設定，不是要你買什麼產品。我們只對長期監控它是否保持正確收費，而不對這次改動收費。

第 1 步——列出所有以你名義發郵件的服務。 這是大家最容易出錯的地方。把它們全寫下來：你的郵箱服務商（Google Workspace、Microsoft 365 等），加上任何郵件行銷工具、CRM、客服系統、電商平台、開票／會計應用和預訂系統。如果某個服務帶著你的名字發信，你卻把它忘了，那麼當你收緊策略時，SPF 就會攔下它的郵件。

第 2 步——在你的根網域發布一條 TXT 記錄。 把你所有發件方的「include」行合併到一條記錄裡。常見平台對應如下：

合併後的記錄長這樣：

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

按服務商分，在哪裡添加：

第 3 步——先穩妥，再強制。 在你確認發件方清單完整之前，先用 ~all（軟失敗）發布，這樣不會誤傷任何合法郵件。一旦確認你所有正經郵件仍然暢通，再收緊到 -all（硬失敗）——或者更好，保留 ~all 並加上 p=reject 的 DMARC 策略，這是推薦的現代組合。

第 4 步——確保你只有一條記錄。 如果已經存在一條舊的 SPF 記錄，就編輯它，而不是再加一條。兩條 v=spf1 記錄會互相抵消，讓你毫無保護。

第 5 步——盯緊查詢次數。 如果你發件方很多，可能會衝破 10 次查詢的上限。一旦如此，就合併精簡——有些服務商提供「SPF 扁平化」，或者乾脆刪掉你不再使用的發件方。

第 6 步——重新檢測你的網域，確認它現在已通過：記錄存在，策略嚴格。

常見錯誤

它在哪裡發揮作用

SPF 是地基，但它只是三層中的一層。DKIM 加上一個加密簽名，證明郵件沒被篡改；DMARC 是把 SPF 和 DKIM 串起來的指令，告訴收件方對驗證失敗的郵件實際該怎麼處理——包括攔截對你客戶所看到的那個可見「發件人」名稱的冒充。先把 SPF 做對（它是最快的勝利，權重也最大），再補上 DKIM 和 DMARC，徹底關上這扇門。這三項修復都是免費的。

在您的託管服務商上完成設置

熱門服務商的分步指引：

常見情況

常見問題

我不懂技術——這個我自己能搞定嗎？

你不需要弄懂細節。這個改動就是往你的網域設定裡加一兩行字，由管理你網站的人或你的 IT 服務商來做。把下面的「如何修復」一節交給他們就行——通常幾分鐘搞定，而且是免費的。我們只收取長期監控它是否保持正確的費用。

我們已經有 SPF 記錄了——這不就夠了嗎？

不一定。有記錄只是上半場；把它設置得足夠嚴格才是下半場。一條以「~all」（軟失敗）結尾、背後又沒有 DMARC 的記錄，等於在告訴收件伺服器「這可能是假的，但還是收下吧」——保護幾乎為零。兩條 SPF 記錄，或一條查詢次數過多的記錄，會被判定為失效，看上去存在卻毫無保護。兩個環節都得對。

修復這個會不會不小心搞壞我自己的郵件？

如果記錄漏掉了某個合法的發件方就有可能——比如以你名義發郵件的開票應用或郵件行銷工具。這正是為什麼穩妥的做法是：先把所有以你名義發郵件的服務全部列出來，先用寬鬆的「~all」發布，確認沒有遺漏後，再收緊到硬失敗。按這個順序來就不會出問題。

「~all」和「-all」有什麼區別，我們該用哪個？

「-all」（硬失敗）告訴收件方拒收任何不在你清單上的郵件——最強的設定。「~all」（軟失敗）則說「大概不合法，但還是先收下」。如今的最佳實踐推薦用「~all」配合 DMARC 策略為「reject」——這一對組合既能提供與「-all」相同的保護，又不會有轉發郵件被退回的風險。單獨用「~all」、背後沒有 DMARC 強制執行，才是要避免的弱設定。

SPF 單靠自己就能阻止所有郵件偽造嗎？

不能——它是必不可少的第一層，但不是全部答案。SPF 聲明哪些伺服器可以替你發郵件，但它不告訴收件方在郵件驗證失敗時該怎麼做，也管不到使用者看到的那個可見「發件人」名稱。要徹底鎖死冒充，你還需要 DKIM 和 DMARC。SPF 是最快、收益最高的第一步，所以從這裡開始，再補上另外兩個。

多久會生效，會不會要花錢？

DNS 改動通常幾分鐘到幾小時內生效。修復本身永遠免費——只是在你的 DNS 服務商那裡改個設定而已。如果有人告訴你加一條 SPF 記錄需要購買付費產品，那是錯的。