重點摘要
設定您的 SPF 記錄
-all（硬性失敗）
適用於大多數設定。未列在 SPF 記錄中的伺服器會被標示為身分驗證失敗。
~all（軟性失敗）
來自未列出伺服器的郵件會被接收，但會加上標記。適合在改用嚴格設定前測試新的 SPF 記錄。
查詢次數上限
SPF 記錄有 10 次 DNS 查詢的上限，超過就會失敗。使用這個工具確保不超出上限。
如何建立不會擋掉合法郵件的 SPF 記錄
SPF 記錄是發布在根網域上的 TXT 記錄，用來告訴收件信箱哪些系統獲准代表該網域寄信。這份清單通常包括團隊郵件使用的 Google Workspace 或 Microsoft 365、寄送電子報的電子郵件服務商、寄送收據與密碼重設信的交易型郵件服務，有時還包括 CRM 或業務互動平台。
建立 SPF 最安全的做法，是在改用硬性失敗政策前，先盤點所有寄件來源。檢查您的電子郵件服務商、CRM、客服系統、帳單系統、產品應用程式，以及任何從同一網域或子網域寄信的陌生開發工具。如果 SPF 漏掉某個寄件服務，信箱服務商可能會把原本合法的郵件視為未經身分驗證。
SPF 也有實際限制：像是 include:， a， mx， exists及redirect這類機制會觸發 DNS 查詢，而 SPF 評估最多只能進行 10 次 DNS 查詢。看起來乾淨但超過上限的記錄，可能在信箱評估時失敗。請讓記錄保持精簡、避免重複的 include，並在不同團隊或工具需要各自的寄件設定時使用專用子網域。
彙整所有以您網域名義寄信的服務，包括收件匣郵件、電子報、應用程式通知、發票與業務工具。
加入需要的 IP 與 include 網域，選擇失敗政策，然後複製產生的 SPF 值。
發布記錄，等待 DNS 生效，再用 SPF 檢查工具與 DMARC 檢查工具確認結果。
SPF 與 DKIM、DMARC 及名單品質的關係
SPF 不可或缺，但它不是送達率設定的全部。 DKIM 會為郵件簽章，讓收件伺服器確認郵件寄出後未遭更改。 DMARC 會告訴信箱服務商，當 SPF 或 DKIM 與可見的寄件者（From）網域不一致時該如何處理。這些記錄共同幫助信箱判斷郵件是否經過授權。
身分驗證無法讓不良名單變得安全。如果寄給過時、拼錯或有風險的地址，即使身分驗證通過，退信率與投訴訊號仍會損害寄件者信譽。對於行銷活動與 CRM 匯出檔，寄送前請先使用免費電子郵件驗證工具或大量驗證檢查名單。退信率低於 3% 屬於健康範圍；3-5% 需要清理與檢視；高於 5% 對寄件網域而言屬於高風險。
如果團隊有多個寄件服務，請在發布變更前記錄每個 include 的負責人。這樣日後移除廠商、新增子網域，或寄件平台更改建議的 SPF include 時，稽核起來會更容易。
SPF 產生器常見問題
SPF 記錄要發布在哪裡？
將產生的值以 TXT 記錄發布在寄件用的根網域上，例如 example.com。如果從子網域寄信，請改為發布在該子網域上。
應該使用 -all 還是 ~all？
當您確定記錄已包含所有合法寄件服務時，使用 -all。在盤點或遷移期間則使用 ~all，因為它在設定過程中會給信箱服務商較溫和的訊號。
一個網域可以有多筆 SPF 記錄嗎？
不行。一個網域應只有一筆 SPF TXT 記錄。如果存在多筆 SPF 記錄，收件伺服器可能會回傳永久錯誤。請將所有寄件服務合併到單一記錄中。
已設定 SPF，還需要 DKIM 和 DMARC 嗎？
需要。SPF 授權寄件者，DKIM 為郵件簽章，DMARC 則將身分驗證與網域政策連結起來。這三種記錄共同建立現代信箱服務商所需的信任。