Wildcard DNS record
Whether an invented name under the domain resolves. A deliberate arrangement on plenty of sites and a surprise on others, so it is reported as a fact.
A wildcard DNS record (*.example.com) answers for every name under the domain that does not have a record of its own. With one in place, anything.example.com resolves — including names nobody ever created.
How SiteScan checks
The scan asks for the A record of an invented name, sitescan-wildcard-probe.example.com, which no zone would carry on purpose. If it resolves, a wildcard is in place and the row reads "Present"; otherwise "Missing". Either way the row is neutral: SiteScan reports it as a fact, not a finding.
Why it matters
Wildcards are deliberate on many setups — multi-tenant SaaS with a subdomain per customer, hosting platforms, sites that catch typos. Elsewhere they are a leftover that surprises the owner:
- Every invented subdomain serves your site, or an error page, which can look like duplicate content to search engines and confuse visitors.
- Mail and certificate tooling may behave unexpectedly for names you never meant to exist.
- It hides mistakes: a typo in a link to a subdomain still resolves instead of failing loudly.
With a wildcard in place SiteScan also skips the CNAME check, since every name resolves there anyway. If you do not need one, delete the * record and create records for the subdomains you use. If you do, make sure the web server answers unknown hosts with a 404 or a redirect rather than with a copy of the site — see www variant.
See this check on your own site
Run a free scan: the report shows this row for your domain along with the other checks of the site audit.
More in “DNS & email”
What SiteScan checks
TLS certificate
- TLS certificate expiry
- Outdated TLS versions (TLS 1.0/1.1)
- TLS certificate chain
- TLS certificate issuer
- Certificate signature algorithm
Domain registration
- Domain registration expiry
- Registered domain name
- Domain registrar
- Domain registration date
- Domain last updated date
- Domain status codes (EPP)
- Domain transfer lock
- Registrar abuse contact
- RDAP and WHOIS data source
Indexing
- robots.txt file
- CSS and JS blocked in robots.txt
- XML sitemap
- Sitemap index file
- Off-domain URLs in the sitemap
- Sitemap lastmod dates
- Broken URLs in the sitemap
- RSS and Atom feed
Addresses & redirects
Security headers
- HTTP security headers and grade
- Strict-Transport-Security (HSTS) header
- Content-Security-Policy (CSP) header
- X-Content-Type-Options: nosniff
- X-Frame-Options and clickjacking
- Referrer-Policy header
- Permissions-Policy header
- HSTS preload list
- CORS and cross-origin reads
- HTTP TRACE method
Delivery & reputation
- Cache-Control header for HTML
- ETag and Last-Modified revalidation
- HTTP/3 and QUIC support
- Server version disclosure in headers
- DNS blocklist (DNSBL) check
Internal links
Exposure
- Exposed sensitive files (.env, .git, backups)
- Directory listing enabled
- Public JavaScript source maps
- Exposed WordPress endpoints
Well-known files
- security.txt file
- llms.txt for AI assistants
- llms-full.txt file
- ads.txt authorized sellers file
- humans.txt file
- Well-known change-password URL
DNS & email
- MX records (mail servers)
- SPF record
- DMARC record and policy
- DNSSEC signing
- CAA record
- Nameserver redundancy
- IPv6 support (AAAA record)
- MTA-STS policy
- TLS-RPT reporting record
- BIMI record (brand logo in email)
- Wildcard DNS record
- Dangling CNAME and subdomain takeover
Privacy & consent
- Analytics and tracking scripts
- Cookie consent banner
- Privacy policy link
- Terms of service link
- Imprint (Impressum)
- Accessibility statement
Core Web Vitals
- Lighthouse performance score
- Largest Contentful Paint (LCP)
- Cumulative Layout Shift (CLS)
- Interaction to Next Paint (INP)
- CrUX field data vs lab data