2026 獨立站訂單郵件進垃圾箱，先查 SPF 還是 DKIM？

判斷：適合先查第三方發信服務的傳送紀錄，再依結果檢查 SPF、DKIM 與 DMARC；不要看到訂單郵件進垃圾箱就先改 DNS。如果服務商沒有該封郵件的紀錄，先查網站是否觸發通知；若已記錄傳送，才沿著回應狀態與網域驗證排查。SPF、DKIM 的郵件投遞（email deliverability）檢查只能協助定位問題，認證通過也不保證進入收件匣。

本文適合需要處理訂單確認或出貨通知未送達的跨境電商站長，以及近期更換第三方發信服務或調整 DNS 的技術負責人。
若你維護多個業務網域，可逐一核對各網域的 From 地址、認證結果和發信紀錄；不必先把問題歸因於伺服器。

最後更新於 2026 年 11 月 5 日；資料核實自 Gmail 發件人指南、RFC 9989 與 WooCommerce 郵件排障文件。

先分清未觸發與未送達，再談認證

顧客說沒收到訂單郵件，不足以證明 SPF 或 DKIM 設定錯誤。WooCommerce 的郵件工作流程可能卡在通知觸發、主機郵件函式、第三方服務傳送或收件端過濾等不同環節；官方排障文件亦建議分開檢查郵件是否產生及是否送達。WooCommerce 郵件排障說明

先確認訂單狀態，再檢查 WooCommerce 對應通知是否啟用、是否有郵件紀錄。如果紀錄不存在，應先查應用程式端；如果第三方發信服務顯示已接收或傳送，才開始檢查服務商回應與郵件標頭。訂單郵件的每一個環節都需要證據，單看顧客的收件匣或網站前台提示無法判定故障位置。

第一階段：核對實際發信來源，不照抄 DNS 範例

使用第三方郵件服務後，SPF 紀錄應反映目前實際使用的發信來源；如果網域還有其他服務寄出郵件，也要盤點並納入評估。不要複製網路上其他服務商的 include: 值，亦不要在同一網域重複發布多筆 SPF 政策紀錄。RFC 7208 說明了 SPF 紀錄的發布與評估規則；最終應以你所用服務商的 DNS 指引及郵件標頭結果核實。RFC 7208：SPF 標準

你可以先查目前公開的 TXT 紀錄，再與服務商後台要求逐項對照：

dig +short TXT your-domain.example

輸出示意：

"v=spf1 include:<服務商提供的授權網域> ~all"

這只是格式示意，不是可直接使用的設定值。尖括號中的內容必須由實際發信服務商提供；若網域另有網站通知、客服或其他合法寄件來源，變更前也要確認該來源是否仍在使用。

接著寄出測試信，檢查完整郵件標頭中的 SPF 結果。DNS 查得到一筆紀錄，不代表實際寄件通過驗證；真正要確認的是收件端檢查該封郵件時取得的結果，以及它對應的寄件網域。

第二階段：分開看 DKIM 通過與 From 網域對齊

DKIM 是郵件上的簽章驗證：標頭會提供簽章網域等資訊，收件端再依網域 DNS 中的公開金鑰檢查簽章。RFC 6376 定義了 DKIM 的簽章與驗證方式。RFC 6376：DKIM 標準

DKIM 顯示通過，不代表使用者看到的 From 網域已與 DKIM 簽章網域對齊。請在同一封測試郵件中分別記下：

• 使用者看到的 From 網域。
• 郵件標頭中 DKIM 簽章的 d= 網域及驗證結果。
• SPF 驗證所檢查的寄件網域及結果。
• DMARC 對這些結果與 From 網域的對齊判定。

Google 的發件人指南列出 SPF、DKIM、DMARC 及對齊要求，並區分一般寄件者與每日向 Gmail 寄送超過 5,000 封郵件的寄件者條件。這個門檻是 Gmail 指南中的適用條件，不可推論成所有收件平台通用的規則；請按實際收件平台及寄信情況核對。Google 發件人指南

DMARC 先盤點發信來源，再調整政策

DMARC 的設定應配合實際使用的寄件網域、SPF 和 DKIM 結果判斷。若你尚未盤點正常業務郵件的發信來源，就直接收緊政策，可能讓原本合法的交易通知或其他業務郵件遇到拒收或隔離風險。先確認哪些服務仍在替該網域寄信，再評估監測結果與處置策略。

RFC 9989 於 2026 年 5 月發布，取代 RFC 7489 與 RFC 9091，是 DMARC 標準文件更新；這項更新本身不代表你的獨立站必須改用自建郵件伺服器，也不等於所有收件平台新增了相同的強制要求。RFC 9989：DMARC 標準

可用以下方式查看網域發布的 DMARC TXT 紀錄：

dig +short TXT _dmarc.your-domain.example

查詢結果可協助你確認紀錄是否存在，但仍須與郵件標頭的 SPF、DKIM、DMARC 結果及服務商文件對照。WooCommerce 亦提供郵件認證相關說明，設定值應按實際採用的發信服務及網域配置確認，而不是從其他服務複製。WooCommerce 郵件認證說明

按故障證據選擇修正方向

