Wildcard DNS Records: What `*.example.com` Actually Matches

Most DNS records answer for one specific name. A wildcard record answers for names that were never defined at all. Point *.example.com at an IP address, and a query for anything.example.com, a subdomain you never created, gets a real answer instead of NXDOMAIN. It's a small piece of syntax with a surprisingly sharp set of edges.

What a wildcard record actually is

A wildcard is written with a literal asterisk as the leftmost label:

*.example.com.    A    203.0.113.42

Any query for a subdomain of example.com that has no record of its own matches this and gets 203.0.113.42 back. It works the same way for other record types too: a wildcard CNAME, a wildcard MX, even a wildcard TXT are all valid syntax, though not all of them are a good idea, covered below.

What it does and doesn't match

The asterisk only covers one label at that specific level. *.example.com matches anything.example.com, but it does not match deeper.anything.example.com, a query two labels below the apex isn't covered by a wildcard defined one label below it. Covering both would require a second wildcard at the deeper level, *.anything.example.com, which isn't practical unless anything is itself a fixed, known label.

The other sharp edge: a specific record always wins over a wildcard, even where both could apply. If blog.example.com has its own explicit A record, a query for blog.example.com gets that record's answer, not the wildcard's, regardless of which one was created first. The wildcard only fires for names with nothing more specific defined.

Common uses

Multi-tenant platforms. A SaaS product that gives every customer a subdomain, acme.example.com, initech.example.com, without provisioning a DNS record per signup, is the textbook use case. One wildcard record covers every current and future tenant automatically.

Catch-all staging or preview environments. Some teams wildcard a subdomain specifically for ephemeral environments, pr-1234.preview.example.com, so a CI pipeline can spin up a new preview URL without touching DNS for each one.

Typo and stray-subdomain handling. Rather than letting an unrecognized subdomain return NXDOMAIN, a wildcard can route it somewhere deliberate, a redirect, a landing page, or a controlled "not found" response, instead of an ambiguous DNS-level failure.

The email problem

A wildcard MX record is valid syntax and a bad idea in almost every real setup. It means any subdomain that doesn't exist, including a typo nobody meant to create, suddenly accepts mail. That's a wider surface for misdirected or spoofed mail to land somewhere unexpected, and it works against the specificity that SPF, DKIM, and DMARC are built around: authentication policies are typically scoped to specific sending domains, not a wildcard's worth of subdomains nobody's tracking. Almost every real mail setup keeps MX records explicit, one subdomain at a time, and leaves wildcards out of the picture entirely for anything mail-related.

Wildcards and TLS certificates

A single wildcard certificate, *.example.com, covers every matching subdomain with one cert instead of issuing one per hostname. The trade-off is on the validation side: a wildcard doesn't correspond to any single, connectable hostname, so a certificate authority can't validate it by serving a file over HTTP or responding to a TLS handshake at a specific address the way it would for an ordinary domain. It has to validate ownership of the underlying DNS zone itself instead, which is a meaningfully different, DNS-based process.

Checking whether a domain has one

There's no dig query type for "wildcard" specifically, since as far as the protocol is concerned it's just an A, CNAME, or other record with an unusual name. The way to confirm one exists is to query a subdomain you're confident was never explicitly created:

dig A definitely-not-a-real-subdomain-12345.example.com

An answer instead of NXDOMAIN means a wildcard is catching it. NXDOMAIN means either no wildcard exists, or one exists at a different level than the name you tried. OneDollarDNS's DNS Lookup tool runs this kind of check without a terminal.

How DNS monitoring fits in

A wildcard record changing is exactly as consequential as any other record change, arguably more so, since it silently reroutes every subdomain that isn't individually defined rather than just one name. OneDollarDNS monitors wildcard records the same way it monitors any other: a change to what *.example.com resolves to shows up as an alert, whether that wildcard covers a handful of tenant subdomains or effectively your entire unclaimed namespace.