Domain & DNS Setup
Domain and DNS Setup: Connect Your Website Without Losing Track of Your Email
A domain can be registered in one account, use DNS in another, point to a server elsewhere, and receive email through Zoho. That is a normal arrangement. Problems arise when nobody knows which account is responsible for a particular change.
The goal of domain setup is to establish a durable business address, connect the required services, and retain the access needed to change them later. This guide explains the domain layer of your website infrastructure.
Choose a domain you can use consistently
Prefer a name the business can say, spell, and use in an email address without repeated explanation. Check likely spelling mistakes and whether the name creates confusion with another organization. Domain availability alone does not establish the right to use a brand name.
Choose the extension for the business identity and audience. Do not buy a name full of descriptive words on the assumption that the name itself will deliver search rankings. The website still needs useful content and a clear offer.
Before paying, inspect the renewal price, account protections, support route, and transfer conditions. An introductory price is only one part of the decision. The owner should be able to maintain the registration without relying on the developer’s personal billing or recovery details.
Record the final domain exactly. Similar-looking domains, punctuation, and spelling errors can affect mail and account creation long after the purchase.
Keep the three control points separate
The registrar maintains the registration and nameserver delegation. The authoritative DNS provider publishes the zone’s records. The destination provider runs the website, mailbox, or other connected service.
If Cloudflare is authoritative, edit the active records there. An old DNS editor at the registrar may still exist, but changes in that inactive zone will not control public resolution.
A hosting provider’s instruction to “point the domain” usually means changing the relevant record or delegation. Determine which change is actually required. Moving a website does not necessarily require transferring its registration or replacing every nameserver.
Document the registrar and authoritative DNS provider in the ownership inventory, along with the person authorized to make changes.
Understand the records you actually need
| Record | Its job | What to check |
|---|---|---|
| A | Maps a hostname to an IPv4 address | The address belongs to the intended destination |
| AAAA | Maps a hostname to an IPv6 address | IPv6 reaches the correct service and is actually configured |
| CNAME | Makes a hostname an alias of another hostname | The target is correct and the use is supported at that name |
| MX | Identifies the servers accepting mail for the domain | The values and priorities match the mail provider |
| TXT | Carries values used by services, including verification and mail authentication | Each record is entered at the requested name with the correct value |
| NS | Delegates DNS responsibility | The registrar lists the nameservers assigned to the active zone |
A record that points to a server does not tell that server which website to display. The server must also be configured to recognize the requested hostname. Likewise, a CNAME is not an HTTP redirect: it does not by itself change the address shown in the browser.
Treat unused AAAA records carefully. A working IPv4 test can hide an IPv6 destination that serves an old site or cannot establish HTTPS.
For email, use the actual values issued for the organization’s Zoho account and region. Do not copy a generic record set from an unrelated account. The business email guide covers those values and their verification.
Inventory the zone before changing anything
Save or export the current records. Check the root domain, www, mail-related entries, verification records, and any subdomains used by other systems. Ask what depends on unfamiliar entries before removing them.
Automated scans can help discover records, but they should not be treated as proof that every required entry has been imported. Compare the destination zone with the current authoritative source and the known service inventory.
Record the previous value and intended replacement for each change. Keep the old hosting or mail service available for the transition where the project requires it. Deleting the previous environment immediately can turn an easily reversible mistake into lost service or data.
Change delegation in a controlled order
For a move to Cloudflare DNS, use the following sequence:
- Confirm client-controlled access to the registrar and destination Cloudflare account.
- Create the zone and review all required records before changing delegation.
- Review existing DNSSEC. Follow the supported migration procedure so the parent DS record does not refer to obsolete signing keys.
- Enter the exact assigned nameservers at the registrar.
- Check the active delegation and record answers, then test web and mail services.
- Complete the destination DNSSEC setup where used and verify its operation.
Cloudflare documents the ordinary nameserver transition and options for DNSSEC-aware migration. Do not leave a mismatched DS record in place: a signed-delegation problem can prevent validation even when the visible records look correct. Cloudflare nameserver setup
The Cloudflare guide continues with proxy and HTTPS configuration. DNS delegation alone does not establish that the proxy is active or the origin is ready.
Plan TTLs without promising instant propagation
TTL tells caches how long a DNS answer may be reused. If an existing record has a long TTL, changing it now does not recall copies already held by resolvers.
For a planned record change, lowering its TTL ahead of time can help shorten later reuse, provided enough time passes for the previous longer-lived answers to expire. It does not make a nameserver transition instantaneous or guarantee that every device refreshes simultaneously.
Avoid changing records repeatedly while waiting. Instead, compare the authoritative answer with the answers from the resolvers you are testing. That helps separate an unsaved configuration from a cached previous response.
If Cloudflare proxies a hostname, public DNS may return Cloudflare addresses rather than the origin IP. That behavior is expected for the proxied route; it is not evidence that the origin address was ignored.
Verify with specific questions
Use your DNS tools to ask which nameservers are authoritative and what answers are published. These are read-only examples for a domain you own or administer; replace example.com with the actual domain:
dig NS example.com
dig A example.com
dig AAAA example.com
dig CNAME www.example.com
dig MX example.com
dig TXT example.com
To inspect a particular authoritative server, use dig @assigned-nameserver example.com A, substituting the real assigned nameserver. Different responses between the authoritative server and a recursive resolver may indicate cached information. Empty output for one record type is not necessarily an error if that record is not intended to exist.
Next, open the intended web addresses over HTTPS. Confirm that the correct site appears and that preferred-hostname redirects work. Send an external test message to the business mailbox and reply from it.
The required evidence is functional: correct delegation, correct answers, the intended site, and working mail. A green indicator in one provider’s dashboard is useful but does not establish all four.
Diagnose the layer before changing it
No address resolves: inspect the spelling, delegation, record existence, and DNSSEC state. A WordPress plugin will not repair a domain that cannot resolve.
The wrong site appears: inspect both A and AAAA, the active DNS provider, and the server’s hostname configuration. Also check whether you are seeing an old cached response at a later layer.
The site works but email fails: inspect MX and the mailbox organization first. Do not overwrite web records in an attempt to repair mail delivery.
The address resolves but HTTPS fails: the request has progressed beyond basic DNS resolution. Inspect the certificate, hostname, proxy mode, and origin configuration through the server and Cloudflare guides.
Only some visitors see the change: compare their resolution path, IPv4/IPv6 behavior, and the responses returned by the web delivery layers. “Propagation” should not become a permanent explanation for an uninvestigated configuration error.
Preserve the domain as a business asset
Keep renewal notices, billing, and account recovery under the owner’s control. Record when responsibility changes. A transferred development project should not leave the domain renewing on an inaccessible card or recovery phone.
Review the zone when services are retired, but remove records only after checking their purpose. Stale references can create confusion; indiscriminate cleanup can break working integrations.
Include the domain and DNS records in the handover documentation. Keep the credential store separate from the general zone inventory.
Frequently asked questions
Must the registrar, DNS provider, and host be the same company?
No. They perform separate roles and can work together. The important requirement is correct delegation and records, with clear ownership of the relevant accounts.
Does changing nameservers move the website or email data?
No. It changes where DNS is answered. The destination still needs the correct records, and any actual file, database, or mailbox migration must be handled separately.
Should I use www or the root domain?
Choose a preferred public hostname and configure the alternatives consistently. Both can be viable. Check DNS, HTTPS, redirects, WordPress settings, and canonical URLs together so the choice is implemented throughout the site.
Can I remove every record I do not recognize?
No. Verification, mail, and integration records may not be obvious from their names. Identify the dependency and owner before deleting them.
Why do changes at my registrar have no effect?
The registrar may no longer be the authoritative DNS provider. Check the delegated nameservers and edit the active zone. Registration control and DNS editing are not always in the same account.
Does a domain purchase include business email?
Not necessarily. Confirm the purchased product and set up the intended mailbox service. In the arrangement described here, Zoho Mail is configured separately and connected through DNS.
Connect your domain correctly
If you want me to handle the setup, provide the domain name, the services it should support, and any known existing providers. I can organize the registration and DNS work within your website project while keeping control with you.