電子郵件網域驗證：網域驗證和 MX 記錄檢查完整指南

電子郵件網域驗證是郵件驗證過程的基礎。在確定特定郵箱是否存在之前，驗證服務必須首先確認網域本身是有效的並且能夠接收郵件。這份全面指南探討了電子郵件網域驗證的技術要點，從 DNS 查詢到 MX 記錄驗證，並解釋了為什麼網域級別的檢查對維護健康的郵件列表至關重要。

如需了解基礎概念，請參閱我們的電子郵件驗證完整指南。

什麼是電子郵件網域驗證?

電子郵件網域驗證是確認電子郵件地址的網域部分（@ 符號後面的部分）有效、配置正確並且能夠接收郵件的過程。

當您驗證像 user@example.com 這樣的電子郵件地址時，網域驗證會檢查 example.com 是否：

• 作為註冊網域存在
• 具有正確的 DNS 配置
• 具有指向郵件伺服器的 MX 記錄
• 正在主動接收郵件

這種網域級別的驗證發生在任何驗證特定郵箱的嘗試之前，作為驗證過程中的關鍵第一道過濾器。

為什麼網域驗證很重要

網域驗證具有幾個關鍵功能：

效率：首先檢查網域可以避免浪費資源嘗試驗證不存在或配置錯誤的網域上的郵箱。如果網域不存在或無法接收郵件，就沒有必要檢查單個地址。

早期檢測：網域級別的問題（過期網域、缺少 MX 記錄）比郵箱級別的問題更容易檢測。網域驗證可以快速可靠地發現這些問題。

威脅檢測：許多電子郵件威脅可以在網域級別識別——已知的垃圾郵件網域、一次性電子郵件服務和可疑的新註冊網域。

減少假陰性：一些郵件伺服器會拒絕單個郵箱驗證嘗試，但網域驗證仍然可以確認網域能夠接收郵件，從而減少假陰性錯誤。

網域驗證的技術過程

了解網域驗證的工作原理可以幫助您理解其能力和局限性。

步驟 1：網域提取和語法驗證

第一步從電子郵件地址中提取網域並驗證其基本格式：

有效網域的特徵：

• 遵循 DNS 命名約定
• 僅包含允許的字元（字母、數字、連字符）
• 正確的標籤結構（由點分隔，無前導/尾隨連字符）
• 來自已識別列表的有效 TLD（頂級網域）

常見的語法問題：

• 網域中的空格
• 無效字元（網域中的下劃線，而非子網域）
• 缺少或無效的 TLD
• 雙點或前導/尾隨點

大多數語法錯誤表明存在拼寫錯誤或故意偽造的地址。

步驟 2：DNS 查詢

一旦網域在語法上有效，驗證就會執行 DNS 查詢以確認網域存在並且配置正確。

A 記錄檢查：A 記錄將網域映射到 IP 地址。雖然對於電子郵件不是嚴格要求的，但大多數合法網域都有其主網域的 A 記錄。

AAAA 記錄檢查：類似於 A 記錄，但用於 IPv6 地址。隨著 IPv6 的採用增長，越來越常見。

NS 記錄檢查：名稱伺服器記錄指示哪些伺服器對該網域具有權威性。它們的存在確認網域已註冊並處於活動狀態。

SOA 記錄檢查：授權起始記錄包含有關網域的管理資訊。缺少 SOA 記錄表明網域可能未正確配置。

未通過基本 DNS 查詢的網域——沒有 A 記錄、沒有 NS 記錄、沒有 SOA——很可能已過期、從未註冊或嚴重配置錯誤。

步驟 3：MX 記錄驗證

MX（郵件交換）記錄是電子郵件網域驗證中最關鍵的元素。這些記錄指定哪些郵件伺服器處理該網域的電子郵件。

MX 記錄的工作原理：

• 每條 MX 記錄包含一個優先級號和一個郵件伺服器主機名
• 較低的優先級號表示首選伺服器
• 多條 MX 記錄提供冗餘
• 郵件伺服器首先嘗試較低優先級的 MX，然後回退到較高優先級

MX 記錄配置示例：

example.com MX 10 mail1.example.com
example.com MX 20 mail2.example.com
example.com MX 30 backupmx.example.com

在這個配置中，mail1.example.com 處理大部分電子郵件，mail2 作為備份，backupmx 作為最後的選擇。

MX 記錄驗證檢查：

1. 網域是否存在 MX 記錄？
2. MX 主機名是否解析為有效的 IP 地址？
3. 郵件伺服器是否可達？
4. 它們是否響應初始 SMTP 連接？

步驟 4：郵件伺服器連接測試

在識別 MX 記錄後，驗證可能會嘗試連接到郵件伺服器以確認它們正在運行。

