Wildcard DNS Records: How They Work

What a Wildcard DNS Record Is

A wildcard DNS record uses an asterisk (*) as the leftmost label in a domain name. It acts as a catch-all, matching any query for a subdomain that does not have its own explicit DNS record.

*.example.com.    3600    IN    A    93.184.216.34

This record means: if someone looks up anything.example.com and there is no specific record for anything.example.com, return 93.184.216.34. The asterisk matches any single label in that position.

Without a wildcard, a query for a nonexistent subdomain returns an NXDOMAIN response (name does not exist). With a wildcard, it returns whatever the wildcard record specifies. This is a fundamental difference in how your domain behaves, and it has both useful applications and real risks.

For a broader overview of DNS record types and their purposes, see our DNS record types guide. For general DNS concepts, our complete DNS guide covers the full picture.

How Wildcard Matching Works

Wildcard matching in DNS follows specific rules defined in RFC 4592. The behavior is not always intuitive, so it is worth understanding the details.

Rule 1: Wildcards Only Match When No Explicit Record Exists

If you have both a wildcard and an explicit record for a subdomain, the explicit record wins. The wildcard is only consulted when no other record matches.

*.example.com.      3600    IN    A    93.184.216.34
www.example.com.    3600    IN    A    93.184.216.35
api.example.com.    3600    IN    A    93.184.216.36

In this configuration:

• www.example.com resolves to 93.184.216.35 (explicit record)
• api.example.com resolves to 93.184.216.36 (explicit record)
• shop.example.com resolves to 93.184.216.34 (wildcard match)
• anything-else.example.com resolves to 93.184.216.34 (wildcard match)

This is the intended design. The wildcard catches everything that you have not specifically defined.

Rule 2: Wildcards Match One Label Only

The asterisk matches exactly one DNS label (the part between dots). It does not match multiple levels of subdomains.

*.example.com.    3600    IN    A    93.184.216.34

• foo.example.com matches the wildcard
• bar.example.com matches the wildcard
• foo.bar.example.com does NOT match *.example.com

For foo.bar.example.com to match a wildcard, you would need *.bar.example.com. Each level of subdomain depth requires its own wildcard if you want catch-all behavior at that level.

Rule 3: Existence of Any Record Blocks the Wildcard

This is the part that catches people off guard. If any record exists for a name, the wildcard does not apply for any type at that name. Even if you only have a TXT record for mail.example.com, the wildcard A record will not match mail.example.com.

*.example.com.       3600    IN    A      93.184.216.34
mail.example.com.    3600    IN    TXT    "v=spf1 include:..."

A query for the A record of mail.example.com returns NODATA (the name exists but not for that type), not the wildcard. The existence of the TXT record means mail.example.com is a defined name, and the wildcard is not consulted.

This behavior is correct per the RFC but surprises administrators who expect the wildcard to fill in missing record types for existing names.

Record Types That Support Wildcards

Most common DNS record types can be used with wildcards.

A and AAAA Records

The most common wildcard use case. Route all unmatched subdomains to a specific IP address.

*.example.com.    3600    IN    A       93.184.216.34
*.example.com.    3600    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

CNAME Records

Point all unmatched subdomains to another domain name.

*.example.com.    3600    IN    CNAME    fallback.example.com.

A wildcard CNAME is useful when you want all unknown subdomains to resolve through the same target, such as a CDN or load balancer endpoint. Be aware that a CNAME cannot coexist with other record types at the same name, so a wildcard CNAME means you cannot have wildcard MX, TXT, or other records.

MX Records

Route email for all unmatched subdomains to a mail server.

*.example.com.    3600    IN    MX    10 mail.example.com.

This is occasionally used but can have unintended consequences for email delivery. See the risks section below.

TXT Records

Set TXT records (such as SPF) for all unmatched subdomains.

*.example.com.    3600    IN    TXT    "v=spf1 -all"

A wildcard SPF record that specifies -all is actually a useful security measure. It tells receiving mail servers that no subdomain should be sending email unless it has its own explicit SPF record. This helps prevent subdomain spoofing.

Practical Use Cases

SaaS Multi-Tenant Applications

SaaS platforms that give each customer a subdomain (e.g., customer1.app.example.com, customer2.app.example.com) use wildcard DNS to route all customer subdomains to the same application server or load balancer. The application then determines which customer to serve based on the hostname in the request.

