▲ Quick answer

A wildcard domain uses an asterisk label — *.example.com — as a catch-all that matches any subdomain you have not explicitly defined. In DNS, a wildcard record answers for all such subdomains at once; a wildcard SSL certificate secures all first-level subdomains with a single certificate. It covers one level only, not deeper ones.

The wildcard is one of those tools that turns a tedious, repetitive job into a single line. Instead of defining hundreds of subdomains by hand, you define one pattern. Understanding exactly what that pattern matches — and what it doesn’t — is the whole game.

What is a wildcard domain?

“Wildcard” borrows the card-game idea of a card that can stand for any other. In domains, the asterisk (*) is that wild card: *.example.com stands in for any single subdomain label — blog.example.com, shop.example.com, literally-anything.example.com — provided you haven’t created a specific record for that exact name. The behavior is defined in the original DNS specifications (RFC 1034, clarified by RFC 4592).

Wildcard domain

A domain using an asterisk label (*.example.com) that matches any single-level subdomain without its own explicit record — used for catch-all DNS and for SSL certificates covering all first-level subdomains.

Wildcard DNS records

A wildcard DNS record simply uses * as the host name. Create an A record for *.example.com pointing at an IP, and every undefined subdomain — whatever someone types — resolves to that address. It is the classic “catch-all” for subdomains.

One important subtlety: an explicit record always wins over the wildcard. If you have both *.example.com and a specific shop.example.com, then shop uses its own record and everything else falls through to the wildcard.

i

One level, not all levels

*.example.com matches x.example.com but not x.y.example.com. Wildcards apply to a single label position; deeper names need their own wildcard at that level.

Wildcard SSL/TLS certificates

The other common “wildcard” you’ll meet is in HTTPS. A wildcard certificate is issued for *.example.com and secures every first-level subdomain with one certificate — so www, blog, app and any future subdomain are all covered, with no need to request a new certificate each time you add one. The rules for issuing them are set by the CA/Browser Forum.

What a wildcard certificate for *.example.com does and doesn’t cover.
NameCovered?
blog.example.comYes
shop.example.comYes
example.com (the apex)Not automatically (often added separately)
a.b.example.comNo (deeper level)

When to use a wildcard

Wildcards shine when subdomains are numerous or unpredictable. Common cases include: SaaS platforms that give each customer their own subdomain (customer1.example.com); development and staging environments spun up on the fly; sites that generate subdomains dynamically; and any project where managing each subdomain’s DNS and certificate by hand would be impractical.

Cautions and best practice

!

Convenience cuts both ways

A wildcard DNS record makes every undefined subdomain resolve, which can accidentally expose internal services or help attackers with subdomain-based tricks. And a wildcard certificate’s private key, if compromised, exposes all your subdomains at once. Use wildcards deliberately, restrict them where you can, and protect the certificate key carefully.

Where you only need a handful of fixed subdomains, explicit records and per-host certificates are often safer and clearer. Reach for the wildcard when scale or unpredictability genuinely calls for it.

Why wildcard domains matter

Wildcards are a force multiplier for anyone running many subdomains: one DNS rule and one certificate can replace hundreds of manual entries. Knowing precisely what a wildcard matches — one level deep, only where no explicit record exists — lets you use that power confidently, and avoid the surprises that come from a catch-all quietly answering for names you never intended.

★ Key takeaways

  • A wildcard domain uses * to match any undefined subdomain at one level.
  • Wildcard DNS is a catch-all record; an explicit record always overrides it.
  • A wildcard SSL certificate secures all first-level subdomains with one cert.
  • Wildcards cover a single level only — and their convenience carries real security trade-offs.

Frequently asked questions

What is a wildcard domain in simple terms?

A wildcard domain uses an asterisk — *.example.com — to stand for any subdomain that you have not specifically defined. Instead of creating a record for blog, shop, app and so on individually, one wildcard rule answers for all of them.

What is a wildcard DNS record?

It is a DNS record whose name is an asterisk label, like *.example.com. It matches every subdomain at that level that has no explicit record of its own, returning the wildcard’s value — a catch-all for subdomains.

What is a wildcard SSL certificate?

A wildcard SSL/TLS certificate secures a domain and all of its first-level subdomains with one certificate, issued for *.example.com. It means blog.example.com, shop.example.com and any other direct subdomain are all covered without separate certificates.

Does a wildcard cover multiple subdomain levels?

No. A wildcard like *.example.com matches only one level — anything.example.com — not deeper names like a.b.example.com. To cover a deeper level you would need a wildcard at that level, such as *.b.example.com.

Are wildcard domains risky?

They can be if misused. A wildcard DNS record can unintentionally make every undefined subdomain resolve, which may expose services or aid abuse. A wildcard certificate, if its private key leaks, exposes all subdomains at once. Used deliberately, with care, both are safe and convenient.

When should I use a wildcard instead of individual records?

Use a wildcard when subdomains are numerous, dynamic or unpredictable — for example a platform that gives each customer their own subdomain. When you only need a handful of fixed subdomains, explicit records (and per-host certificates) are usually clearer and safer. Reach for the wildcard only when scale genuinely justifies it.

Sources & further reading