SMTP 連接過程：

1. 在端口 25（或 587/465）上建立 TCP 連接
2. 接收伺服器問候語（220 響應）
3. 發送 EHLO/HELO 命令
4. 觀察伺服器響應

成功的連接確認網域的郵件基礎設施正在運行。連接失敗可能表明：

• 伺服器暫時停機
• 網路問題
• 防火牆阻止連接
• 伺服器配置錯誤

理解 MX 記錄驗證結果

根據 MX 記錄狀態和郵件伺服器行為，網域驗證可以產生各種結果。

未找到 MX 記錄

當網域沒有 MX 記錄時，電子郵件傳遞遵循 RFC 規定的回退行為：

RFC 回退：如果不存在 MX 記錄，郵件伺服器會嘗試傳遞到 A 記錄 IP 地址。一些網域有意依賴這種行為，雖然這越來越少見。

驗證解釋：沒有 MX 記錄的網域被標記為更高風險。電子郵件可能可以傳遞也可能不可以——這取決於 A 記錄 IP 上的伺服器是否接受 SMTP 連接。

MX 記錄指向不存在的伺服器

有時 MX 記錄存在，但指定的郵件伺服器不存在：

原因：

• 網域遷移正在進行中
• 配置錯誤
• 故意的反垃圾郵件措施
• 託管服務過期

驗證結果：網域被標記為無法接收電子郵件。此網域上的任何地址都會被退回。

MX 記錄指向本地主機或私有 IP

MX 記錄指向 127.0.0.1、0.0.0.0 或私有 IP 範圍的網域無法接收外部電子郵件：

常見模式：

• 127.0.0.1 - 本地主機，由不想接收電子郵件的網域使用
• 0.0.0.0 - 空路由，明確拒絕電子郵件
• 10.x.x.x、192.168.x.x - 私有地址，無法從網際網路路由

驗證結果：網域絕對無法從外部來源接收電子郵件。所有地址都應標記為無效。

Catch-All 網域檢測

在網域驗證期間，服務可以經常檢測到全捕獲配置：

什麼是全捕獲：配置為接受任何地址的電子郵件的網域，即使是不存在的地址。伺服器不會拒絕未知收件人，而是接受所有郵件。

檢測方法：發送一個隨機的、明顯不存在的地址的驗證請求。如果伺服器接受它，該網域可能配置了全捕獲。

影響：對於全捕獲網域，無法進行單個郵箱驗證。這些網域上的所有地址都應標記為"無法驗證"而不是"有效"。

網域級別的威脅檢測

除了基本的可傳遞性之外，網域驗證還可以檢測各種電子郵件威脅。

一次性郵件網域

一次性電子郵件服務提供臨時電子郵件地址，用戶創建這些地址是為了避免提供真實的電子郵件。這些地址會短暫工作，然後消失。

網域級別的檢測：BillionVerify 維護著一個全面的已知一次性電子郵件網域資料庫。這些網域上的任何地址都會立即被標記。

AI 增強檢測：我們的機器學習模型可以識別可能是一次性電子郵件網域的情況，即使它們尚未在資料庫中——分析網域註冊模式、DNS 配置和行為信號。

新註冊的網域

在過去幾週或幾個月內註冊的網域具有更高的風險：

為什麼新網域有風險：

• 合法企業很少使用全新的網域進行註冊
• 詐騙者經常註冊新網域用於一次性使用
• 垃圾郵件操作通過新網域循環以避免黑名單

驗證方法：標記來自新註冊網域的地址以進行額外審查。該網域可能是合法的，但需要額外謹慎。

停放和不活躍的網域

一些註冊網域並未主動用於電子郵件：

停放網域：顯示廣告或"待售"頁面，但沒有功能性電子郵件 過期託管：網域已註冊但託管服務已失效 佔位符配置：MX 記錄指向佔位符或錯誤頁面

網域驗證可以識別這些情況，防止來自看起來有效但實際上無法接收電子郵件的地址的退信。

已知的垃圾郵件和釣魚網域

威脅情報資料庫跟蹤與垃圾郵件、釣魚和其他惡意活動相關的網域：

資料庫來源：

• ISP 垃圾郵件報告
• 安全研究人員的發現
• 行業黑名單
• 自動蜜罐檢測

驗證應用：已知不良網域上的地址會被標記，無論技術上是否可傳遞。即使這些地址可以接收電子郵件，您也不希望它們出現在您的列表中。

不同電子郵件提供商的網域驗證

主要的電子郵件提供商以不同方式處理網域驗證，需要專門的方法。

Gmail 和 Google Workspace

Google 運營著世界上最大的電子郵件基礎設施之一：

