Wildcard DNS Records: How *.example.com Works

Intermediate⏱ 4 min readUpdated October 13, 2026

A record named *.example.com answers for every subdomain you never created: blog, test, anything-at-all. That makes per-customer subdomains and preview environments a one-line job. It also makes typos resolve, invites mail to hosts that do not exist and can hand a forgotten subdomain to someone else. The rules for what the asterisk matches are stricter than most people assume.

How a wildcard answers

A resolver asks for a name. If the zone has no such name, the server looks for a * record at the closest name that does exist, and answers as if the record had been written for the name asked (RFC 4592). Take this zone:

; zone example.com
example.com.        3600 IN A      203.0.113.10
www.example.com.    3600 IN CNAME  example.com.
shop.example.com.   3600 IN A      203.0.113.20
*.example.com.      3600 IN A      203.0.113.80

With *.example.com in the zone: an existing name keeps its own record, a missing name gets the wildcard, and a name under an existing one gets nothing.

Query	Answer	Why
`example.com` `A`	`203.0.113.10`	The apex is never matched by `*.example.com`.
`shop.example.com` `A`	`203.0.113.20`	The name exists, so the wildcard is ignored.
`blog.example.com` `A`	`203.0.113.80`	No such name: the answer is made from `*`.
`a.b.example.com` `A`	`203.0.113.80`	Neither `b` nor `a.b` exists, so it is still matched — over any number of labels.
`shop.example.com` `MX`	No records (NODATA)	The name exists. The wildcard never adds types a real name lacks.
`x.shop.example.com` `A`	NXDOMAIN	The closest existing name is `shop`, and there is no `*.shop.example.com`.

The rules that catch people out

Existing names are untouchable. If www has only a CNAME, a query for www TXT gets nothing from * — even if the wildcard has a TXT record.
A name is "existing" even without records of its own when something lives below it. Create api.dev.example.com and dev.example.com starts to exist: test.dev.example.com no longer reaches *.example.com.
The asterisk works only as the whole leftmost label. *.example.com is a wildcard; www.*.example.com, *-dev.example.com and *abc.example.com are ordinary, literal names.
A wildcard CNAME is allowed, but like any CNAME it cannot share its name with other records — *.example.com CNAME plus *.example.com MX is invalid.
Answers carry the name that was asked, not *. The client cannot tell a wildcard answer from a real record; only comparing with a random name reveals it.

Note: A wildcard TLS certificate is a different thing with a different rule: a certificate for *.example.com covers blog.example.com but not a.b.example.com or example.com itself. A DNS wildcard that resolves deep names does not make the certificate cover them.

When a wildcard is the right tool

SaaS with a subdomain per customer (acme.app.example): new customers work instantly, and the application decides from the Host header which tenant to show.
Preview and branch environments created and destroyed automatically, all served by one load balancer.
A catch-all redirect that sends any mistyped subdomain to the main site — if you accept the side effects below.

The risks

Typos look like success. ww.example.com or mial.example.com resolve and land on a server that may answer with a confusing page instead of a clear error.
Mail. A wildcard MX makes every invented subdomain a valid mail destination, which spammers notice; a wildcard A without any MX does the same through the A-record fallback. Publish a null MX and a strict SPF on the wildcard if it exists only for the web.
Subdomain takeover. A wildcard CNAME to a cloud service (*.example.com → example.azurewebsites.net) hands every unclaimed subdomain to whoever registers that target after you leave the service.
Hidden mistakes. A record you deleted keeps "working" through the wildcard, so a broken migration can go unnoticed — until the wildcard is removed.

; keep a web wildcard from inviting mail to every subdomain
*.example.com.  3600 IN MX   0 .              ; RFC 7505 "null MX"
*.example.com.  3600 IN TXT  "v=spf1 -all"

Watch out: Before adding a wildcard to a domain that sends mail or is used for logins, write down which subdomains must not resolve, and test them after the change.

How to check whether a domain has a wildcard

Ask for a name nobody would create. If it resolves, there is a wildcard (or a CDN or DNS provider that synthesizes answers). Then compare with a real subdomain:

# a label that surely does not exist — answered by the wildcard?
dig +short pixdns-test-7f3a.example.com A
# compare with a name that does exist
dig +short shop.example.com A

Tip: Paste the random name into the PixDNS DNS lookup to see the record type and TTL the wildcard returns. Subdomain enumeration tools filter wildcard answers out the same way: they resolve a random label first and discard everything that matches it.

Look up a random subdomain →Next: CNAME records explained →

Frequently asked questions

Does *.example.com cover example.com?

No. The wildcard matches names below the domain, never the domain itself. Keep a separate record for the apex.

Does *.example.com cover a.b.example.com?

In DNS, yes — as long as b.example.com does not exist. A wildcard TLS certificate, by contrast, covers only one level.

Why does my wildcard not work for one subdomain?

Because that name, or a name below it, exists in the zone. An existing name never gets answers from the wildcard, even for record types it does not have.

Can I use a wildcard for MX or TXT?

Yes, any record type can be a wildcard. A wildcard MX is rarely a good idea; a wildcard null MX and v=spf1 -all are a common safeguard.

Try it on your domain

See the theory in practice — run a DNS Lookup for your own domain.

Updated October 13, 2026

Sources