Wildcard DNS records explained: how *.example.com works

A wildcard DNS record uses an asterisk to answer for any subdomain that has no record of its own. With *.example.com pointing to your server, anything.example.com resolves without creating each name. This guide explains how wildcard DNS records work and when to use them.

Before you start

You need access to the DNS zone, for example cPanel → Domains → Zone Editor.

A basic wildcard

*.example.com.     3600  IN  A  203.0.113.50
blog.example.com.  3600  IN  A  198.51.100.9

• shop.example.com → 203.0.113.50 (matched by the wildcard).
• blog.example.com → 198.51.100.9 (an explicit record always wins).
• example.com itself is not matched – the root needs its own record.

The rules

• Only the leftmost label can be *. *.example.com is valid; shop.*.example.com is not a wildcard.
• One level per match in practice: *.example.com matches a.b.example.com too, unless b.example.com exists as a name (with any record type), which blocks the wildcard beneath it.
• Type-specific: a wildcard A record does not answer MX or TXT queries unless you add wildcard records of those types too.
• Existing names block wildcards: if shop.example.com has only an MX record, an A query for it returns no data rather than the wildcard A.

Common uses

• SaaS and multi-tenant apps where each customer gets customer.yourapp.com.
• WordPress Multisite with subdomain sites.
• Development and preview environments such as feature-x.dev.example.com.
• Catching typos and redirecting unknown subdomains to the main site.

The web server must also accept those names: a wildcard server alias in Apache (ServerAlias *.example.com) or Nginx (server_name *.example.com), or a wildcard subdomain in cPanel.

Wildcards and SSL

A wildcard DNS record does not give you HTTPS for every subdomain. You also need a wildcard certificate (*.example.com), which from Let's Encrypt requires DNS-01 validation. A wildcard certificate covers one level only: a.example.com, but not a.b.example.com.

Add a wildcard in cPanel

1. Open Zone Editor → Manage for the domain.
2. Add an A record with name *.example.com. and your server's IP.
3. To serve content, create a subdomain named * in Domains, pointing to the document root you want.

Risks and downsides

• Hides mistakes: typos in hostnames resolve instead of failing, which makes debugging harder.
• Subdomain takeover patterns: wildcard CNAMEs to external services you no longer control can be abused.
• Email: avoid wildcard MX unless you really want mail for every subdomain.
• SEO duplicates: random subdomains serving the main site create duplicate content – redirect unknown hosts to the canonical domain.

Test a wildcard

dig random123.example.com A +short
dig blog.example.com A +short

FAQ: wildcard DNS

Does a wildcard slow down DNS?

No. Authoritative servers answer wildcard matches as quickly as normal records.

Can I use a wildcard CNAME?

Yes, *.example.com CNAME target.example.net. is valid, but remember CNAME rules still apply to each matched name.

Why doesn't my root domain resolve?

Wildcards never match the zone apex; add an A record for @.

Next steps

• Wildcard SSL certificates
• DNS A and AAAA records explained
• DNS CNAME record explained