Does a wildcard *.example.com match multiple levels, like a.b.example.com?

It can — but only while nothing sits between them. RFC 4592 synthesizes a wildcard answer for any name under example.com that has no closer existing node. So `*.example.com` will answer for `a.example.com` and for `a.b.example.com` too, as long as `b.example.com` doesn't exist in the zone. The moment you add any record at or below `b.example.com`, that name becomes a real node, and `a.b.example.com` stops matching the wildcard and returns NXDOMAIN. The wildcard only reaches names whose parent is the closest existing node above them.

Why did my wildcard stop working for one subdomain after I added an unrelated record?

Because you created an exact node, and exact matches always beat the wildcard. If `*.example.com` has an A record but you then add a TXT record on `api.example.com`, then `api.example.com` now exists as its own node. A query for its A record returns NODATA (empty), not the wildcard's A — the wildcard is only consulted for names that don't otherwise exist. This also bites wildcard MX: a wildcard MX covers only hosts that aren't listed in the zone at all, so any subdomain that already has, say, an A record won't inherit the wildcard MX.

Does a *.example.com SSL certificate cover a.b.example.com and the apex?

No on both counts. A wildcard certificate for `*.example.com` matches exactly one label to the left — `www.example.com`, `api.example.com` — and nothing deeper. `a.b.example.com` needs its own cert or a `*.b.example.com` wildcard. The bare apex `example.com` is also not covered by `*.example.com`; if you want both, the certificate has to list `example.com` and `*.example.com` as separate names. This mismatch between what a wildcard DNS record reaches and what a wildcard cert validates is a common source of cert-name errors.

Wildcard DNS Record Setup: What * Actually Matches

Problem

You added a *.example.com record so that every subdomain — app., api., staging., anything a colleague invents next week — resolves without you touching DNS again. It felt like a shortcut that would save you a hundred future tickets. Then one subdomain didn’t resolve, or resolved to the wrong place, and now you’re wondering whether the wildcard is even doing anything.

The wildcard almost certainly works. What surprises people is which names it reaches, and — more often — which names it silently stops reaching the moment you add some other record. Wildcards in DNS follow a specific set of rules from RFC 4592, and none of them are the intuitive “match everything below” you probably assumed.

What a wildcard actually is

A wildcard is a normal record whose leftmost label is a single asterisk: *.example.com. It tells the nameserver to synthesize an answer for names that don’t have their own record. Query whatever.example.com, the server finds no exact match, sees the wildcard, and answers as if whatever.example.com had that record all along.

Three rules govern it, and they explain nearly every wildcard surprise:

The asterisk is only a wildcard as the leftmost label. *.example.com is a wildcard. sub.*.example.com is not — there the * is a literal asterisk character in a name, which is almost never what you want.
An exact match always wins. If www.example.com has its own A record, the wildcard is never consulted for www.
The wildcard only reaches names whose closest existing ancestor is its parent. This is the one that bites, and it deserves its own section.

The empty-non-terminal footgun

Say you have exactly one record: *.example.com A 203.0.113.10. Right now it answers for a.example.com, b.example.com, and even a.b.example.com — anything under example.com with no record of its own.

Now you add one unrelated record: logs.metrics.example.com A 203.0.113.99.

You’ve just quietly created metrics.example.com as a node in the tree — an empty non-terminal. It owns no records itself, but it exists because something lives below it. And because it now exists, it becomes the closest ancestor for anything under it. So foo.metrics.example.com no longer matches *.example.com; the wildcard’s parent (example.com) is no longer the closest node above foo.metrics.example.com. That name returns NXDOMAIN.

The wildcard didn’t change. You never edited it. But adding a record three labels deep pulled a whole branch out from under it. This is the single most common “the wildcard broke and I didn’t touch it” report, and RFC 4592 is quite clear that this is working as designed — the wildcard was never meant to be a catch-all across arbitrary depth.

The corollary for record types: a wildcard is consulted per type, and only for names that don’t otherwise exist. A *.example.com MX record does not give an MX to www.example.com if www already has an A record — www exists, so the wildcard never applies to it. Wildcard MX only covers names that are entirely absent from the zone.

The SSL half nobody mentions

Your DNS wildcard and your TLS wildcard do not agree on what “wildcard” means.

A *.example.com certificate matches exactly one label: api.example.com is covered, a.b.example.com is not, and the bare apex example.com is not either. So you can have a DNS wildcard cheerfully resolving a.b.example.com to your server, and the browser still throwing a certificate-name error, because the wildcard cert only validates one level down. If you serve multi-level subdomains, each level needs its own wildcard (*.b.example.com) or a SAN entry.

Check both sides before you assume the wildcard is fine: confirm what the name resolves to, then confirm the certificate actually lists a name that matches it.

Diagnosis with DechoNet

DNS Lookup — Query a specific subdomain and a made-up one (does-not-exist-123.example.com). If the invented name returns your wildcard’s value, the wildcard is live; if a real subdomain returns NXDOMAIN, look for an intervening node that broke synthesis.
SSL Check — Confirm the served certificate lists a name that matches the depth you’re actually using — *.example.com won’t validate a two-label-deep host.

Setup and safety checklist

In the name/host field, enter just * (your DNS panel appends the zone) — not *.example.com, which most panels would turn into *.example.com.example.com.
Pick the record type you actually need: * A/AAAA for a catch-all IP, * CNAME to point every unlisted subdomain at a platform hostname.
Remember exact records win: any subdomain with its own record ignores the wildcard, and creating a deep record can strand a whole branch as an empty non-terminal.
Match your certificate to your depth — a *.example.com cert covers one label only, not the apex and not two levels deep.
Treat a wildcard CNAME to a third-party service as a takeover surface: it points every possible subdomain at that provider, so if the target is ever deprovisioned, your entire namespace becomes claimable. Scope wildcards narrowly and remove them when the service goes away.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.