Root domains

A bare domain — example.com, with no www or other label in front — cannot be pointed at an edge service the way a subdomain can. This is a rule of the DNS protocol, not a limit of ours, and every service that sits in front of your site through DNS runs into it. Covering the root takes one redirect, set up at your DNS provider.

Why a root domain is different

Pointing a hostname at us means giving it a CNAME record. DNS forbids a CNAME at the root of a zone: the root has to carry its own NS and SOA records, and a name that has a CNAME may carry nothing else. Your DNS provider will reject it with an error like "CNAME must not be used with any other type on the same name".

Some providers offer ALIAS or ANAME records, which look like a root CNAME but are flattened into plain address records before anyone sees them. That flattening is exactly the problem: the addresses behind an edge service are shared by a great many sites, so once the chain is flattened there is no longer anything marking the traffic as yours. The hostname cannot be activated.

Why we turn root domains away at signup. Rather than let you add one and discover this after changing DNS, we decline it up front and point you here. It is a deliberate choice to fail at the form instead of in production.

The fix: protect `www`, redirect the root to it

Pick www.example.com (or any subdomain) as the address your site actually serves from, and redirect the root to it. Every visitor — whether they type the root or the www — ends up on the protected address.

visitor types example.com → 301 → www.example.com → protected visitor types www.example.com → protected

The redirect carries no page content, no scripts and no form data: the real page only ever loads on the protected hostname. Nothing is left exposed.

Setting up the redirect

Most DNS providers can do this for you without touching your web server. Look for a feature named Redirects, Forwarding, URL redirect or Redirect rules in your DNS control panel, and create:

Field	Value
From	`example.com`
To	`https://www.example.com`
Type	Permanent (301)
Forward path	Yes — keep the rest of the URL

If your provider has no such feature, the same redirect can be done in your web server. On nginx it is a small block that answers for the root and sends everything to www:

server { listen 443 ssl; server_name example.com; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; return 301 https://www.example.com$request_uri; }

If you take the nginx route, remove example.com from the server_name of the block that serves your site, leaving only www.example.com. Otherwise two blocks claim the same name and nginx warns about a conflict, ignoring one of them.

Use a permanent redirect

Use 301, not 302. A permanent redirect tells search engines the www address is canonical and consolidates your ranking there instead of splitting it across two addresses. Serving identical content on both without a redirect is a duplicate-content problem that exists whether or not you use us.

Your email is not affected

Mail delivery uses MX records, which point at your mail provider and have nothing to do with the web address. Adding a redirect or changing which hostname serves your site does not touch them. Your SPF, DKIM and DMARC records are likewise untouched.

Native root support

Protecting a root domain directly — with no redirect — is possible on dedicated infrastructure, which we offer as a separate arrangement rather than on the standard plans. If your root has to stay the canonical address and a redirect is not acceptable, get in touch.

Next: Content Security Policy →