電子郵件送達能力檢查
在聲譽之前、在內容之前，收件方只問一個問題：這個網域能證明郵件真的來自它嗎？本檢查讀取這份證明——MX 記錄、SPF 寄件人名單（按收件方的計數方式展開並計數）、位於 _dmarc 的 DMARC 策略，以及常用選擇器下的 DKIM 金鑰——並按維運人員會修復的順序，用通俗語言返回發現。
想持續盯著它？用 myeventwatch 免費監控——到期和停機提醒，無需綁卡。
這項檢查測的是什麼
垃圾郵件過濾從身分開始，因為身分可以在毫秒內查清。當一封郵件聲稱來自某個網域時，接收伺服器會查詢該網域發布的規則。SPF 列出被允許寄送的伺服器。DKIM 提供一個簽章，可用 DNS 中發布的金鑰來驗證。DMARC 要求可見的寄件人網域與這兩種證明中的一種對齊，並說明兩者都不對齊時的懲罰——無、隔離、拒絕。本頁呼叫 sysosx 伺服器上的 GET /api/check/email-auth，它透過健康檢查所用的 DNS 解析器讀取同樣的記錄，並將其轉化為發現：每個通訊協定、每個問題、一個嚴重程度，按值得修復的順序排列。
其中兩個發現值得談談誠實問題，因為這兩處正是檢查器常偽造精度的地方。SPF 查詢計數是真實的：檢查器按接收方適用的相同規則逐項展開 include 和 redirect 鏈，所以它報告的數字就是嚴格的接收方會計算出的數字——包括當記錄隨著供應商更改自己的記錄而悄悄漂移、超過十次查詢上限時。DKIM 結果是一次探測，而不是一次普查：金鑰發布在所有者選擇的選擇器名稱之下，檢查會嘗試常用選擇器，而一個都沒找到並不證明 DKIM 不存在——任何其他選擇器下的金鑰從外部都是看不見的，結果會直截了當地說明這一點，而不是宣稱某個網域未簽章。唯一完整的 DKIM 測試仍然是一封真實郵件及其 Authentication-Results 標頭。
如何閱讀結果
從失敗項開始；它們是垃圾郵件資料夾最喜歡的原因。沒有 MX 意味著該網域根本收不到郵件。沒有 SPF，或 SPF 記錄以 +all 結尾，意味著任何人都可以聲稱自己是你——後者更糟，因為這種聲稱是被官方允許的。多條 SPF 記錄會悄悄使 SPF 評估整體失效。缺少 DMARC 記錄意味著失敗的郵件沒有既定的懲罰，而且同樣代價高昂的是，沒有人在收集那些顯示誰以你的網域寄送的聚合報告——欺騙活動通常就是這樣被發現的。當報告真的到達時，它們以原始 XML 的形式出現；DMARC 報告分析器會在本機開啟 .xml、.gz 和 .zip 檔案，並將其轉化為按來源劃分的表格，顯示誰通過了、誰失敗了以及要修復什麼。警告是中間狀態：p=none 是啟動 DMARC 的好地方，卻是止步的壞地方；~all 是測試模式，不是目的地。然後看畫面的另一半：驗證證明身分，而DNS 黑名單檢查器衡量聲譽——兩者都要執行，因為一個驗證完美的網域如果 IP 被列入名單仍會進垃圾桶，一個乾淨的 IP 如果 SPF 損壞也會如此。把這一切串起來的指南是為什麼你的郵件會進垃圾桶。
常見問題
SPF、DKIM 和 DMARC 是什麼？它們如何配合？
它們是三個透過 DNS 發布的、對「這封郵件真的來自它聲稱的網域嗎？」這一問題的回答。SPF 列出被允許為某個網域寄送的伺服器。DKIM 讓網域對郵件進行加密簽章，使收件方可以用 DNS 中發布的金鑰驗證簽章。DMARC 將它們聯繫起來：它要求可見寄件人標頭中的寄送網域與 SPF 或 DKIM 結果對齊，並告訴收件方當兩者都不對齊時該怎麼做——監控、隔離或拒絕。沒有 DMARC 的 SPF 只是一個未簽章的建議；DMARC 才是把另外兩者變成策略的東西。
三項都通過了，我的郵件為什麼還是進垃圾桶？
因為驗證是入場券，不是座位安排。通過 SPF、DKIM 和 DMARC 意味著收件方相信郵件確實是你的——之後，投放位置取決於聲譽和內容：黑名單列入（用本站的黑名單檢查器檢查）、收件人互動、投訴率、寄送量模式以及郵件本身。驗證失敗是垃圾郵件投放中最常見的可修復原因，這也是為什麼這項檢查排在第一位，但這裡結果乾淨而垃圾郵件投放持續存在，意味著問題出在聲譽或內容上，而不是身分上。
檢查說未找到 DKIM 金鑰。這是否意味著我的網域沒有簽章？
不是——結果本身也用同樣的話說明了這一點。DKIM 金鑰位於網域所有者選擇的選擇器名稱之下，而且無法從外部分別列舉一個網域的選擇器。本檢查探測主要服務商使用的常用選擇器（default、google、selector1、selector2、mail、dkim、s1、s2、k1、mandrill 等等）。任何其他名稱下的金鑰對探測來說都是看不見的。決定性的測試是一封真實郵件：向你控制的信箱寄送郵件，並檢查 Authentication-Results 標頭，它會報告所用的選擇器以及簽章是否驗證通過。
為什麼檢查要統計 SPF 查詢次數？為什麼上限是 10？
評估一條 SPF 記錄可能需要進一步的 DNS 查詢——每個 include、a、mx、ptr、exists 和 redirect 項都算一次。RFC 7208 將總數上限設為 10；超過它，收件方會返回永久錯誤，SPF 結果作廢，這可能比一條能乾淨評估的適度記錄更糟。隨著服務商被加入，記錄的查詢次數會悄悄增長（每個 include 都帶來自己的項），所以一條在設定時合法的記錄，會隨著供應商更改自己的記錄而漂移超過上限。本檢查按收件方的方式展開記錄並報告真實計數，讓漂移在它使你的驗證失效之前就被看見。
如果有多個發現都是失敗，我應該先修復什麼？
按順序：多條 SPF 記錄（合併為一條——在修復它之前，下游的一切都不可靠）、缺失或 +all 的 SPF 記錄（發布真實的寄件人名單，並以 -all 結尾）、缺失的 DMARC 記錄（從帶報告地址的 p=none 開始，這樣你可以在強制執行之前看到誰以你名義寄送），然後隨著報告變乾淨，將 DMARC 從 p=none 提升到 p=reject。如有黑名單列入，那是平行工作——在修復記錄的同時修復其原因並申請移除。我們的指南會按順序講解其中的道理：為什麼你的郵件會進垃圾桶。