Wildcard DNS Records: Uses, Risks, and Best Practices

← Back to Blog

A single DNS record can answer for an unlimited number of subdomains. Add one wildcard entry, and suddenly anything.yourcompany.com, literally-anything.yourcompany.com, and every other name you never explicitly created all resolve to the same place. Wildcard DNS records are powerful, convenient, and genuinely necessary for certain architectures. They're also a frequent source of security problems and confusing misconfigurations.

Understanding when wildcards help, when they hurt, and how they interact with the rest of your DNS is essential for using them safely. This guide covers what wildcard records are, their legitimate uses, the real risks they introduce, and best practices for managing them.

What Is a Wildcard DNS Record?

A wildcard DNS record uses an asterisk (*) as the leftmost label to match any subdomain that doesn't have its own explicit record. It looks like this:

*.yourcompany.com.    3600    IN    A    203.0.113.50

With this record in place, any query for a subdomain of yourcompany.com that doesn't have a specific record returns 203.0.113.50. So foo.yourcompany.com, bar.yourcompany.com, and anything-at-all.yourcompany.com all resolve to that IP, even though you never created records for any of them.

Wildcards work with various record types, not just A records. You can have wildcard CNAME, MX, TXT, and other record types, though A and CNAME are the most common.

How Wildcards Actually Match (The Rules)

Wildcard matching is more nuanced than it first appears, and misunderstanding the rules leads to surprises.

Explicit Records Always Win

A wildcard only answers for names that don't have their own record. If you have both:

*.yourcompany.com.      IN  A  203.0.113.50
api.yourcompany.com.    IN  A  203.0.113.99

Then api.yourcompany.com resolves to 203.0.113.99 (the explicit record), while anything-else.yourcompany.com resolves to 203.0.113.50 (the wildcard). The explicit record takes precedence.

Wildcards Only Match One Level

A wildcard like *.yourcompany.com matches foo.yourcompany.com but does NOT match foo.bar.yourcompany.com (two levels deep). The asterisk represents exactly one label, not multiple. To match deeper levels, you'd need additional wildcards like *.bar.yourcompany.com.

The Subtle Trap: Wildcards and Existing Names

Here's a rule that catches people: a wildcard does not match a name if that name (or something below it) exists in the zone for any record type. If blog.yourcompany.com has an MX record but no A record, a query for the A record of blog.yourcompany.com will NOT fall through to the wildcard, because the name blog.yourcompany.com exists in the zone. This behavior, defined in the DNS specifications, surprises administrators who expect the wildcard to fill in any missing record type.

Legitimate Uses of Wildcard Records

Wildcards exist for good reasons. Here are the scenarios where they're the right tool.

Multi-Tenant SaaS Applications

The classic use case. A SaaS platform gives each customer their own subdomain: customer1.app.com, customer2.app.com, and so on. Creating an explicit DNS record for every customer would be impractical, especially with thousands of customers signing up dynamically. A wildcard (*.app.com) points all of them to the application, which then routes based on the hostname. This is the standard pattern for multi-tenant architectures.

Dynamic or Ephemeral Subdomains

Applications that generate subdomains on the fly, preview environments for pull requests, per-user spaces, dynamically provisioned services, benefit from wildcards so the DNS doesn't need updating every time a new subdomain is created.

Catch-All Behavior

Sometimes you want any subdomain to resolve somewhere sensible rather than returning an error, perhaps to a landing page or a catch-all handler. A wildcard provides this.

Wildcard TLS Certificate Pairing

Wildcard DNS often pairs with wildcard TLS certificates (*.yourcompany.com), allowing any subdomain to serve HTTPS without provisioning individual certificates. The DNS wildcard and certificate wildcard work together to support a flexible subdomain architecture.

The Risks of Wildcard Records

The same flexibility that makes wildcards useful also makes them risky. Here's what to watch for.

They Mask Missing Records and Errors

With a wildcard in place, every subdomain resolves to something, even typos and mistakes. If someone mistypes a subdomain in a configuration, instead of getting a clear "this doesn't exist" error, they get the wildcard's answer, which may route them somewhere unexpected. This masking makes troubleshooting harder because nothing ever appears to be "missing."

They Expand the Attack Surface

A wildcard means every possible subdomain resolves to your infrastructure. If that infrastructure has a vulnerability, or if the wildcard points to a service that can be manipulated, the entire infinite namespace of subdomains becomes a potential vector. This is exactly the dynamic that made the Borrowed Trust campaign so damaging: attackers who took over abandoned cloud DNS zones added a single wildcard record that exposed an unlimited subdomain namespace, each entry inheriting the victim's trusted domain authority.

