Wildcard Subdomains: Configuration, Use Cases, and Management
Wildcard subdomains — created with a DNS record using an asterisk as the subdomain prefix (*.example.com) — route any subdomain request that does not have a specific matching record to a designated server. This enables powerful patterns like per-customer URLs in SaaS applications without creating individual DNS records for each customer.
Creating Wildcard DNS Records
In your DNS management interface, create an A record with an asterisk as the Name/Host: * 3600 IN A 192.0.2.1. This catches any subdomain of example.com that does not have a more specific record. Specific subdomain records (like www, blog) take precedence over the wildcard — DNS resolvers always prefer the most specific matching record.
Note that wildcards only match one level. *.example.com matches anything.example.com but not anything.anything.example.com. For multi-level wildcards, each level needs its own wildcard record.
Web Server Configuration for Wildcards
Your web server needs to accept requests for any subdomain and route them to the correct application. In Nginx: server {{ server_name ~^(?P<tenant>.+)\.example\.com$; ... }}. The regex captures the subdomain into a variable that the application can use to identify the tenant. In Apache: ServerAlias *.example.com in your VirtualHost catches all subdomains.
Your application then reads the Host header from the incoming request, extracts the subdomain, and uses it to look up the appropriate tenant's data and configuration. This pattern is used by platforms like Shopify (stores get shop.myshopify.com), WordPress.com (blogs get name.wordpress.com), and many B2B SaaS products.
Wildcard SSL Certificates
Standard SSL certificates cover a specific list of domain names. Wildcard certificates cover any subdomain of a domain: a certificate for *.example.com covers blog.example.com, app.example.com, etc. They do not cover the root domain (example.com) itself — a Subject Alternative Name (SAN) entry is needed for that — and do not cover multiple levels (*.*.example.com is not valid in standard wildcard certificates).
Let's Encrypt issues wildcard certificates but requires DNS-01 challenge validation (proving you control DNS for the domain) rather than the simpler HTTP-01 challenge. Tools like Certbot with the dns-cloudflare or dns-route53 plugins automate wildcard certificate renewal via DNS challenges.
See our articles on subdomain security and subdomains for microservices for advanced architectural topics.