Wildcard DNS can make a name answer even when no record was explicitly created for that name. That matters when you are diagnosing DMARC: a TXT answer may be synthesized from a wildcard, and another nearby name may behave differently because part of the DNS tree already exists.
The right test starts with the domain in a real message’s From address. Trace each relevant query and its returned record set. Do not infer DMARC coverage from the presence of an asterisk in a zone export or from a website responding at an invented hostname.
Separate DNS synthesis from DMARC discovery
DNS wildcard processing determines whether a particular query can receive synthesized data. DMARC discovery determines which policy is applicable to the message. These are different steps. The first DMARC query prefixes _dmarc to the Author Domain; subsequent discovery follows the applicable protocol rules. RFC 9989, section 4.10.
A wildcard such as *.example.com is not a universal instruction to copy every record into every subdomain. DNS considers existing names, the closest enclosing name and the record type requested. A wildcard with only an address record does not supply a DMARC TXT policy. RFC 4592 §3.3.1 and RFC 4592 §3.3.3.
Also avoid treating _dmarc.*.example.com as a pattern that a DMARC receiver expands over all subdomains. Under RFC 4592 §2.1.1, a wildcard domain name has an asterisk as its leftmost label; DMARC does not search a catalogue of textual patterns to find a policy for each message.
Use existing names as deliberate test cases
Consider a synthetic zone with a TXT record at *.example.com containing an otherwise valid DMARC value. If branch.example.com does not exist and the closest encloser for a query at _dmarc.branch.example.com is example.com, that wildcard can be the source of a synthesized TXT answer.
Now suppose branch.example.com exists as a DNS node. The closest encloser for _dmarc.branch.example.com changes. The wildcard immediately beneath that closer node would be *.branch.example.com. The lookup does not simply fall back to *.example.com when that source is absent. This distinction is why broad wildcard assumptions fail. RFC 4592, section 3.3.1.
Under RFC 4592 §2.2.2, an empty non-terminal can count as an existing name too. A name can exist because records exist below it even when it has no record set of its own. Adding an apparently unrelated record deeper in the tree can therefore change which wildcard, if any, supplies an answer. Treat the scenario as an explanation of the algorithm, not as proof of how your provider’s current zone is configured.
Build a small discovery worksheet
Choose the actual sending domain, an explicitly configured subdomain, a delegated subdomain if relevant and a genuinely nonexistent test name. Avoid sending mail from invented domains merely to test DNS. For each case record:
- The exact Author Domain being modeled.
- The initial _dmarc-prefixed TXT lookup name.
- Authoritative answer status and complete TXT record set.
- Whether a matching owner is explicit or potentially synthesized, based on zone evidence.
- Any fallback policy discovery and the resulting policy domain.
- The implementation or specification used to interpret the result.
A positive DNS answer by itself may not disclose that it was synthesized. Use authorized zone inspection and authoritative responses together. Querying a literal asterisk name is not equivalent to testing the concrete name the receiving mail system will query.
Do not confuse existence with authorization
Domain existence affects more than the presence of an explicit TXT row. RFC 9989 distinguishes policy for existing and non-existent subdomains through its policy-discovery rules and sp/np handling. Wildcard answers can affect the DNS observations behind that distinction. Verify the actual existence and policy path before relying on np for a particular name. RFC 9989 §3.2.13 and RFC 9989 §4.10.1.
Even when a policy is discoverable, it does not authorize an application to send or create an aligned signature. Under RFC 9989 §5.3.5, a message still needs an authenticated aligned identity to pass DMARC. Use the alignment guide for that separate task.
Prefer an explainable policy layout
As an operational recommendation, use explicit records where precise control is required and document intended fallback behavior. Before changing a wildcard, inventory its other uses: the same DNS configuration may support unrelated services. Do not remove it as a mail-only cleanup without checking those dependencies.
Retest the worksheet after adding a DNS node, delegating a subdomain or changing the DMARC layout. Save the previous and new observations. The completion criterion is an explained policy path for each important sender domain, not a blanket statement that the wildcard covers everything.
Preserve a bounded conclusion
In the synthetic zone, the nonexistent branch allows *.example.com to supply the concrete query only under the stated closest-encloser and TXT assumptions. Once branch exists, the candidate becomes *.branch.example.com; absence there does not trigger wildcard fallback to the parent. DMARC may still perform its own separate policy discovery. No authoritative lookup or zone change was executed.