MX 模式：Gmail.com 使用 Google 的標準 MX 伺服器（gmail-smtp-in.l.google.com 和備用伺服器） 驗證注意事項：

• 由於 Google 的反垃圾郵件措施，單個郵箱驗證受到限制
• 網域驗證確認地址位於 Gmail 基礎設施上
• 基於角色的地址（@gmail.com）需要額外驗證

Microsoft 365 和 Outlook.com

Microsoft 的電子郵件平台顯示出獨特的模式：

MX 模式：Microsoft 365 通常為 *.mail.protection.outlook.com 驗證注意事項：

• 與 Gmail 類似，限制郵箱驗證
• Microsoft 365 自定義網域顯示 Microsoft MX 基礎設施
• 消費者 Outlook.com 與商業 Microsoft 365 具有不同的特徵

Yahoo 和其他提供商

不同的提供商有不同的配置：

Yahoo：使用 Yahoo 的 MX 基礎設施，有一些驗證限制 ProtonMail：注重隱私的提供商，具有特定的 MX 模式 iCloud：Apple 的電子郵件服務，具有獨特的配置

了解提供商特定的模式可以幫助驗證服務應用適當的邏輯。

實施網域驗證

無論是使用 API 還是構建內部工具，有效的網域驗證都涉及以下內容。

基本檢查

至少，網域驗證應包括：

1. 語法驗證：確認網域遵循 DNS 命名規則
2. DNS 存在檢查：驗證網域已註冊並正在解析
3. MX 記錄查詢：檢查郵件交換記錄
4. MX 解析：確認 MX 主機名解析為 IP
5. 基本連接：驗證郵件伺服器可達

增強驗證

更複雜的驗證會添加：

1. 全捕獲檢測：識別接受所有郵件的網域
2. 一次性網域檢查：標記臨時電子郵件服務
3. 網域年齡分析：評估新註冊的網域
4. 威脅資料庫檢查：與已知不良網域匹配
5. 提供商識別：識別主要電子郵件提供商

使用 BillionVerify 進行網域驗證

BillionVerify 的 API 作為我們電子郵件驗證過程的一部分提供全面的網域驗證：

const response = await fetch('https://api.billionverify.com/v1/verify', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ email: 'user@example.com' })
});

const result = await response.json();
// 結果包括網域級別的資訊：
// - domain: "example.com"
// - domain_status: "valid" | "invalid" | "disposable"
// - mx_found: true | false
// - catch_all: true | false

我們的驗證會自動執行所有網域檢查，提供有關網域狀態的詳細結果以及郵箱驗證。

常見的網域驗證挑戰

網域驗證面臨幾個影響準確性的技術挑戰。

DNS 傳播延遲

當網域更改其 MX 記錄時，更改不會立即傳播：

挑戰：最近更改的網域可能會顯示舊的或不一致的 MX 記錄，具體取決於 DNS 解析器緩存。

緩解措施：BillionVerify 使用多個 DNS 解析器並檢查一致性。我們還維護自己的 DNS 基礎設施，採用積極的緩存管理。

地理 DNS 變化

一些網域使用 GeoDNS 根據請求者的位置返回不同的結果：

挑戰：MX 記錄可能因地區而異，影響驗證結果。

緩解措施：我們的全球基礎設施從多個地區執行驗證，識別地理變化。

臨時 DNS 故障

DNS 基礎設施偶爾會遇到臨時問題：

挑戰：DNS 查詢失敗可能表明真正的問題或臨時故障。

緩解措施：智能重試邏輯和多個查詢源區分臨時故障和實際網域問題。

反驗證措施

一些網域實施措施以防止或限制驗證：

技術：

• 對 DNS 查詢進行速率限制
• 阻止已知驗證服務 IP
• 返回誤導性 SMTP 響應
• 對非人類請求進行隨機失敗

緩解措施：BillionVerify 使用複雜的技術來處理反驗證措施，同時尊重服務條款。

網域驗證的最佳實踐

通過這些實踐最大化網域驗證的價值。

在完整驗證之前驗證網域

對於大型列表，按網域進行預篩選以提高效率：

1. 從您的電子郵件列表中提取唯一網域
2. 驗證每個網域一次
3. 立即標記無效網域上的所有地址
4. 僅對有效網域上的地址進行完整驗證

這種方法對於每個網域有許多地址的列表更快、更具成本效益。

監控網域變化

您已驗證的網域可能會更改狀態：

定期重新驗證：網域可能會過期、更改配置或被入侵。定期驗證可以發現這些變化。

注意模式：如果先前有效的網域上的許多地址開始退信，請調查該網域的當前狀態。

了解網域質量層級

