Wildcard DNS Records: How *.example.com Really Works

A wildcard DNS record is a record whose owner name starts with the label *, such as *.example.com. The authoritative server uses it to synthesise an answer for names that do not exist in the zone: ask for anything.example.com, and if nothing called anything exists, you get the wildcard's data with the name you asked for. That last condition is the whole story. A wildcard is not a pattern that overrides or fills in existing names; it is a default for names that would otherwise be NXDOMAIN. Most surprises with wildcards come from forgetting this.

The rules are defined in RFC 1034 and clarified, in careful detail, in RFC 4592.

A zone to reason about

$ORIGIN example.com.
@          3600  IN  A      192.0.2.10
www        3600  IN  A      192.0.2.10
shop       3600  IN  TXT    "site-verification=abc123"
api.eu     3600  IN  A      192.0.2.30
dev        3600  IN  NS     ns1.dev-dns.example.
*          3600  IN  A      192.0.2.20

What different queries return:

Query	Answer	Why
blog.example.com A	192.0.2.20	blog does not exist, the wildcard is expanded
a.b.example.com A	192.0.2.20	neither b nor a.b exists; a DNS wildcard covers several labels
blog.example.com MX	NODATA (empty answer, NOERROR)	the wildcard matches the name, but it has no MX data
shop.example.com A	NODATA	shop exists (it has a TXT record), so the wildcard does not apply
eu.example.com A	NODATA	eu exists as an empty non-terminal because api.eu exists
x.eu.example.com A	NXDOMAIN	the closest existing ancestor is eu.example.com, and there is no *.eu.example.com
test.dev.example.com A	referral to the dev nameservers	a delegated subzone is outside this zone's wildcard
example.com MX	NODATA	the apex is not "under" the wildcard

The rules behind the table

Only the leftmost label, only a whole label

*.example.com is a wildcard. www.*.example.com and foo*.example.com are not: there the asterisk is just an odd character in a name. There is no partial matching and no regular expressions in DNS.

Names that exist are never matched

If a subdomain exists with any record type, the wildcard is out of the picture for every type at that name. In the zone above, shop.example.com has only a TXT record, so a query for its A record returns an empty answer, not the wildcard address. This is the number one wildcard support question: "I added a verification TXT for a subdomain and the subdomain stopped resolving."

Empty non-terminals exist too

A name exists as soon as something exists below it. Because api.eu.example.com is in the zone, eu.example.com exists as an "empty non-terminal", even though it owns no records. The wildcard at *.example.com therefore answers neither for eu.example.com nor for x.eu.example.com: for the latter, the server finds the closest existing ancestor (the "closest encloser", here eu.example.com) and looks for a wildcard directly below that, *.eu.example.com. There is none, so the answer is NXDOMAIN.

A practical consequence that bites mail and certificate setups: creating _dmarc.news.example.com or _acme-challenge.news.example.com turns news.example.com into an empty non-terminal. If news was previously served by the wildcard, it stops resolving the moment you add the underscore record. The fix is to give news its own explicit records.

Multiple labels, unlike certificates

A DNS wildcard matches one or more labels: x.y.example.com is answered by *.example.com as long as y.example.com does not exist. A wildcard certificate is different: *.example.com on a certificate matches exactly one label, so it is valid for y.example.com and not for x.y.example.com, and not for example.com itself. The two wildcards are separate mechanisms that merely share an asterisk. If you need a wildcard certificate, note that Let's Encrypt issues them only through the DNS-01 challenge, and that CAA records have a dedicated issuewild tag for them.

Delegations are not covered

Below an NS cut the parent zone has no authority, so its wildcard does not apply. The child zone needs its own wildcard if it wants one.

Any record type works

Wildcards are not limited to addresses. * IN CNAME tenants.saas.example., * IN MX 10 mail.example.com. and * IN TXT "…" are all valid. The wildcard rule is evaluated per name; then the type is looked up at the wildcard, which is why blog.example.com MX above is NODATA rather than NXDOMAIN.

Where wildcards are the right tool

