通配符MX可以使先前未設定的子網域顯示為接收郵件。這並不意味著該區域下的每個名稱都共享相同的路線。 DNS通配符合成取決於名稱是否存在以及最近的封閉節點，而不是所有子網域之間的簡單文字匹配。
區分通配符DNS和郵箱 catch -all
參考： RFC 4592 §3.3, RFC 5321 §3.3.
DNS通配符，例如 *.example.com 可以為某些原本不存在的名稱提供資料。郵箱-all像是關於它接受哪些本地部分的電子郵件伺服器規則。任何一個都可以獨立存在。通配符MX答案並不能證明交易所會接受 anything@sub.example.com，且-all郵箱無法修復從未到達其伺服器的DNS路由。
RFC 4592根據最接近的包圍體和合成源定義了通配符行為。即使現有名稱沒有所要求類型的記錄，它們也很重要。不要假設通配符MX會填入每個已包含 A 或 A 的名稱中缺少的MX類型 TXT記錄.
行走最小區域
參考： RFC 4592 §2.2.2, RFC 4592 §3.3.1, RFC 5321 §5.1.
使用隔離的 example.com 測試區包含 *。 example.com 。在MX 10 mx.example.com 。， 一個 一個記錄 在 mx.example.com，以及 A 記錄 known.example.com。如果沒有其他相關名稱，則MX查詢 missing.example.com 可以合成通配符MX 。對現有的MX查詢 known.example.com 該名稱沒有MX數據，並且不簡單地繼承通配符。然後SMTP可以遵循其位址後備規則。
添加 leaf.branch.example.com 。 TXT中“夾具”。這會產生幹預 branch.example.com 節點，即使它沒有自己的明確記錄。該分支下方的MX查詢現在有一個更緊密的封閉節點。沒有通配符 *.branch.example.com，頂點通配符並不是萬能-all後備方案。保留這個反例，因為它解釋了為什麼兩個明顯相似的位址採用不同的路由。
這些都是綜合預期結果。將區域載入到隔離的權威伺服器中，查詢每個確切的名稱並保存答案、權限和回應代碼。分別測試名稱存在和類型不存在。這些範例未聲明實時伺服器執行。
審核路線及其接受政策
參考： RFC 1034 §4.3.2.
列出實際的子網域、委派的子網域和通配符擁有者。授權創建了權限邊界；父通配符不能取代子區域的答案。檢查選定的不存在名稱和已知名稱，並追蹤傳回的MX主機名稱到其位址。
在接收服務上，確認接受哪些收件者網域和本地部分。意外的路由可能會將操作郵件暴露給錯誤的租戶或生成 後向散射 如果拒絕延遲。僅測試您控制的地址和服務，包含無害的內容和明確的預期處理。
更改最窄的相關控制
參考： RFC 7505 §3, RFC 8767 §4.
如果某個網域不應接收郵件，請評估該名稱的明確 Null MX 。如果通配符是不必要的，則刪除它可能會影響許多以前未見過的名稱。在更改之前清點這些依賴項。驗證更改後的DNS和收件人處理，包括快取的先前答案，並準確記錄已消除的意外路由。
保持證據範圍明確
通配符遍歷是基於來源的預期結果說明，而不是執行的權威DNS測試。在選擇通配符之前必須確定名稱是否存在以及最接近的包圍符；如果候選來源不存在，則不要搜尋更廣泛的通配符所有者作為後備。