MB (Mailbox Domain) 舊版紀錄查詢
MB (Mailbox) 紀錄是原始 RFC 1035 DNS 規範中一個引人入勝的實驗性產物。在現代網路架構中，網域名稱系統嚴格處理將流量路由到實體伺服器或 IP 位址的任務，而內部應用程式（如電子郵件伺服器）則解析 Payload 以找出資料屬於哪個特定使用者。MB 紀錄試圖模糊這些界線。它沒有透過 MX 紀錄將組織的郵件路由到集中式伺服器叢集，而是嘗試將個別使用者的信箱直接在 DNS 區域檔內原生對應到特定的主機名稱。
Direct-to-Host 郵件路由
在 MB 協定理論下，DNS 層將擁有關網路中每個員工或使用者的精細知識。例如，管理員在理論上可以設定一個 MB 紀錄，使得發送至 sysadmin 信箱的郵件被明確地路由到高安全性的 UNIX 大型主機，而發送至 sales 的郵件則被路由到完全不同、安全性較低的伺服器。當遠端伺服器想要遞送電子郵件時，它會針對電子郵件地址的本地部分 (local-part)（@ 符號之前的字串）特別向 DNS 查詢，以尋找該單一使用者收件匣的確切硬體目的地。
無法擴展的噩夢
MB 紀錄的運作現實是一場絕對的擴展災難。要管理一個擁有 5,000 名員工的中型企業網路，系統管理員將需要維護 5,000 筆獨立、手動輸入的 DNS 紀錄，僅僅是為了處理標準的電子郵件路由。每次有新員工入職或被解僱時，都必須編輯核心 DNS 區域檔、遞增 SOA 序號，並將變更傳播到全球網際網路，只為了一個信箱的配置 (provisioning)。這導致區域檔膨脹到難以管理的大小，並為早期的 DNS 解析器帶來了極端的處理負載。
委派至應用程式層 (Application Layer)
工程師們很快就意識到，DNS 是管理使用者層級身分的錯誤協定。業界完全放棄了 MB 概念，並建立了堅固的架構邊界。今天，DNS（透過 MX 紀錄）僅負責將電子郵件封包送到組織郵件傳輸代理 (MTA) 的「前門」。一旦連線建立，應用程式層軟體（如 Postfix、Exim 或 Microsoft Exchange）就會接手，使用內部資料庫或 Active Directory 來解析地址的本地部分，並將 Payload 遞送到正確的內部收件匣。您不會在任何現代生產網路上找到正在解析的 MB 紀錄。