MR (Mail Rename) 舊版 DNS 檢查器
MR (Mail Rename) 紀錄是 RFC 1035 早期時代的另一個實驗性產物，被設計為在 DNS 層級作為已更改電子郵件地址的別名機制。當企業網路首次上線時，更改使用者的電子郵件地址是一個令人驚訝的複雜路由問題。引入 MR 紀錄是為了直接在 DNS 查詢階段內建立一個永久的轉發迴圈 (forwarding loop)，以防止在員工更換部門或更改使用者名稱時合法的郵件被退回。
連線前的別名解析 (Pre-Connection Alias Resolution)
如果員工將他們的使用者名稱從 jsmith 更改為 john.smith，系統管理員會在舊節點上發佈一個指向新信箱的 MR 紀錄。當外部郵件伺服器收到發往舊電子郵件的訊息時，它會查詢 DNS。遇到 MR 紀錄時，發送伺服器被指示實際覆寫 (rewrite) 電子郵件的信封標頭 (envelope headers)，將舊目的地換成新目的地，甚至在啟動 SMTP 連線以遞送 Payload 之前就進行。它的運作方式與 CNAME 紀錄對主機名稱的運作方式非常相似，但它特別侷限於信箱的本地部分 (local-parts)。
路由延遲與營運負擔
就像 MB 和 MG 紀錄一樣，MR 紀錄在自身的營運負擔 (operational overhead) 之下崩潰了。由於 DNS 查詢依賴於穿越多個邊緣網路的 UDP 封包，僅為了要求解析本地別名而依賴外部 DNS 查詢，會為郵件佇列增加巨大的延遲。此外，它向公共網際網路暴露了內部企業結構。如果惡意行為者查詢了 MR 紀錄，他們可以輕易繪製出組織完整的員工歷史記錄和部門變更，為社交工程和網路釣魚攻擊建立了一份高度詳細的名單 (roster)。
現代的伺服器端別名處理 (Server-Side Aliasing)
將使用者別名暴露給 DNS 層被認為是不必要且不安全的。隨著郵件伺服器變得更加複雜，該協定被完全棄用。今天，別名處理在本地郵件傳輸代理 (MTA) 設定內被即時且安全地處理。Postfix 中的 /etc/aliases 檔案、Exim 中的虛擬別名對應 (virtual alias maps) 或 Microsoft Active Directory 中的 Proxy 位址等技術，能在毫秒內於內部處理使用者名稱交換。外部發送伺服器只需連接到 MX 紀錄，丟下 Payload，然後讓接收伺服器處理內部的重新命名邏輯，完全繞過 DNS 層。