A wildcard DNS record (*.example.com) lets you point any subdomain to the same IP address or hostname. This is needed for WordPress Multisite and SaaS applications, where each user gets their own subdomain.

A typical scenario is a platform such as a hosted storefront builder, where each customer gets an address like customer.platform.com. Without a wildcard you'd have to create a separate A record for every new customer by hand; with a wildcard, you configure DNS once and after that the routing by subdomain name is handled by the application on the server, not by the DNS zone.

Creating a Wildcard Record

In cPanel → Zone Editor

Add an A record:

Name: *
Type: A
Value: 192.168.1.100 (your IP)

In Cloudflare

Type: A
Name: *
Content: 192.168.1.100
Proxy status: DNS only (grey icon) or Proxied

✅ A wildcard record only works for one level: *.example.com does not cover sub.sub.example.com.

Not every DNS panel handles the * character the same way. Some registrars' basic free panels limit which records you can create and simply don't offer a wildcard as an option — in that case the zone gets moved to a DNS provider with full support, such as the hosting panel or Cloudflare, rather than looking for a workaround.

Wildcard SSL Certificate

HTTPS on all subdomains requires a wildcard SSL certificate:

# Certbot wildcard via DNS-01 challenge
certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.example.com" \
  -d "example.com"

# Automatically via acme.sh + Cloudflare API
acme.sh --issue \
  --dns dns_cf \
  -d "*.example.com" \
  -d "example.com"

⚠️ Let's Encrypt wildcard certificates require a DNS-01 challenge — API access to the DNS provider is needed for auto-renewal.

Let's Encrypt certificates only last 90 days, so the manual --manual run shown above is only suitable for a one-off check. In production, the DNS-01 challenge is set up through the specific DNS provider's plugin (dns_cf for Cloudflare, similar ones for others), so acme.sh or certbot can add and remove the verification TXT record themselves on every renewal without a human involved.

Usage in WordPress Multisite

# In /etc/apache2/sites-available/multisite.conf
ServerName example.com
ServerAlias *.example.com

# Or in Nginx
server {
    server_name ~^(.+)\.example\.com$;
    set $subdomain $1;
}

Checking the Wildcard Record

# Should resolve identically:
dig anything.example.com A
dig test123.example.com A
dig myapp.example.com A

It's worth testing on several random names rather than just one: if the zone still has an old explicit record left over for one specific subdomain, only a test against three or four different names will reveal the mismatch — a query to that one leftover name will return a different IP than a query to any arbitrary name.

Common Wildcard Record Errors

Behavior	Cause	Fix
Different subdomains resolve differently even though a wildcard exists	A separate explicit record exists for one specific subdomain, for example blog.example.com A ...	Check the full list of zone records for a conflict with the wildcard — an explicit record always takes priority
sub.sub.example.com doesn't resolve	A wildcard only covers one level of nesting, per RFC 1034	Create a separate wildcard *.sub.example.com, or an explicit record for that name
Let's Encrypt: Invalid response ... urn:ietf:params:acme:error:dns	An HTTP-01 challenge was used instead of the DNS-01 challenge required for wildcards	Switch to DNS-01, as in the certbot/acme.sh example above
An MX record doesn't work through the wildcard	The standard advises against relying on a wildcard for MX; many mail systems ignore such answers	Create an explicit MX record for the specific mail subdomain

Wildcard vs. Explicit Records: Priority

Situation	Which record wins	Why
There's a wildcard *.example.com A and an exact record blog.example.com A	the exact record	DNS always prefers the more specific name match
There's a wildcard *.example.com and a CNAME at sub.example.com	the CNAME	the same specificity principle applies
There's a top-level wildcard but none for *.sub.example.com	neither — NXDOMAIN, if there's no explicit record	a wildcard doesn't inherit down to a deeper nesting level

When a Wildcard Doesn't Fit

You need an explicit list of allowed subdomains for an application with access control — a DNS wildcard doesn't replace authorization checks at the application level
Some subdomains need to point to different IPs or services — then you need separate A/CNAME records, and the wildcard only covers them as a fallback for names not accounted for
You need to bind a subdomain to mail (MX) — use a dedicated MX record, don't rely on the wildcard, see configuring MX for mail
SSL is only needed for 2–3 specific subdomains — a regular SAN certificate for those exact names is simpler to issue than a wildcard with its mandatory DNS-01 challenge, see the ACME DNS challenge for SSL