MINFO (Mailbox Information) 紀錄查詢
MINFO (Mailbox Information) 紀錄在 RFC 1035 中被定義為一種實驗性協定，旨在將高度精細的管理路由元資料附加到郵件論壇和個別信箱。在網際網路的撥接 (dial-up) 時代，網路連線經常中斷，郵件伺服器也經常當機。自動化的退回訊息（未傳遞報告或 NDR）通常會在伺服器之間無休止地循環，阻塞了 ARPANET 有限的頻寬。MINFO 紀錄是為了直接在 DNS 層提供用於錯誤處理的嚴格路由規則的一種嘗試。
RMAILBX 與 EMAILBX 參數
與使用單一目標字串的標準紀錄不同，MINFO Payload 需要兩個截然不同的指標 (pointers)。第一個是 RMAILBX (負責信箱)。此參數明確定義了負責接收與特定郵件論壇相關的自動錯誤訊息和伺服器退信的網域或信箱。第二個參數是 EMAILBX (錯誤信箱)，它定義了負責該清單的人員管理員或維護者。當外部伺服器在嘗試遞送大量 Payload 時遇到嚴重故障，它應該要查詢 MINFO 紀錄，以找出錯誤日誌 (error logs) 確切應該發送到哪裡，從而繞過寄件者的實際地址。
頻外 (Out-of-Band) 傳輸的失敗
MINFO 紀錄的核心架構缺陷是它依賴於「頻外」(out-of-band) 訊號傳輸。這迫使一個已經在處理 SMTP 交易的郵件伺服器必須停止執行、開啟新的 UDP 連線、向 DNS 層查詢 MINFO 紀錄、等待傳播，然後重寫錯誤路由路徑。事實證明，這比在實際電子郵件傳輸期間簡單地「頻內」(in-band) 處理錯誤路由要慢得多且可靠性更低。
SMTP 標頭取代了 DNS 邏輯
工程師們很快就意識到，SMTP 協定本身比 DNS 層更適合處理退信元資料。特定的 SMTP 信封標頭（尤其是 Return-Path 和 Errors-To 標頭）的引入，完全消除了對 MINFO 紀錄的需求。今天，當大量發件人發送電子報時，他們會將退信處理地址直接嵌入到電子郵件的隱藏標頭中。如果接收伺服器遇到錯誤，它只需在本地讀取標頭並立即發回退回訊息，完全不需要任何外部 DNS 查詢。因此，生產環境中的 MTA 完全忽略了 MINFO Payload。