What Is a Wildcard DNS Record, and When Should You Use It?
Imagine you are launching a SaaS product where every customer gets their own address: acme.example.com, globex.example.com, initech.example.com, and hundreds more. Creating a separate DNS record every time someone signs up would be tedious and slow. A wildcard DNS record solves this with one entry, *.example.com, that answers for any subdomain you have not explicitly defined. It sounds simple, and mostly it is, but the matching rules have a few surprises that catch people out, and a careless wildcard can create security and email problems. This article explains how wildcard matching actually works according to the standard, shows real zone-file examples, and covers when a wildcard is the right tool and when it is not. If you are new to subdomains, How to Set Up Subdomains in DNS Settings is a good primer.
What Is a Wildcard DNS Record?
A wildcard DNS record is any record whose owner name starts with an asterisk label, such as *.example.com. When a resolver asks for a name in the zone that does not exist, the authoritative server can synthesise an answer from the wildcard instead of returning NXDOMAIN.
Wildcards are not a separate record type. You can have a wildcard A record, AAAA record, CNAME, MX, TXT, and so on. The asterisk is just a special owner name that the authoritative server treats as a pattern.
$ORIGIN example.com.
$TTL 3600
@ IN A 203.0.113.10
www IN A 203.0.113.10
api IN A 203.0.113.20
* IN A 203.0.113.30
With this zone, www.example.com returns 203.0.113.10 and api.example.com returns 203.0.113.20, because those names exist. Any other name, like acme.example.com or test123.example.com, returns 203.0.113.30 from the wildcard.
How Wildcard Matching Really Works
The rules are defined in RFC 1034 section 4.3.3 and clarified in RFC 4592, "The Role of Wildcards in the Domain Name System." The important parts are less intuitive than "asterisk matches anything."
1. A wildcard only applies when the name does not exist
A wildcard is a fallback. If a name exists in the zone, with any record type at all, the wildcard does not apply to it. That has a consequence people often miss:
mail IN MX 10 mx.example-mail.net.
* IN A 203.0.113.30
Here, mail.example.com exists because it has an MX record. A query for mail.example.com A will not use the wildcard. It returns an empty answer (NOERROR with no data), because the name exists but has no A record. If you want both, you must add an explicit A record for mail.
2. The asterisk must be the leftmost label
*.example.com and *.dev.example.com are valid wildcards. foo.*.example.com or web*.example.com are not wildcards: the asterisk is treated as a literal character, and some providers reject such names outright.
3. A wildcard can match multiple levels
*.example.com matches a.example.com, but it also matches a.b.example.com, as long as neither a.b.example.com nor b.example.com exists. The wildcard matches whatever is missing beneath its parent, not only one label.
4. Existing intermediate names block the wildcard
If dev.example.com exists (even if it only exists because api.dev.example.com is defined, which makes dev an empty non-terminal), then anything.dev.example.com will not match *.example.com. The lookup stops at the closest existing name, dev.example.com, and only a wildcard directly beneath it (*.dev.example.com) could match.
* IN A 203.0.113.30
api.dev IN A 203.0.113.40
With these two records:
| Query | Result | Why |
|---|---|---|
foo.example.com | 203.0.113.30 | Name does not exist; wildcard matches |
a.b.example.com | 203.0.113.30 | Neither name exists; wildcard matches |
api.dev.example.com | 203.0.113.40 | Explicit record |
dev.example.com | NOERROR, no data | Exists as an empty non-terminal |
foo.dev.example.com | NXDOMAIN | Closest encloser is dev, which has no wildcard |
example.com | Apex record (if any) | Wildcards never match the parent name itself |
5. A wildcard never covers its own parent
*.example.com does not match example.com. The apex needs its own records.
6. Delegated subdomains are not covered
If eu.example.com is delegated to other nameservers with NS records, the wildcard in the parent zone does not apply to names below it. That subzone is a separate zone with its own rules. For more on how zones and delegations split a namespace, see What Is the Difference Between a DNS Zone and a Domain?
Testing Wildcard Behaviour
You can see wildcard matching with dig by querying a random name that you know does not exist:
dig "$(openssl rand -hex 6).example.com" A +noall +answer
This builds a random 12-character label (for example 3f9a1c7b2e04.example.com) and queries it. If the zone has a wildcard A record, you will get an answer with the queried name as the owner, not *.example.com. The server rewrites the owner name, so clients never see the asterisk. If there is no wildcard, you will get NXDOMAIN. More on reading response codes is in What Do NXDOMAIN, SERVFAIL, and REFUSED Mean?
To query the wildcard record itself, ask for the literal name:
dig "*.example.com" A +short
The quotes stop your shell from expanding the asterisk into filenames.
Here is a small Python script that checks whether a zone has a wildcard by testing several random names:
import secrets
import dns.resolver
def has_wildcard(zone, rtype="A", samples=3):
answers = set()
for _ in range(samples):
name = f"{secrets.token_hex(8)}.{zone}"
try:
result = dns.resolver.resolve(name, rtype)
answers.update(r.to_text() for r in result)
except dns.resolver.NXDOMAIN:
return False, set()
except dns.resolver.NoAnswer:
return True, set()
return True, answers
found, values = has_wildcard("example.com")
print("wildcard:", found, sorted(values))
If any random name returns NXDOMAIN, there is no wildcard for that type. If they all resolve, the zone has one, and the script prints the values it returns. A NoAnswer result means a wildcard exists but holds a different record type.
Wildcard Records with Other Types
Wildcard CNAME
A wildcard CNAME sends every undefined subdomain to one hostname, which is common when a hosting platform or CDN routes tenants by the HTTP Host header:
* IN CNAME tenants.example-platform.net.
Because this is a CNAME, the usual rule still applies: the * name cannot hold other record types alongside it.
Wildcard MX and TXT
Wildcard MX records accept mail for any subdomain, such as anything@random.example.com. That is occasionally useful but often invites spam to arbitrary addresses. Wildcard TXT records are more problematic. They give every non-existent subdomain the same TXT data, which can confuse services that look up TXT at specific names, such as _dmarc or DKIM selectors. Because _dmarc.example.com would not exist, a wildcard TXT would answer for it with whatever value you set, which may be nonsense to a DMARC checker. If you need email records, define them explicitly, as described in What Is a TXT Record?
When Should You Use a Wildcard?
Wildcards are a good fit when names are created dynamically and all point at the same place.
- Multi-tenant SaaS. Customer subdomains such as
acme.example.comall hit one load balancer, and the application decides which tenant to serve from the hostname. - Preview and staging environments. Platforms that give each branch or pull request its own hostname, such as
pr-482.preview.example.com, use a wildcard under a dedicated subdomain. - Development and local tooling. A wildcard under
dev.example.compointing at an internal IP lets developers spin up services without touching DNS. - Catch-all landing pages. Mistyped or retired subdomains can land on a helpful page instead of a browser error.
When You Should Not Use a Wildcard
- When you have a small, fixed set of subdomains. Explicit records are clearer and safer.
- At the top of your main zone, without thought. A root-level
*.example.commakes every typo resolve, so misconfigured clients fail in confusing ways instead of with a clean NXDOMAIN, and it hides missing records during troubleshooting. - With a CNAME to a third-party service you might leave. If you stop using the platform but forget the wildcard, every subdomain now points at a resource someone else could claim. That is the classic setup for subdomain takeover, explained in What Is a Dangling DNS Record?
- For email-related TXT records. Define SPF, DKIM and DMARC records explicitly.
Wildcard DNS vs Wildcard SSL Certificates
A wildcard DNS record and a wildcard TLS certificate are separate things that are often used together. A certificate for *.example.com covers exactly one label: acme.example.com yes, a.b.example.com no, and example.com no. DNS wildcards, as shown above, can match multiple levels. If your wildcard DNS serves deeper names, your certificate must cover them too.
Let's Encrypt only issues wildcard certificates through the DNS-01 challenge, because you have to prove control of the whole zone, not just one web server. A typical certbot command using a DNS plugin looks like this:
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d "example.com" -d "*.example.com"
This requests one certificate covering the apex and all first-level subdomains, using the Cloudflare DNS plugin to create the required _acme-challenge TXT records automatically. Plugins exist for many other DNS providers. The full mechanism is explained in How Does the DNS-01 Challenge Work?
Wildcards and DNSSEC
Wildcards work with DNSSEC, but the server has to prove two things in a signed answer: that the queried name does not exist, and that the wildcard is the closest match. It does this by including NSEC or NSEC3 records alongside the synthesised answer. Modern authoritative servers handle this automatically. Signed responses to wildcard queries are slightly larger as a result, and the RRSIG reveals that a wildcard was used, since its label count is lower than the queried name's.
Wildcard DNS Records FAQ
No. A wildcard like *.example.com only applies to names below example.com. The root domain needs its own A, AAAA or ALIAS records.
No. Explicit records always win. A wildcard only answers for names that do not exist in the zone at all, regardless of record type.
Because that subdomain already exists. Once a name has any record, the wildcard no longer applies to it, so you must add the A record for that name explicitly.
No. Only an asterisk as the leftmost label acts as a wildcard. An asterisk elsewhere is treated as a literal character, and many providers will not accept it.
Yes, as long as none of the intermediate names exist. *.example.com can answer for a.b.example.com unless b.example.com exists.
Yes. A wildcard CNAME is common for multi-tenant platforms. The usual CNAME rules still apply, so the wildcard name cannot hold other record types alongside it.
It can be. A forgotten wildcard pointing at a third-party service is an easy route to subdomain takeover, and wildcards hide typos that would otherwise fail visibly. Use them deliberately and review them when services change.
If you serve HTTPS on the wildcard names, yes, or you need a certificate per hostname. Remember that a wildcard certificate only covers one subdomain level.
Conclusion
A wildcard DNS record is a powerful shortcut: one line in your zone can answer for an unlimited number of subdomains. That makes it ideal for multi-tenant applications, preview environments and developer tooling. The catch is that wildcards follow precise rules. They only apply to names that do not exist, they are blocked by any existing intermediate name, they never cover the parent, and they can reach several levels deep.
Use wildcards when names are genuinely dynamic, keep them scoped to a dedicated subdomain where you can, define email-related records explicitly, and remove them promptly when the service behind them goes away. Do that, and a wildcard will save you time without creating surprises.
Here are some useful references for going deeper on wildcard DNS records:
- RFC 4592: The Role of Wildcards in the Domain Name System — the authoritative clarification of wildcard matching rules.
- RFC 1034: Domain Names - Concepts and Facilities — section 4.3.3 defines the original wildcard behaviour.
- BIND 9 Documentation: BIND 9 Administrator Reference Manual — zone-file syntax, including wildcard owner names, for the most widely used authoritative server.
- Let's Encrypt: Challenge Types — explains why wildcard certificates require the DNS-01 challenge.
- Certbot Documentation: DNS Plugins — the certbot plugins used to automate DNS-01 validation.