• Multi-tenant SaaS: customer.app.example.com for every customer, without a DNS change per signup.
• Development and preview environments: feature-123.preview.example.com created by CI.
• Catch-all to a landing page or a redirect, so that mistyped subdomains still end up somewhere useful.

In all three cases the web server (and the certificate) must be ready to handle arbitrary hostnames; DNS only gets the visitor to the door.

Pitfalls

Wildcard MX. With * IN MX, every nonexistent subdomain becomes a routable mail domain. Mail to user@typo.example.com is delivered to your server instead of bouncing at the sender, and spammers can use any invented subdomain as a sender domain that "has mail service". Use it only if you really run catch-all mail for subdomains. Remember also that a wildcard MX record does not apply to subdomains that exist with other records.

Wildcard TXT. A TXT wildcard answers every TXT lookup under the zone for names that do not exist: _dmarc.sub.example.com, selector._domainkey.sub.example.com, _acme-challenge.sub.example.com all receive the same string. Well-behaved clients ignore data that does not start with the expected tag, but debugging becomes confusing. Explicit underscore records override the wildcard, because names that exist are never matched.

SPF for nonexistent subdomains. One legitimate use of a wildcard TXT record is * IN TXT "v=spf1 -all", stating that made-up subdomains send no mail. The limit is the usual one: subdomains that exist with other records (www, shop) are not covered and need their own SPF record if you want the same statement there.

Typos resolve. Without a wildcard, wwww.example.com is NXDOMAIN and the mistake is obvious. With one, it resolves, a monitoring check against a misspelled hostname stays green, and a removed subdomain quietly falls back to the wildcard target instead of failing.

Enumeration and inventory. Subdomain discovery tools that test candidate names see every candidate "exist". Serious tools detect this by first querying a random label; your own inventory scripts should do the same.

Wildcard CNAME to a third party. Pointing * at a hosting platform means every possible subdomain of yours is routed to that platform. If the platform lets any customer claim any hostname that points at it, someone else can serve content under your domain. This widens the risk described in subdomain takeover; prefer explicit records per hostname, or a platform that verifies hostname ownership.

Wildcards and DNSSEC

Signed zones handle wildcards without any action from you. The DNSSEC signature of an expanded answer reveals the expansion through its label count (the RRSIG says the owner had fewer labels than the name you asked for), and an accompanying NSEC or NSEC3 record proves that the exact name does not exist, so a validator can confirm the wildcard was applied legitimately.

Testing a wildcard

Query a name that cannot possibly exist:

$ dig +short anything-random-123.example.com
192.0.2.20

An answer means a wildcard is in place. Compare with a name that exists with other types:

$ dig shop.example.com MX

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4711
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

NOERROR with an empty answer is NODATA: the name exists, the type does not, and the wildcard was not consulted.

You can also ask for the wildcard record itself. Quoted to keep the shell from expanding it, the asterisk is queried as a literal label:

$ dig +short '*.example.com'
192.0.2.20

Finally, test a deep name and a name under an existing subdomain (a.b.example.com, x.www.example.com). The first should match; the second should be NXDOMAIN, because www exists and has no wildcard of its own.

Common mistakes

• Expecting the wildcard to supply an A record for a subdomain that already has a TXT, MX or any other record.
• Adding _dmarc.sub or _acme-challenge.sub and being surprised that sub no longer resolves.
• Assuming *.example.com covers example.com. It never does, in DNS or on certificates.
• Assuming a wildcard certificate covers a.b.example.com because the DNS wildcard does.
• Writing *.example.com. into a panel that appends the zone name, producing *.example.com.example.com.
• Forgetting the wildcard when moving nameservers; it is one line and easy to overlook in an export.
• Using a wildcard to avoid keeping an inventory of subdomains. You still need the inventory; you have just made it harder to build.

Check it with OrbitProbe

Enter an invented subdomain of your domain in the OrbitProbe DNS lookup: if public resolvers return records for it, a wildcard is answering, and the tool shows which types and TTLs it serves. Then look up a subdomain you actually use and compare. A real subdomain that returns no address while invented ones do is the "name exists" rule at work. For the record types themselves, see DNS record types explained.