Wildcard DNS Records Explained

Imagine you're running a SaaS application where every customer gets their own subdomain: acme.yourapp.com, techcorp.yourapp.com, startup47.yourapp.com. You have 10,000 customers. Do you create 10,000 DNS records?

You create one.

A wildcard DNS record uses an asterisk (*) to match any subdomain that doesn't have its own specific record. In DNS zone file syntax:

*.example.com.  3600  IN  A  192.0.2.100

That asterisk is a catch-all. When someone requests anything.example.com, the DNS server checks: does anything.example.com have its own record? No? Then the wildcard answers.

The Mental Model

A wildcard is a default case—like the default in a switch statement or the else at the end of a conditional chain. It only fires when nothing more specific matches.

Once you see it that way, the matching rules become obvious:

Specific records always win. If you have both *.example.com and app.example.com, queries for app.example.com use the specific record. The wildcard never overrides an explicit configuration. (The default case doesn't run when another case matches.)

Wildcards match exactly one level. *.example.com matches app.example.com but not api.app.example.com. This isn't arbitrary—it mirrors organizational boundaries. Your subdomain is yours to subdivide; the parent domain doesn't automatically claim your nested subdomains. If you need to catch *.app.example.com, create that record separately.

Wildcards don't match the apex. *.example.com handles subdomains, not example.com itself. The apex domain needs its own A or AAAA record.

This hierarchy means you can layer specific records on top of wildcards. Point www.example.com to your marketing site, api.example.com to your API servers, and let *.example.com handle everything else.

Why This Matters

Instant Subdomain Provisioning

Without wildcards, creating a new customer subdomain means adding a DNS record and waiting for propagation. With wildcards, the DNS layer is already handled—a new subdomain works the moment your application recognizes it.

Development Environments on Demand

A wildcard for *.dev.example.com lets developers spin up feature-xyz.dev.example.com or experiment.dev.example.com without touching DNS. Every branch can have its own subdomain.

User-Generated Subdomains

Blog platforms, portfolio sites, and website builders let users claim subdomains like yourname.platform.com. Wildcards make this work without manual configuration for each user.

Wildcard SSL Certificates

Wildcard DNS and wildcard SSL certificates work as a pair. A certificate for *.example.com secures any first-level subdomain with a single certificate.

The limitations mirror DNS wildcards:

• Only covers one subdomain level
• Doesn't cover the apex domain (usually included via Subject Alternative Names)
• Requires DNS-based validation—you prove ownership by creating specific TXT records

The Dangers

Wildcards are powerful. Powerful things break in powerful ways.

Subdomain Takeover

This is the big one. If your wildcard CNAME points to a cloud provider and you decommission a service without cleaning up the reference, an attacker can claim that orphaned resource. They now serve content from your subdomain—with your domain's reputation and your users' trust.

The fix: use specific records for critical services, and audit your infrastructure regularly. DNS record deletion should be the first step when decommissioning anything.

Email Abuse

Wildcard MX records let spammers send email from arbitrary subdomains of your domain. spam-campaign.yourdomain.com damages your domain's reputation. Most email administrators avoid wildcard MX records entirely.

Certificate Control

Use CAA records with the issuewild property to specify which certificate authorities can issue wildcard certificates for your domain. Without this, any CA could issue a wildcard certificate for your domain if an attacker can prove control of a subdomain.

Amplification Attacks

Every subdomain query gets a response, which can be exploited for DNS amplification attacks. Rate limiting and DDoS protection become more important when wildcards are in play.

When to Use Wildcards

Use wildcards for:

• Multi-tenant applications with customer subdomains
• Development and staging environments
• User-generated content platforms
• Any scenario with dynamic, unpredictable subdomains

Use specific records for:

• Production infrastructure (api., www., mail.)
• Services with unique IP requirements
• Anything security-critical

The pattern: wildcards handle the long tail, specific records handle what matters most.

Sources