They Complicate Dangling DNS Detection

Wildcards make it harder to detect dangling DNS and subdomain takeover risks. Normally, you can audit your explicit subdomain records and check each target. But a wildcard resolves everything, so a randomized nonsense hostname will return a result whether or not it's legitimately configured. As we noted in the Borrowed Trust analysis, security researchers specifically test wildcard resolution with random hostnames precisely because an unexpected resolution is a strong signal of a compromised or misconfigured zone.

They Can Enable Email and Phishing Abuse

If a wildcard covers MX or interacts with email authentication, it can create openings for abuse. More commonly, a wildcard A record combined with a permissive application can let attackers serve content under arbitrary subdomains of your trusted domain, useful for phishing that leverages your brand's reputation.

They Interact Unexpectedly with SPF and Subdomains

Wildcards and email authentication don't always combine cleanly. A wildcard doesn't automatically extend your SPF, DKIM, and DMARC protection to every subdomain, which can leave generated subdomains spoofable even though they resolve. Subdomain email security requires explicit DMARC subdomain policies (sp=), not wildcard coverage.

Best Practices for Wildcard Records

Use Explicit Records When You Can

If you know the specific subdomains you need, create explicit records for them rather than relying on a wildcard. Explicit records are auditable, each one represents a deliberate decision, and they don't mask errors. Reserve wildcards for cases where the set of subdomains is genuinely dynamic or unbounded.

Scope Wildcards as Narrowly as Possible

Instead of a broad wildcard at your apex (*.yourcompany.com), scope it to a specific subdomain branch where dynamic naming actually happens (*.apps.yourcompany.com or *.tenants.yourcompany.com). This limits the wildcard's reach to where it's needed and keeps the rest of your namespace explicit and auditable.

Pair Wildcards With Application-Level Validation

If a wildcard routes all subdomains to an application, that application should validate the hostname and reject ones it doesn't recognize, rather than serving content for any arbitrary name. The DNS wildcard resolves the name; the application decides whether to actually honor it. This prevents the wildcard from being abused to serve content under unrecognized subdomains.

Monitor for Unexpected Wildcard Behavior

Because wildcards resolve everything, you need monitoring that can detect when a wildcard appears that shouldn't exist, or when wildcard behavior changes. An unexpected wildcard is a strong indicator of compromise, as the Borrowed Trust campaign demonstrated at scale.

Audit Wildcards During Decommissioning

When you tear down a project or environment that used a wildcard, removing the wildcard record is critical. An orphaned wildcard pointing at decommissioned infrastructure is exactly the kind of dangling configuration attackers look for. Make wildcard cleanup an explicit step in your decommissioning checklist.

Don't Use Wildcards to Avoid DNS Management

Sometimes wildcards are used as a shortcut to avoid the work of managing individual records. That convenience comes at the cost of visibility and security. If you're using a wildcard purely to avoid creating records, reconsider, the explicit records are usually worth the small effort.

How to Check for Wildcards

Testing for a wildcard is simple: query a randomized, nonsense hostname that you've definitely never created. If it resolves, you have a wildcard (or, more concerningly, a compromised zone).

Use the DNS lookup tool at dnsassistant.com/tools to query a random subdomain like random-test-12345.yourcompany.com. If it returns an answer, a wildcard is in play. If you didn't intentionally configure one, that's a red flag worth investigating immediately.

How DNS Assistant Helps

Wildcards require careful monitoring precisely because they resolve everything and can mask both errors and compromise. DNS Assistant supports safe wildcard management:

Record change detection alerts you when a wildcard record is added, modified, or removed, so an unexpected wildcard (a strong compromise signal) doesn't go unnoticed.
Dangling DNS detection across 22+ cloud providers helps identify when records, including wildcards, point to decommissioned infrastructure vulnerable to takeover.
Continuous monitoring catches the moment a wildcard's behavior changes, which is exactly when problems and compromises surface.
Full record visibility across all your domains helps you maintain an accurate picture of where wildcards exist and what they point to.
Multi-channel alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

Given how central wildcard records were to the Borrowed Trust campaign and other subdomain takeover attacks, monitoring wildcard behavior is an important part of DNS security hygiene.

Get Started

Test whether your domains have unexpected wildcards using the DNS lookup tool, or run a Free Domain Risk Report for a comprehensive view of your DNS configuration.

For continuous monitoring of wildcard records and all your DNS configuration with real-time alerting, sign up at dnsassistant.com.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.