電子郵件網域檢查不等於投遞測試

郵件網域檢查可以顯示已發布的 DNS 紀錄，但無法證明某封郵件通過驗證、成功送達或進入了收件匣。應將每項結果視為對某個網域在特定時間的一次觀察，再根據真正想解決的寄信問題，選擇下一項檢查。

開始行銷活動前，創辦人執行檢查工具，看到了幾項正常結果，很容易就想宣布郵件已準備就緒。但接收郵件、發布寄件政策、替郵件簽章，以及讓收件者收到郵件，是不同的環節。

我們於 2026年10月16日 使用 FounderOmni 的公開郵件網域檢查工具檢查了 founderomni.com，並將選填的 DKIM 選擇器留白。這次結果可以說明如何解讀設定證據，而不將它視為郵件送達的證明。檢查過程沒有寄出郵件，也沒有更改任何 DNS 設定。

先確認實際要求檢查的內容

解讀狀態標記前，先記錄網域和輸入參數。根網域與用於寄信的子網域不一定發布相同的紀錄。未提供 DKIM 選擇器的檢查，與檢查服務商指定選擇器的請求也不相同。

我們的結果標記為紐約時間上午 10:00 完成檢查。介面說明，檢查可能重複使用過去五分鐘內的結果。這個時間戳記描述的是本次觀察，並不保證全球所有解析器在同一時刻都能看到相同資訊。

介面顯示的結果如下：

• MX：Found（已找到）。 回應將 mx1.spacemail.com 和 mx2.spacemail.com 列為接收郵件的目標伺服器。
• SPF：Found（已找到）。 傳回的文字以 v=spf1 開頭，在結尾的 ~all 之前包含兩個服務商參照。
• DMARC：Review（需檢查）。 傳回的紀錄是 v=DMARC1; p=none;。
• DKIM：Not checked（未檢查）。 說明為「No selector supplied」（未提供選擇器）。

每一列回答的都是各自的問題。「Not checked」說明本次執行缺少輸入，並不能證明該網域沒有 DKIM 金鑰。「Found」表示工具取得了一筆相符紀錄，不代表寄件者及其每封郵件都通過完整的協定驗證。

下圖整理了觀察到的結果及其適用範圍。這是針對本次檢查製作的原創說明圖，並非工具介面的重製。你也可以查看實際保存的詳細結果截圖。

也應區分查詢失敗與紀錄不存在。如果請求無法完成，有用的下一步是調查這次失敗，或透過正常操作再次嘗試。把無法取得的結果寫成「缺漏」，會憑空製造一個尚未證實的設定問題。

區分已發布的紀錄與正常運作的郵件

MX 紀錄說明傳入郵件應送往何處，並不授權外寄行銷郵件的寄件方。可用結果核對收信設定是否符合預期服務商的要求，而不能把它當作品牌所有郵件的驗證標記。

SPF 發布與相應寄信身分有關的授權資訊。SPF 規範說明了涉及 SMTP 信封寄件者和寄送 IP 位址的檢查。找到紀錄文字是一項觀察；使用正確輸入驗證真實寄件者，則是另一件事。

我們的公開檢查工具明確說明，它沒有評估寄送 IP，也沒有執行遞迴 SPF 規則。因此，介面中的服務商參照不能證明團隊使用的每項服務都已獲授權、完整政策適用於每條寄送路徑，或某封郵件通過了驗證。應先核對實際服務商設定，再決定需要更改什麼。

DKIM 需要另一項背景資訊。它的選擇器機制允許同一簽章網域使用不同的公開金鑰，因此服務商實際使用的選擇器很重要。隨意猜一個選擇器後查不到紀錄，不能證明所有可能的選擇器都不存在。

本例中，我們刻意不提供選擇器。下一步應向寄信服務商取得正確的值，或從有權查看的郵件簽章資訊中取得。即使之後成功查到金鑰，也只能說明公開金鑰資訊已發布，無法驗證某封郵件的簽章是否正確。不要將簽章私密金鑰輸入公開檢查工具。

DMARC 將驗證結果、使用者可見的寄件網域和網域所有者的政策連結起來。在規範列出的政策值中，none 表示不要求特定的投遞處理；它不要求拒絕驗證失敗的郵件，僅有這項紀錄也無法證明驗證已達成對齊。

傳回的紀錄也沒有用來接收彙總報告的 rua 位址。把政策稱為「監控模式」，不應等同於團隊已在接收報告：報告接收位址及其收集流程都需要另外驗證。本次檢查沒有查看任何私人報告服務或信箱。

不要只為了消除「需檢查」標記，就把監控政策改為強制執行政策。應與網域管理人員共同核對合法的寄送路徑和相關證據。設定變更需要實際維運理由，而不只是讓概覽看起來更整齊。

依據真正需要回答的問題選擇下一項檢查

先提出明確的問題。要調查「這次查詢是否已顯示我們的 DNS 修改」，需要準確的網域、紀錄名稱、傳回值及檢查時間；要回答「我們的行銷郵件是否通過驗證」，需要實際寄送路徑和郵件的證據；要回答「收件者是否收到郵件」，則需要送達紀錄或收件者端的證據。

進行獲授權的郵件測試時，應將寄件者、收件者、服務商、時間及相關驗證結果記錄在一起。服務商接受郵件的事件、收件伺服器的回應，以及收件者實際看到郵件，是不同的觀察。不能將其中一項當作三項，也不能認為郵件被接受就證明它進入了收件匣。

如果郵件未如預期送達，應保留失敗細節，而不是重複執行無關的 DNS 檢查，直到出現綠色結果。應查看服務商實際記錄的事件或回應，以及經授權可取得的目標收件者端證據。這樣才能找出需要繼續調查的具體環節。

一份簡短的交接紀錄可以包含：

• 問題： 需要確認的設定、驗證或送達事實。
• 範圍： 準確的網域、已提供的選擇器，以及相關的寄送路徑。
• 觀察： 傳回的紀錄或實際郵件證據，以及對應的時間戳記。
• 未知項目： 所選檢查沒有評估的部分。
• 下一步： 接著要查看的服務商設定、特定查詢或獲授權郵件的結果。

這樣的紀錄能協助小團隊避免在各自檢查不同內容後，互相傳遞籠統的「郵件正常」結論。私人郵件標頭、位址和帳戶資訊應保留在日常安全流程中，只分享調查所需的資訊。

確認寄送路徑後，郵件本身仍需協助讀者採取行動。我們的歡迎郵件指南介紹了另一個獨立任務：把第一個有用的操作說清楚。清楚的文案和已發布的 DNS 紀錄，都無法取代真實郵件傳送過程的證據。