HostBible Wildcard DNS: How *.example.com Works, Use Cases, and Common Pitfalls

Wildcard DNS records let you point any (non‑explicit) subdomain of your domain to a destination, without creating each subdomain one by one. They’re especially useful for multi‑tenant apps (like customer1.example.com, customer2.example.com) or catch‑all subdomains (like preview links or short-lived environments).

This article explains how wildcard matching works, when it doesn’t apply, how to set up common wildcard records in HostBible, and how to troubleshoot the most common surprises.

Not covered here: changing/switching nameservers. If your domain isn’t using HostBible DNS, see our DNS Nameservers article.

A wildcard DNS record uses an asterisk (*) to match subdomains that don’t have an explicit record.

Example:

Wildcard DNS is a DNS feature—it does not create real “subdomain objects”. It simply tells resolvers where to go when someone asks for a name that isn’t explicitly defined.

Wildcard matching has a few rules that explain most “why doesn’t this work?” cases.

*.example.com matches one-subdomain.example.com
It does not match two.levels.example.com (like a.b.example.com).

If you need that, you typically create an additional wildcard at the next level, such as *.b.example.com.

If you create an explicit record for app.example.com, that name will use the explicit record—not the wildcard.

This is usually what you want (and it’s a great way to override a wildcard for specific subdomains like www, api, or mail).

This is the most common pitfall.

If the DNS name exists at all, wildcard records typically won’t “fill in” missing record types for that same name.

Example scenario:

If a service looks up a TXT record for app.example.com, the result may be “no TXT record” (often shown as NODATA), and the wildcard TXT might not be used—because app.example.com exists.

Takeaway: If a service requires a TXT record at an exact name (like app.example.com), add that TXT record explicitly.

*.example.com does not cover:

If you want example.com to resolve, create separate records for the root (@ / apex) as needed.

If your app assigns each customer a subdomain:

A wildcard lets you route all tenants to the same load balancer, reverse proxy, or app entry point—then your application routes based on the hostname.

Examples:

Wildcard DNS prevents you from having to create DNS entries for each one.

Teams often use patterns like:

A wildcard record supports this pattern cleanly—just make sure your app and SSL setup also support it (see note below).

Wildcard DNS is not a substitute for mail and identity records.

Create these explicitly when needed:

We don’t cover provider-specific mail setup here. The key rule is: mail/auth records should be explicit, not wildcarded.

Many services validate ownership using very specific names such as:

If verification fails, don’t assume the wildcard will apply—add the exact record name the service provides.

If you’re doing DNS validation for SSL, keep it simple here and refer to our SSL Certificates article for the deeper details.

*.example.com won’t catch a.b.example.com.
If your structure has multiple levels, you may need additional records like:

Below are common wildcard record patterns in HostBible. In most DNS editors, the Name/Host field for a wildcard is either:

If HostBible auto-appends your domain, enter * as the name and HostBible will apply it under your domain.

Use this when your destination is an IPv4 address.

Example

What it does:
Any undefined subdomain (like anything.example.com) resolves to 203.0.113.10.

Use this when your destination supports IPv6.

Example

Tip: You can use both A + AAAA wildcard records together if your service is dual-stack.

Use this when your destination is another hostname (for example, a platform hostname or a traffic manager).

Example

Important CNAME rules

If you need TXT verification and wildcard routing, you often must choose a routing approach that doesn’t require * to be a CNAME—or you must place TXT records on the exact verification names instead of *.

Wildcard TXT can be useful for some internal conventions, but many third‑party verification flows require specific TXT hostnames and won’t rely on wildcard behavior.

Example

Common pitfall:
If a specific subdomain already exists (any record type), wildcard TXT may not apply to TXT lookups for that name. When in doubt, add the TXT record to the exact name the service requests.

Check whether you already have explicit records like:

If they exist, the wildcard won’t be used for those names.
​Fix: Update the explicit record (or remove it if you truly want wildcard behavior).

That’s expected: *.example.com doesn’t match two levels deep.
​Fix: Add a second wildcard at the right level, such as *.b.example.com.

This is usually due to one of these:

Fix checklist:

DNS results can be cached.

Fix checklist:

Wildcard DNS only routes traffic to a destination. Your web server/app must also:

Fix: Configure your application/web server to handle unknown hostnames appropriately (tenant routing, default site, 404 rules, etc.).

You can test from your computer using command-line tools:

Tip: Test both:

No. The root/apex (example.com) needs its own record(s).

Yes, commonly (IPv4 + IPv6).

Usually no, because a CNAME at * typically prevents other record types at the same name. Use explicit verification records instead.

It will make them resolve in DNS, but your app/server must still handle requests for those hostnames.