Domains
Point a domain at a website
Send visitors to a sending domain's apex and www to your own URL — a redirect server, a landing page, a signup form — without touching the mail records that keep it delivering.
What this setting is
Somewhere on your domain page there is a Website section with one field: where visitors to this domain should go. You put a URL in, press Save, and within about a minute the domain sends everyone who visits it to that address.
It applies to the domain itself and to www. The path and the query string are kept, so a link to /pricing?utm_source=campaign arrives at your target as /pricing?utm_source=campaign rather than at its home page. A certificate for the domain is issued automatically, so https:// works from the first request.
That combination is what a bare A record would not give you: an A record has to hold an IP address, so it breaks the moment your redirect server moves, and it needs a certificate of its own.
Why it is not an A-record editor
On a domain that sends cold email, the apex already carries MX, SPF, DKIM and DMARC. Those records are what make mail from the domain authenticate, and none of them fails loudly when they are wrong. A hand-edited SPF record that is one character off looks completely normal on the page and makes every message fail authentication at the receiver.
So the setting is a URL and nothing else. It is physically incapable of touching a mail record, and Rewrite records will not undo it.
Setting it
- Open the domain.
- Find Website and type the address, starting with
https://. - Save.
The status under the field tells you what happened:
| Status | Meaning |
|---|---|
| *(nothing)* | No redirect set. The domain serves its landing page while it ages. |
| Checking | Saved, and we are confirming it answers. Takes about a minute. |
| Live | A request to the domain comes back with your target. |
| Not answering yet | Saved, but the domain does not return your target yet. Usually propagation — it clears on its own. |
Clear removes it and the domain goes back to its landing page. The mail records and the domain's DNS do not change either way, and neither does warming or sending.
Requirements and limits
- https only. We serve the redirect over TLS, and an
http://target would send visitors to a plaintext page that may not exist. - The target cannot be the domain itself. That is a loop, and the page will not load. We refuse it rather than saving something broken.
- One target per domain. Not per path, and not several at once.
- Not on every domain. It works on domains whose nameservers point at us — everything you register here, plus a BYO domain you delegate. See below for the others.
- We will not overwrite an existing website. If the apex already answers with something else, the save fails and names the record in the way. Taking it over would take that site down, so that one is your call to make.
If the field is read-only
You will see this on a domain kept at your own DNS host, and the reason is different in each case.
You maintain the records. We only read this domain's DNS, never write it, so there is nothing of ours in the path. At your DNS host, add an A record for the domain itself and one for www, each pointing at your redirect server's address. That is the one place an A record is the right answer.
Your Cloudflare, our token. The token we hold is scoped to DNS — it writes records, but it cannot bind the Worker that serves a redirect. Add the same two records in Cloudflare, or move the domain to our nameservers.
In both cases, leave the mail records exactly as they are. MX and the inbound record are what replies and bounces arrive on, and repointing them breaks delivery before it breaks anything else.
Need More Help?
Bring your own domain · Domains and mailboxes · SPF, DKIM, DMARC and MX