A wildcard MX can make a previously unconfigured subdomain appear to receive mail. It does not mean every name below the zone shares the same route. DNS wildcard synthesis depends on whether names exist and on the closest enclosing node, not a simple text match across all subdomains.
Distinguish wildcard DNS from mailbox catch-all
References: RFC 4592 §3.3, RFC 5321 §3.3.
A DNS wildcard such as *.example.com can supply data for certain otherwise nonexistent names. A mailbox catch-all is an email-server rule about which local parts it accepts. Either can exist without the other. A wildcard MX answer does not prove the exchange will accept anything@sub.example.com, and a catch-all mailbox cannot repair a DNS route that never reaches its server.
RFC 4592 defines wildcard behavior in terms of the closest encloser and source of synthesis. Existing names matter even if they have no record of the requested type. Do not assume a wildcard MX fills the missing MX type at every name that already has an A or TXT record.
Walk a minimal zone
References: RFC 4592 §2.2.2, RFC 4592 §3.3.1, RFC 5321 §5.1.
Use an isolated example.com test zone containing *.example.com. IN MX 10 mx.example.com., an A record at mx.example.com, and an A record at known.example.com. With no other relevant names, an MX query for missing.example.com can synthesize the wildcard MX. An MX query for the existing known.example.com has no MX data at that name and does not simply inherit the wildcard. SMTP may then follow its address fallback rules.
Add leaf.branch.example.com. IN TXT "fixture". This creates the intervening branch.example.com node even if it has no explicit record of its own. An MX query below that branch now has a closer enclosing node. With no wildcard at *.branch.example.com, the apex wildcard is not a catch-all fallback. Preserve this counterexample because it explains why two apparently similar addresses take different routes.
These are synthetic expected results. Load the zone into an isolated authoritative server, query each exact name and save answer, authority and response code. Test name existence and type absence separately. No live server execution is claimed by these examples.
Audit the route and its acceptance policy
References: RFC 1034 §4.3.2.
List actual subdomains, delegated children and wildcard owners. A delegation creates an authority boundary; the parent wildcard is not a substitute for the child zone's answers. Check selected nonexistent names as well as known names, and trace the returned MX hostname to its addresses.
On the receiving service, confirm which recipient domains and local parts are accepted. Unexpected routing can expose operational mail to the wrong tenant or generate backscatter if rejection is delayed. Test only addresses and services you control, with harmless content and explicit expected handling.
Change the narrowest relevant control
References: RFC 7505 §3, RFC 8767 §4.
If one domain should not receive mail, assess an explicit Null MX at that name. If the wildcard is unnecessary, removing it may affect many previously unseen names. Inventory those dependencies before changing it. Verify both DNS and recipient handling after the change, including cached previous answers, and record exactly which unexpected routes were eliminated.
Keep the evidence scope explicit
The wildcard walk is a source-based expected-result illustration, not an executed authoritative DNS test. Name existence and the closest encloser must be determined before selecting a wildcard; if the candidate source does not exist, do not search broader wildcard owners as a fallback.