完成基本檢查後，按以下條件分流。這份決策表的目標是先找到負責的環節，再決定要修網站、DNS 還是請服務商查投遞；不要在沒有證據時反覆修改多項設定。

• 若網站及郵件紀錄都沒有該封郵件，先查訂單狀態、WooCommerce 通知設定與應用程式日誌；否則不要先修改 SPF 或 DKIM。
• 若網站有事件、第三方服務商沒有傳送紀錄，先核對網站使用的服務商設定及服務商端的接收狀態；取得服務商紀錄後，再決定是否需要修正 DNS。
• 若服務商有傳送紀錄，郵件標頭顯示認證失敗，按該服務商的 DNS 文件修正相應紀錄，再寄出測試郵件核對結果。
• 若 SPF、DKIM 通過，但 DMARC 未通過或對齊失敗，先核對 From、SPF 驗證網域與 DKIM d= 網域，不要只看「pass」字樣。
• 若認證與對齊均通過，收件人仍未收到，請向服務商提供傳送時間、服務商回應與郵件標頭，並請收件人檢查垃圾郵件或隔離區。

WooCommerce 提供第三方郵件服務商設定說明；使用何種服務及 DNS 設定值，應以你實際採用的服務商文件為準。WooCommerce 郵件服務商設定說明

進行實測時，可建立測試訂單並寄往不同收件服務，逐封保存訂單狀態、服務商事件、收件端回應及郵件標頭。不要只測一封就把結果泛化到所有收件平台；若問題只在特定收件端出現，應把該平台回應也交給第三方發信服務商協助判讀。

如果你同時在檢查網站的訂單處理流程，可參考訂單郵件與訂單流程檢查說明；若需要釐清伺服器租用與郵件發送服務的責任範圍，也可查看伺服器服務範圍說明。

常見問題

獨立站訂單通知進入垃圾郵件，從哪裡開始查？

先確認訂單有沒有觸發通知，再看網站郵件紀錄及第三方發信服務是否有該封信的事件。沒有事件時先查應用程式；已有服務商傳送紀錄時，再查拒收回應、收件端隔離，以及郵件標頭中的 SPF、DKIM 和 DMARC 結果。

顧客沒收到，但服務商顯示已傳送，接下來怎麼辦？

保存服務商事件、時間與回應資訊，請收件人檢查垃圾郵件或隔離區，並核對郵件標頭。若服務商只能確認已交付給收件端，仍不能據此證明郵件已進入收件匣；將可辨識的紀錄提供給服務商，確認是否有退信、拒收或其他投遞狀態。

使用第三方發信服務，仍要設定 SPF 和 DKIM 嗎？

按實際服務商的要求設定，並核對郵件標頭中的 SPF、DKIM 結果。DNS 設定應對應目前真正寄出郵件的服務；若同一網域仍有其他合法發信來源，也要先盤點，不能直接套用其他服務商的範例值。

DMARC 顯示通過，訂單通知還是進垃圾郵件，原因可能是什麼？

DMARC 通過不等於收件平台保證放行。請同時檢查收件端的垃圾郵件或隔離資訊、第三方服務商事件、郵件標頭及收件人回報；若不同收件平台結果不一，應分開記錄並將相應回應交由服務商協助分析。

下一步先依故障分流確認郵件是在網站端未產生、服務商端未傳送，還是收件端未放行。若你也在評估獨立站遷移，可先把測試訂單、第三方發信設定及 DNS 驗收納入遷移檢查；租用 OSFP Cloud 的 AMD 獨立伺服器可承載網站應用，但郵件認證與實際投遞仍由第三方發信服務及網域 DNS 設定決定，不能把伺服器租用視為郵件發送或收件匣保障。

常見問題

獨立站訂單通知掉進垃圾郵件，應該先看哪裡？

先查訂單是否完成、WooCommerce 通知是否啟用，以及郵件紀錄中有沒有該封信。如果應用程式沒有建立郵件事件，先處理觸發或程式問題；若第三方發信服務已記錄傳送，再查服務商回應、收件端狀態與 SPF、DKIM、DMARC 結果。

服務商顯示已寄出，但顧客仍說沒收到，怎麼追查？

「已寄出」不等於收件端已放進收件匣。請保存寄送時間、收件地址、服務商事件紀錄與退信或拒收回應，再請收件人檢查垃圾郵件、隔離區及公司郵件閘道；同時用測試訂單寄到不同收件服務，對照郵件標頭中的認證結果。

改用第三方郵件服務後，網域還需要 SPF 和 DKIM 嗎？

通常需要按實際服務商提供的 DNS 指引完成授權與簽章設定，但不能直接複製其他服務的紀錄值。核對寄件網域、SPF 查詢結果、DKIM 簽章網域及 From 網域是否符合服務商要求，再用實際寄出的郵件標頭確認，不要只以 DNS 已新增紀錄作為完成證明。

SPF、DKIM 和 DMARC 都顯示通過，為什麼還會進垃圾郵件？

這些結果只說明特定網域驗證及對齊檢查的結果，不能保證收件平台接受郵件或放入收件匣。仍須查收件端隔離與拒收資訊、第三方服務商事件、寄件內容及收件人回報；DMARC 通過也不會取代這些投遞檢查。