MG (Mail Group) 實驗性檢查器
MG (Mail Group) 紀錄是一項令人難以置信的雄心勃勃的早期工程嘗試，旨在將郵件論壇 (mailing list) 功能原生建構到網域名稱系統本身的結構中。在應用程式層級的郵件論壇管理員出現之前，網路工程師建立了一種理論，認為他們可以使用 DNS 紀錄來指示整個網際網路骨幹網路的群組分佈邏輯。該概念在 RFC 1035 中被概述為一種實驗性機制，用於在伺服器對伺服器路由階段處理大量電子郵件的複製 (duplication)。
DNS 層級的 Payload 複製
MG 紀錄的機制依賴於 DNS 節點叢集。管理員會建立一個虛擬網域 (pseudo-domain) 節點，例如 dev-team.example.com。然後，他們會將多筆 MG 紀錄附加到這單一節點上，每筆紀錄都明確指向團隊成員的各別 MB (Mailbox) 紀錄。當外部郵件伺服器嘗試發送電子郵件到該群組位址時，它會向 DNS 查詢 MG 紀錄。權威名稱伺服器將回傳成員的完整陣列。然後，發送伺服器應該要複製電子郵件 Payload 並啟動單獨的 SMTP 連線，以將訊息遞送到 DNS 回應中列出的每一個信箱。
快取與傳播的失敗
由於 DNS 快取的固有特性，MG 協定在實際部署中遭遇了徹底的失敗。DNS 嚴重依賴存活時間 (TTL) 值，其中中間 ISP 會將紀錄快取 24 到 48 小時以減少網路負載。如果使用者想要取消訂閱郵件論壇，系統管理員必須從區域檔中刪除他們的 MG 紀錄。然而，因為外部伺服器快取了舊的群組名單，使用者會連續幾天繼續收到群發電子郵件，直到全球 TTL 過期。透過靜態 DNS 區域編輯來管理動態的使用者訂閱，在計算上效率低落，且令使用者感到極度挫折。
應用程式層清單的興起
網路架構師普遍得出結論：郵件論壇需要複雜的狀態管理 (State Management)——處理退信、處理取消訂閱連結和管理審核佇列——而 DNS 從來沒有被設計來處理這些任務。MG 紀錄被完全放棄。業界轉向應用程式等級的清單管理員，如 GNU Mailman、Majordomo 和現代的 Exchange 通訊群組 (Distribution Groups)。這些應用程式位於標準 MX 紀錄之後，接收單一電子郵件 Payload，並使用內部 SQL 資料庫即時管理複製和分佈，將郵件論壇邏輯與全球 DNS 路由表完全脫鉤。