Pointing a Domain at Vercel/Cloudflare

Get the target values from the host

After adding your custom domain to a deployment on Vercel or Cloudflare, the hosting dashboard tells you which DNS records it expects. Use those exact target values: they can vary by provider and account. Do not copy a random example from a tutorial when the host has supplied a current value.

Find the DNS dashboard for the provider serving your domain’s nameservers. If you registered the domain at one company but delegated nameservers elsewhere, add records at the delegated DNS provider. Otherwise the host may keep reporting that the records are missing.

Point the root and www names

The root, or apex, is usually written as @ in DNS dashboards. For this practical task, add the requested A record at @ with a valid IPv4 address supplied by the host or simulator. Add a CNAME for www pointing to the deployment hostname the host specifies. A CNAME points one name at another hostname; it is not an IPv4 address.

A      @      [host-provided IPv4]
CNAME  www    [host-provided hostname]

The bracketed values are placeholders, not literal record targets. Follow the exact values and field formats shown by your provider. Remove or adjust conflicting records only when you understand what they serve.

Verify ownership with a TXT record

A host may ask you to prove control by adding a TXT record. Enter the requested host/name and value exactly; in this module’s simulator, the value must begin with sf-verify=. TXT verification is separate from directing web traffic, so keep it even after the website begins loading if the host still needs it.

Allow time and check status

Save each record, then return to the deployment dashboard and use its verification check. DNS changes can appear in minutes but may take hours to propagate, depending on caching and provider settings. A delay does not necessarily mean you entered a wrong record. Check type, name, target, duplicate conflicts and the authoritative provider before changing values.

Once verified, test both the root name and www in a browser. This process is the practical point: the registrar holds your registration, DNS publishes directions, and the deployment host confirms it can serve the domain.

Walk a simulator record through its fields

Treat this as fictional practice data, never values to copy into a real domain:

The A value is an example IPv4 address; the CNAME value is a hostname without https:// or a path; the TXT is a verification string. Names like www are often relative to the zone, so the dashboard may expand them automatically. Check whether it expects a short label or the full hostname to avoid creating www.example.com.example.com.

In the simulator, create the three intended rows, inspect type/name/value and run its check. Deliberately try a root CNAME and understand the simulator's rejection, then restore the root A. Real DNS providers can have apex alias/flattening features, but that does not change this exercise's specific A-at-root contract.

Verify DNS and hosting separately

For a real domain you own, copy actual requested targets from the host, not the table above. Use the DNS lesson's nslookup/dig read-only commands to check A, CNAME and TXT. Then inspect the host's verification status and test HTTPS for both apex and www. DNS resolving correctly does not prove the host knows how to serve that hostname or has finished issuing its certificate.

If apex works but www fails, inspect the www record and whether www was added to the host. A CNAME is not an HTTP redirect; choosing a preferred address requires the host's redirect setting. Never delete mail MX/TXT records to fix a website. If a lookup shows an old value, investigate authority and caching before repeatedly editing the target.

Before the simulator assessment, explain each field, show the three records and distinguish ownership verification from directing web traffic. Real-domain deployment is optional and should be done only on names you control.