Skip to content
Webmaster Tools
DNS & domainsDNS LookupWildcard DNS record

Wildcard DNS record

How a wildcard DNS record like *.example.com answers for names that don't exist, why it doesn't cover the apex or deeper levels, and how to test it with dig.

What it is

A wildcard record has * as its leftmost label, such as *.example.com. When a resolver asks for a name under example.com that doesn't exist in the zone, the server synthesizes an answer from the wildcard, using the name that was asked for. The rules are in RFC 1034 §4.3.3, clarified by RFC 4592. Wildcards are common for multi-tenant apps (customer1.example.com, customer2.example.com) and preview environments.

example.com.        3600  IN  A      203.0.113.10
*.example.com.      3600  IN  A      203.0.113.20
www.example.com.    3600  IN  CNAME  example.com.

Here anything.example.com answers 203.0.113.20, www.example.com follows its own CNAME, and example.com uses its own A record.

How it works

Query Answer from the zone above Why
shop.example.com A 203.0.113.20 Name doesn't exist, wildcard matches
www.example.com A CNAME to example.com Name exists, wildcard ignored
example.com A 203.0.113.10 The wildcard never covers the apex
a.b.example.com A 203.0.113.20 No b.example.com exists, so * stands in for a.b
www.example.com MX CNAME, then the MX of example.com www exists, so the wildcard isn't used for any type

The key rules:

  • Only names that don't exist. If a name has any record of any type, the wildcard isn't used for it, even for other types. A name that exists only because something sits below it (an "empty non-terminal": _domainkey.example.com when you have sel._domainkey.example.com) also blocks the wildcard.
  • Not the apex. *.example.com never answers for example.com itself.
  • One label in certificates, not in DNS. In DNS, * can stand for several labels if nothing in between exists. A wildcard TLS certificate for *.example.com covers exactly one label: shop.example.com but not a.b.example.com or example.com.
  • * only as the whole leftmost label. *.shop.example.com is fine; shop*.example.com or a.*.example.com aren't wildcards.

Common setups

  • SaaS subdomains: *.app.example.com CNAME to a load balancer, plus a wildcard certificate.
  • Vercel and Netlify accept wildcard domains, which generally requires using their name servers so they can issue the certificate via DNS validation.
  • Cloudflare supports proxied wildcard records on all plans.

How to check it

Look up a random name that you never created in our DNS Lookup. If it returns an address, a wildcard is in place. With dig:

dig random-test-123.example.com A +short
dig '*.example.com' A +short
nslookup random-test-123.example.com

Quote the * so the shell doesn't expand it.

Common mistakes

  • Expecting the wildcard to cover the root domain: add an A or ALIAS at the apex too.
  • Adding a TXT or MX at foo.example.com and wondering why its A record vanished: the name now exists, so the wildcard no longer answers there.
  • A wildcard MX or TXT (SPF) catching typo subdomains and making them look like valid mail domains.
  • Mail sent to user@typo.example.com resolving because of a wildcard A record.
  • Hiding mistakes: with a wildcard, misspelled hostnames resolve instead of failing clearly.
  • A record: the usual wildcard type.
  • CNAME record: a wildcard CNAME to a load balancer.
  • TXT record: wildcard TXT and its side effects.
  • CAA record: which CA may issue the wildcard certificate (issuewild).