A wildcard DNS record can answer for otherwise unmatched names, but it does not automatically create websites, tenant accounts or certificate coverage for every resulting hostname.
IN THIS ARTICLE
01 What you need before you begin
List the intended hostname pattern and existing explicit records. Confirm the destination application accepts those hostnames and decide whether the record should use Cloudflare’s web proxy.
02 Use a wildcard DNS record without overriding explicit hostnames
- Open DNS > Records and add the supported record type with a wildcard label, such as
*. - Enter the intended origin address or target hostname and choose the appropriate proxy setting.
- Keep explicit records for names that need different destinations, especially mail, administration and verification services.
- Test an unmatched name and an existing explicit name separately. Confirm the explicit record continues to receive its intended answer.
- Verify application routing and TLS for representative names, including any deeper hostname levels your design uses. Remove the wildcard if accepting arbitrary names serves no useful purpose.
03 Confirm the expected result
Unmatched names should follow the intended wildcard behaviour, while explicit DNS nodes retain their own resolution. Test the actual pattern rather than assuming every depth and record type behaves identically.
04 Troubleshoot unexpected results
A wildcard cannot repair a missing application virtual host or an uncovered TLS name. An explicit DNS name or delegation can also change wildcard matching. Use authoritative queries to distinguish DNS matching from web-server routing.
05 Example: use a wildcard without taking over named services
Suppose your application needs many customer subdomains while mail.example.com must continue pointing to a separate mail service. Record the explicit names and existing records before introducing a wildcard.
Test an intended wildcard match and the named exceptions independently. DNS wildcard behaviour depends on the existing DNS names and records; it is not equivalent to a text-replacement rule applied to every hostname.
Will a wildcard DNS record make every site work?
No. The web server or application must also recognise the requested hostname, and HTTPS requires appropriate certificate coverage. A hostname that resolves can still show the wrong site, an application rejection or a certificate warning.
Keep the wildcard's destination and purpose documented. Review any user-provided subdomain input in your application so that resolving many names does not become uncontrolled account access. Ask us for help with the exact hostname and desired route if you are unsure whether the problem is DNS, website mapping or SSL. Do not replace explicit mail or verification records to make a broad wildcard appear to work.
Will a wildcard certificate cover every nested name?
No. Certificate wildcard coverage has its own rules and is separate from DNS wildcard matching. Verify the exact hostname depth against the certificate’s names.
.png)
 (1).jpg)
 (1) (1).png)
 (1).png)
.jpg)
.jpg)
 (1).jpg)
.jpg)