Without a wildcard, the platform would need to create a new DNS record every time a customer signs up. With a wildcard, DNS configuration is static and the application handles routing.

*.app.example.com.    300    IN    CNAME    lb.example.com.

Development and Staging Environments

Teams often use wildcard DNS for development environments where subdomains are created and destroyed frequently. A wildcard pointing to a development server means developers can use any subdomain they want without touching DNS configuration.

*.dev.example.com.    300    IN    A    10.0.1.50

Catch-All Landing Pages

Marketing teams sometimes use wildcards to catch misspelled or guessed subdomains and redirect them to the main site. Instead of returning an error, typo.example.com lands on the homepage.

Simplified CDN Configuration

If all subdomains should be served through the same CDN, a wildcard CNAME to the CDN endpoint eliminates the need for per-subdomain DNS records.

Risks and Downsides

Wildcards are powerful but come with risks that are easy to overlook.

Security Implications

A wildcard record means that every possible subdomain resolves to something. This has security consequences:

Subdomain takeover risk. If your wildcard points to a service you later decommission (a load balancer, a cloud endpoint, a hosting provider), an attacker might claim that endpoint and serve content on any subdomain of your domain.

Phishing enablement. With a wildcard, login-secure-bank.example.com resolves to your server. If an attacker gains control of the server or the wildcard target, they can create convincing phishing URLs using your domain. Following DNS security best practices helps mitigate these risks.

Certificate scope. Wildcard SSL certificates (matching *.example.com) are convenient but represent a broader trust scope. A compromised wildcard certificate private key exposes every subdomain, not just one.

Email Complications

A wildcard MX record means email sent to any nonexistent subdomain will be accepted by your mail server. This can result in:

• Spam directed at random subdomains flooding your mail server
• Backscatter (bounce messages) when your server rejects or bounces messages it accepted via the wildcard
• Complications with email authentication (SPF, DKIM, DMARC) because every subdomain becomes a potential email sender

If you do not intend to receive email at arbitrary subdomains, avoid wildcard MX records and consider setting a wildcard TXT record with v=spf1 -all to explicitly deny email sending from unmatched subdomains.

Unexpected Matches

Once a wildcard is in place, every subdomain resolves. This means typos in subdomain names will not produce errors. They will silently resolve and potentially reach your application. Depending on your application's behavior, this could surface confusing behavior, incorrect content, or error pages that look like your site is broken.

Monitoring Blind Spots

If you use DNS monitoring to verify that specific records resolve correctly, a wildcard can mask problems. A record that was accidentally deleted will still resolve via the wildcard, hiding the deletion. You may need to monitor for the specific expected values rather than just checking whether a name resolves. Learn more about checking DNS records to set up effective monitoring.

When NOT to Use Wildcards

When you have a small, stable set of subdomains. If you only have www, api, and mail, create explicit records. A wildcard adds complexity and risk with no benefit.

When email delivery matters. Wildcards and email are a tricky combination. If email is critical to your business, keep your DNS explicit and avoid wildcard MX or wildcard A records that could interfere with email routing.

When security is a top priority. Explicit DNS records provide a clear inventory of what subdomains exist and where they point. Wildcards make that inventory fuzzy. In security-sensitive environments, the certainty of explicit records outweighs the convenience of wildcards.

When you need precise monitoring. If you monitor DNS records for unauthorized changes, a wildcard makes detection harder because any subdomain query returns a result. Explicit records give you a clear expected state to verify against.

Key Takeaways

• A wildcard DNS record (*) matches any subdomain that does not have its own explicit record.
• Wildcards match one label only. *.example.com matches foo.example.com but not foo.bar.example.com.
• If any record exists for a name (even a different type), the wildcard does not apply for that name.
• Common use cases include SaaS multi-tenant apps, dev environments, and catch-all routing.
• Risks include subdomain takeover, email complications, and monitoring blind spots.
• Use wildcards when the convenience outweighs the risks. For small, stable domains, explicit records are safer and clearer.

References

• Lewi, E., "The Role of Wildcards in the Domain Name System" (RFC 4592), https://datatracker.ietf.org/doc/html/rfc4592
• Cloudflare, "DNS Wildcard Record," https://developers.cloudflare.com/dns/manage-dns-records/reference/wildcard-dns-records/
• ICANN, "SSAC Advisory on Wildcard Use," https://www.icann.org/groups/ssac