A wildcard setup can route otherwise unspecified subdomains to one application, such as a tenant-based website. It requires coordinated DNS, virtual-host handling and application routing; one wildcard DNS record alone does not create a complete multi-tenant service.
IN THIS ARTICLE
What you need before you begin
Confirm the application supports the intended hostname pattern and the hosting service permits wildcard domain configuration. Plan certificate coverage and tenant isolation, and reserve explicit names needed for mail or other services.
01 Prepare wildcard subdomains for an application
- Ask support to confirm the supported wildcard-hostname method for the assigned cPanel service. Use its domain controls only where the wildcard configuration is accepted.
- At the authoritative DNS provider, create the appropriate wildcard record pointing to the intended service. Preserve explicit records that must resolve elsewhere.
- Configure the hosting document root and application to recognise allowed tenant hostnames. Reject unknown or invalid tenants rather than serving arbitrary account data.
- Arrange a certificate covering the required wildcard pattern through a supported validation method. A wildcard certificate does not automatically cover the bare apex or every deeper hostname.
- Test a valid tenant, an invalid tenant and an explicitly configured subdomain, then verify HTTPS and application isolation for each case.
02 Example: check what one wildcard certificate name covers
For a certificate name of *.example.com, the wildcard matches one hostname label. Check the complete names listed in the actual certificate, because it may also contain separate entries.
| Hostname | Covered by this wildcard name alone? |
|---|---|
tenant1.example.com |
Yes, it has one label before example.com. |
example.com |
No. The apex needs its own matching certificate entry. |
shop.tenant1.example.com |
No. This deeper name needs appropriate additional coverage. |
These are certificate-name checks. DNS wildcard matching follows different rules, and a hostname resolving to your server does not prove that its certificate or tenant routing is correct. Test the names your application will actually use before launch.
Confirm the expected result
Known tenants should reach their own intended content, unknown names should fail safely, and unrelated explicit hostnames should keep their separate services.
Troubleshoot unexpected results
If a wildcard domain entry is rejected, do not edit generated Apache configuration from a shared account. Use the provider’s supported route or a suitable platform. If all tenants show one customer’s data, stop launch and fix application host validation and caching before continuing.
Does a wildcard remove the need for tenant setup?
No. DNS can send a hostname to the application, but the application still needs an authorised tenant record, correct storage boundaries and a cache policy that distinguishes tenants.