Most DNS records are specific: they define what happens when someone visits a particular subdomain like www.example.ca or mail.example.ca. A wildcard DNS record does something different - it defines a catch-all rule that applies to any subdomain not otherwise explicitly defined. Understanding when to use one (and when not to) is useful knowledge for any website owner who manages their own DNS.
What a Wildcard DNS Record Is
A wildcard record uses an asterisk as the subdomain label: *.example.ca. This record matches any subdomain of example.ca that does not have its own specific DNS record. If someone visits anything.example.ca, or random.example.ca, or test.example.ca - and none of those subdomains have their own A or CNAME record - the wildcard record handles the request.
Wildcard records can be created for any record type: A records (pointing to an IP address), CNAME records (pointing to another hostname), and MX records (for email routing).
How They Work
DNS resolution follows a specificity rule: more specific records always take precedence over wildcard records. If you have a wildcard A record pointing *.example.ca to your server's IP address, but you also have a specific A record pointing shop.example.ca to a different IP address, visitors to shop.example.ca will be sent to the specific record - not the wildcard. The wildcard only applies to subdomains with no explicit record.
This specificity precedence is important to understand before creating a wildcard, because it means you can safely add specific subdomain records alongside a wildcard without the wildcard interfering.
Common Use Cases
Wildcard SSL certificates - A wildcard SSL certificate (*.example.ca) secures any subdomain of your domain with a single certificate. If you operate multiple subdomains and want all of them served over HTTPS without managing a separate certificate for each, a wildcard SSL combined with a wildcard DNS record is the standard approach. Let's Encrypt issues wildcard certificates through DNS-01 challenge validation.
SaaS platforms with per-customer subdomains - If you are building a platform where each customer gets their own subdomain (customer1.yourapp.ca, customer2.yourapp.ca), a wildcard DNS record points all of those customer subdomains to your application server, which then routes the request based on the hostname. This is the standard architecture for multi-tenant web applications.
Catch-all email routing - A wildcard MX record combined with server-side catch-all email routing allows any email address at your domain to be received, regardless of the specific address used. This is useful for testing and for ensuring that emails sent to slightly incorrect addresses are not lost.
How to Add a Wildcard Record in cPanel
In cPanel, navigate to Domains > Zone Editor and find your domain. Click Manage. To add a wildcard A record, click Add Record and enter an asterisk (*) as the Name field, set the Type to A, and enter the destination IP address. Save the record.
Propagation time for DNS changes is typically between a few minutes and 48 hours, though most resolvers pick up changes within an hour.
Important Caveats
Wildcards expose unintended subdomains - If you create a wildcard A record pointing to your web server, any subdomain someone types will resolve to your server. This is usually harmless - your web server will return a 404 or redirect to your main site - but it means that internal or development subdomains you had assumed were inaccessible are now reachable by anyone.
Wildcards do not apply to sub-subdomains - *.example.ca does not match sub.sub.example.ca. Wildcards only catch one label deep. If you need to cover deeper nesting, you need additional wildcard records.
Audit before enabling - Before adding a wildcard record, review your existing subdomain records and ensure you understand what traffic the wildcard will capture. Do not add a wildcard to a production domain without understanding what it will affect.
Used deliberately, wildcard DNS records are a clean and efficient solution for legitimate multi-subdomain scenarios. Used carelessly, they can expose services you did not intend to make public.
