A wildcard record answers for every subdomain
Updated
What this check looks for
Any name under this domain resolves, including ones you never created. Typos, old links and names invented by other people all point at your server.
Why it matters
A wildcard makes it impossible to tell a real subdomain from a mistake, and it hands anyone a working hostname under your brand to use in a link. It is also frequently deliberate, which is why this is information rather than a fault.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- high
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- DNS
- Module
- Dns records
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Confirm the wildcard is deliberate; if it is not, replace it with explicit records.
An accidental wildcard gives every mistyped or invented name a working address under your domain.
Find the record at your DNS host, where it is listed under the name
*.If it is deliberate — a platform that gives each customer a subdomain — make sure the server it points at refuses or redirects names it does not serve, and that its certificate covers only names you intend.
If it is not, list the subdomains actually in use from your DNS host's query logs, your web server logs and certificate transparency logs, create explicit records for them, then delete the wildcard.
How to confirm it worked
dig +short A no-such-name-7f3a.‹domain› — expect no answer once the wildcard is gone
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
A lookup for ‹probed name›, a name that should not exist, returned ‹addresses›. RFC 1034 §4.3.3 defines wildcard records; they answer for any name at that level with no more specific record. A wildcard is a legitimate design for multi-tenant platforms and a common accident on shared hosting. Check that the address it answers with is a host you control and that it does not serve a certificate or a login page for names you never intended to exist.
A wildcard answers only for names that do not otherwise exist: a name with records of its own, or with names beneath it, is answered from those instead. It also reaches every depth, so *.example.com answers for a.b.example.com unless b.example.com exists. RFC 4592 settles the edge cases.
The effects go beyond the web server. Every invented hostname gets an address, so a catch-all virtual host or CDN rule can serve your site — and a search engine can index it — under names you never chose; redirect any unknown hostname to your canonical address. A wildcard MX or TXT record gives every invented name mail routing or an SPF policy as well. And a wildcard CNAME to a shared hosting or cloud platform hands every name to that platform: if the platform lets its customers claim any hostname, someone else may be able to serve content under yours.
To see it yourself, ask for a name nobody created, then for the wildcard itself — a query for the literal * label returns the record:
dig +short A no-such-name-7f3a.‹domain›dig +short A '*.‹domain›'
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.