並非所有有效網域都同樣有價值：

第 1 層 - 主要提供商：Gmail、Outlook、Yahoo——最高的可傳遞性信心 第 2 層 - 商業網域：信譽良好的成熟公司網域 第 3 層 - 個人網域：個人網域，質量更多變 第 4 層 - 新/未知網域：最近註冊或不熟悉的網域

考慮在您的參與策略中以不同方式對待不同的層級。

適當處理全捕獲網域

全捕獲網域無法在郵箱級別進行明確驗證：

選項：

• 接受全捕獲地址但監控退信率
• 標記為降低發送頻率
• 對於高價值註冊要求額外確認
• 對於特別敏感的應用程式拒絕

正確的方法取決於您的具體用例和風險承受能力。

網域驗證的未來

隨著電子郵件基礎設施的變化，電子郵件網域驗證繼續發展。

DMARC、DKIM 和 SPF 集成

電子郵件身份驗證標準提供額外的網域情報：

DMARC：基於網域的消息身份驗證揭示了網域所有者希望如何處理身份驗證失敗 DKIM：DomainKeys 識別郵件配置指示電子郵件簽名實踐 SPF：發件人策略框架顯示授權的發送伺服器

未來的驗證可能會整合這些信號以增強網域評估。

DNS Over HTTPS (DoH)

DNS 隱私技術影響驗證服務訪問 DNS 資訊的方式：

影響：DoH 可能會改變驗證服務執行查詢的方式 機會：更安全、經過身份驗證的 DNS 資訊可能會提高準確性

機器學習網域分析

AI 越來越多地為網域評估做出貢獻：

應用：

• 根據註冊模式預測網域風險
• 在黑名單收錄之前識別欺詐性網域
• 檢測協同網域濫用活動
• 提高全捕獲檢測準確性

結論

電子郵件網域驗證是電子郵件驗證過程中至關重要的第一步。通過確認網域有效、配置正確並且能夠接收電子郵件，網域驗證可以有效地過濾掉肯定會失敗的地址，同時在網域級別識別潛在威脅。

如需選擇合適的解決方案，請參閱我們的最佳電子郵件驗證服務對比。

了解網域驗證的工作原理——從 DNS 查詢到 MX 記錄分析到威脅檢測——可以幫助您理解其能力和局限性。與郵箱級別的驗證相結合，全面的網域檢查可確保為您的電子郵件驗證需求提供最高的準確性。

BillionVerify 在每個電子郵件驗證請求中執行徹底的網域驗證。我們的全球 DNS 基礎設施、全面的威脅資料庫以及對邊緣情況的智能處理確保對您驗證的每個地址進行準確的網域評估。

立即開始使用 BillionVerify 進行驗證——每天 10 個免費積分，無需信用卡。

常見問題

網域驗證和電子郵件驗證有什麼區別？

網域驗證確認電子郵件地址的網域部分（@ 符號之後）有效並且可以接收電子郵件。電子郵件驗證更進一步，確認特定的郵箱（@ 符號之前）在該網域上存在。網域驗證通常是完整電子郵件驗證的第一步。

為什麼有些有效網域會驗證失敗？

有效網域可能因臨時 DNS 問題、郵件伺服器維護或反驗證措施而驗證失敗。如果您知道有效的網域驗證失敗，請稍後重試。持續失敗表明存在實際配置問題。

MX 記錄如何影響電子郵件的可傳遞性？

MX 記錄指定哪些伺服器處理網域的電子郵件。沒有 MX 記錄（或有效的回退 A 記錄），電子郵件無法傳遞到該網域。配置錯誤的 MX 記錄——指向不存在或無法訪問的伺服器——也會阻止傳遞。

我可以驗證全捕獲網域上的電子郵件地址嗎？

全捕獲網域接受任何地址的電子郵件，使得無法驗證特定郵箱是否存在。BillionVerify 識別全捕獲網域並適當標記地址，讓您根據風險承受能力決定如何處理它們。

網域多久更改一次其電子郵件配置？

大多數網域保持穩定的電子郵件配置，但在遷移、託管更改或管理更新期間會發生更改。定期驗證可以發現配置已更改的網域。對於關鍵列表，建議每季度進行一次驗證。

我應該對哪些網域最謹慎？

新註冊的網域、一次性電子郵件服務的網域和配置異常的網域需要額外審查。BillionVerify 會自動標記這些網域，幫助您做出明智的決定，決定接受哪些地址。

使用 Instantly 或 Smartlead 的團隊，在每次活動前透過 BillionVerify 清洗名單，可顯著提升送達率。

在選擇驗證服務商之前，比較 BillionVerify 與 ZeroBounce 在準確率和速度方面的差異。