A domain name is one of the first things a business acquires when establishing an online presence. It appears in the website address, follows the @ symbol in business email addresses, and often becomes closely connected with the company’s identity.
However, a domain name is not the website itself. It is not the hosting server, the WordPress installation, the email service, or the SSL certificate. These are separate components that must be connected correctly for a website and its associated services to work.
Understanding these differences becomes particularly important when moving a WordPress website, changing hosting providers, transferring a domain, setting up business email, or modifying DNS records. A small mistake at the domain or DNS level can make a functioning website appear offline or interrupt email without anything being wrong with the WordPress installation itself.
This guide explains what a domain name is, how the Domain Name System works, and how domains connect with WordPress hosting, email, SSL certificates, and other online services.
What Is a Domain Name?
A domain name is a human-readable address used to identify a location or service on the internet.
For example:
example.com
Computers ultimately connect to servers using numerical Internet Protocol addresses. A domain name allows people to reach a website using a memorable name instead of entering an IP address.
The Domain Name System, usually shortened to DNS, connects the readable domain name with the technical destination needed to deliver the website, email, or another service. Cloudflare describes a domain as an easy-to-remember address that maps through DNS to the relevant internet resource.
A domain can also contain several parts.
In:
blog.example.com
.comis the top-level domain or TLD.exampleis the registered domain name.blogis a subdomain.
The root or apex domain is generally written as:
example.com
The familiar www in www.example.com is technically also a subdomain. A website can use either the root domain, the www version, or both, provided one is selected as the primary address and the other redirects consistently.
A Domain Name Is Not the Same as a Website
The terms domain, website and hosting are sometimes used interchangeably, but they represent different parts of the system.
The domain name is the address
The domain is the name people enter into their browser, such as:
hostingitrust.com
It can also be used in an email address:
[email protected]
The website is the content and application
The website consists of pages, images, text, code, database content, themes, plugins and other files. In a WordPress website, much of the visible content is stored in the WordPress database, while themes, plugins and uploaded media are stored as files.
Hosting is where the website operates
Web hosting provides the server environment where those files and databases are stored and processed. When somebody visits the domain, DNS directs the request toward the hosting environment, where the server loads WordPress and returns the requested page.
A simple analogy is:
- The domain name is the street address.
- The hosting server is the land or building.
- The website is the business operating inside it.
- DNS is the system that provides directions to the correct location.
The comparison is not technically perfect, but it highlights why registering a domain does not automatically create a website and why purchasing hosting does not necessarily include ownership or control of the domain.
Registrants, Registrars and Registries
Domain registration involves several organizations and roles.
The registrant
The registrant is the individual, company or organization in whose name the domain is registered. ICANN defines the registrant as the person or entity that registers the domain and enters into an agreement with the registrar.
For a business domain, the business should ideally be listed as the registrant, with an authorized person controlling the account and recovery details.
A web designer, employee or IT supplier may help manage the domain, but the business should retain administrative control. Losing access to the registrar account can create serious problems with renewals, transfers, DNS changes and ownership verification.
The registrar
The registrar is the company through which the domain is registered and managed. Registrars process domain registrations, collect the registrant’s information, communicate with the appropriate registry and provide an interface for managing renewals, contacts, nameservers and transfer settings.
The registrar may also sell hosting, email and security services, but these are separate from its role as the domain registrar.
The registry
The registry operator maintains the central database for a particular top-level domain.
For example, different registry operators are responsible for extensions such as .com, .org, .net, or country-code domains. The registry accepts registration and update requests through authorized registrars and maintains the authoritative record of domains registered under that extension.
The relationship can therefore be summarized as:
Registrant → Registrar → Registry
The registrant requests and maintains the domain through the registrar, while the registrar communicates the relevant information to the registry.
Domain Registration Does Not Mean Permanent Ownership
People often speak of “buying” a domain, but domain registration is closer to obtaining the right to use and renew a name under the registrar’s terms.
A domain is registered for a defined period. It must be renewed to remain active. When a registration expires, the domain may enter a grace or recovery period before eventually becoming available for somebody else to register, depending on the domain extension and applicable rules.
This is why domain management should include:
- Auto-renewal where appropriate
- A valid payment method
- Accurate account contact information
- Access to the registrant email address
- More than one trusted administrator when necessary
- Monitoring of renewal notices
- Two-factor authentication for the registrar account
A website can be perfectly healthy on its hosting server and still disappear from public access if the domain expires.
What Is DNS?
DNS stands for Domain Name System. It is the distributed system that tells browsers, mail servers and other applications where services associated with a domain can be found.
When somebody enters a domain into a browser, the browser does not inherently know which server contains the website. A DNS lookup is performed, eventually reaching the authoritative nameservers for that domain. Those nameservers return the relevant DNS records, allowing the browser to connect to the correct destination.
DNS does not contain the website itself. It contains instructions about where different services should go.
A domain can therefore direct:
- Website traffic to one hosting provider
- Email to another provider
- A subdomain to a third-party application
- Verification requests to Google, Microsoft, a payment platform, or another service
- Specific services to different servers
This flexibility is powerful, but it also explains why DNS changes must be handled carefully.
What Are Nameservers?
Nameservers identify the DNS provider responsible for answering authoritative questions about the domain.
They often look like this:
ns1.example-dns.com
ns2.example-dns.com
The nameservers are usually set inside the domain registrar’s control panel. Once assigned, the actual DNS records are generally managed through the corresponding DNS provider.
For example, a domain may be registered with one company while using Cloudflare nameservers. In that arrangement:
- The registrar manages registration and renewal.
- Cloudflare manages the authoritative DNS records.
- A separate hosting provider may operate the WordPress website.
- Another provider may handle business email.
These services do not need to be supplied by the same company.
Changing nameservers is a major DNS change because it moves authority for the entire DNS zone. Before changing them, all required records should be recreated or imported at the new DNS provider. Cloudflare specifically advises reviewing the imported records and manually adding anything missing before completing a nameserver change.
The Most Common DNS Record Types
A DNS zone can contain many types of records. The following five are among the most relevant for ordinary business websites.
1. A Record
An A record connects a hostname to an IPv4 address.
For example:
example.com → 192.0.2.25
This tells browsers and other clients that requests for example.com should be sent to the server using that IPv4 address.
A records are commonly used for root domains and subdomains when the destination has a fixed IPv4 address.
2. AAAA Record
An AAAA record performs a similar function but points to an IPv6 address instead of an IPv4 address.
A website can have both A and AAAA records so that it is reachable over both IP versions. However, an incorrect AAAA record can cause intermittent loading problems because some visitors may attempt to connect through IPv6 while others use IPv4.
A and AAAA records both map hostnames to IP addresses.
3. CNAME Record
A CNAME record makes one hostname an alias of another hostname.
For example:
www.example.com → example.com
or:
shop.example.com → shops.platform-provider.com
Instead of pointing directly to an IP address, the CNAME points to another hostname, which is then resolved to its final destination.
CNAME records are frequently used for:
- The
wwwversion of a domain - Hosted applications
- Content delivery services
- Verification records
- Email-related services
- Third-party platforms
Standard DNS rules generally do not allow a CNAME to coexist with other record types at the same hostname. Some DNS providers offer technologies such as CNAME flattening to support CNAME-like behaviour at the root domain.
4. MX Record
An MX record, or Mail Exchange record, tells other mail systems where incoming email for a domain should be delivered.
For example, when somebody sends a message to:
[email protected]
the sending mail server checks the MX records for example.com to determine which mail provider should receive it.
A domain may have multiple MX records with different priorities. If the preferred destination is unavailable, a secondary server may be tried. Google’s DNS guidance confirms that MX records route email to the servers hosting the domain’s mail accounts and can use different priority values.
Changing website hosting does not automatically require changing MX records. Accidentally removing or replacing them during a DNS migration can stop incoming email even though the website continues to work.
5. TXT Record
A TXT record stores text-based information in DNS. It is widely used for verification, security policies and email authentication.
Common uses include:
- Domain ownership verification
- SPF email authorization
- DKIM email authentication
- DMARC email policy
- Search Console verification
- Microsoft or Google service verification
- SSL certificate validation
- Third-party application setup
TXT records are not merely descriptive notes. Many contain carefully formatted instructions read by automated systems. One missing quotation, duplicated SPF policy, incorrect hostname or accidental deletion can prevent the associated service from working correctly.
DNS Records and TTL
Every DNS record has a Time to Live, or TTL. This determines how long DNS resolvers may cache an answer before requesting an updated version.
A longer TTL can reduce repeated DNS lookups, but it can also mean that old information remains cached for longer after a change. A shorter TTL can help planned migrations take effect more quickly, although it does not guarantee that every network will update instantly.
Cloudflare notes that old DNS data may remain cached until the previous record’s TTL expires, which is one reason DNS changes can appear inconsistent for a period.
Before an important hosting or email migration, administrators sometimes lower the TTL in advance. After the change is stable, it can be increased again where appropriate.
Domain Registration Versus Web Hosting
A domain and hosting can be purchased from the same provider, but they remain separate services.
Domain registration gives you control over the chosen name for the registration period. Hosting provides the technical environment where the website operates.
You can therefore:
- Keep a domain with one registrar and host the website elsewhere.
- Change hosting without transferring the domain.
- Transfer the domain without moving the website.
- Use one company for DNS and another for both domain and hosting.
- Use a separate specialist provider for email.
Keeping the domain and hosting with different companies can provide flexibility and reduce dependence on a single supplier. Keeping them together can be simpler for some users. Neither arrangement is automatically superior; what matters is that ownership, access and responsibilities are clear.
How a Domain Connects to a WordPress Website
Connecting a domain to WordPress usually involves several separate steps.
First, the domain’s DNS records must point toward the hosting environment. This may involve an A record, AAAA record, CNAME, or a provider-specific configuration.
Second, the hosting server must be configured to recognize the domain. Merely pointing DNS toward a server does not always tell the server which website should respond.
Third, WordPress must be configured with the correct site addresses. WordPress distinguishes between the address where its application files are located and the address visitors use to access the front end. These values are commonly represented through the WordPress Address and Site Address settings.
Finally, the website should have a valid SSL certificate and consistently use HTTPS.
A complete request may therefore follow this path:
Visitor enters domain
↓
DNS identifies the destination
↓
The hosting server receives the request
↓
The server loads the correct WordPress installation
↓
WordPress generates and returns the requested page
If one layer is misconfigured, the user may encounter the wrong website, a server error, a redirect loop, an SSL warning, or a blank page.
Domain Transfers and Website Migrations Are Different
A domain transfer moves the domain registration from one registrar to another.
For example:
Registrar A → Registrar B
The purpose may be to consolidate domains, obtain better support, improve account control, or simplify renewal management.
A transfer does not necessarily move the website, alter WordPress, or change the hosting server. If the existing nameservers and DNS records remain unchanged, the site and email may continue operating normally.
A website migration, by contrast, moves the website from one hosting environment to another.
For a WordPress site, this normally involves:
- Website files
- The WordPress database
- Uploaded media
- Themes and plugins
- Configuration settings
- Server rules
- SSL setup
- Caching
- Scheduled tasks
- Testing
- DNS changes at the appropriate time
WordPress’s migration documentation notes that site URL settings are important because they control where WordPress is located and how both the administration area and front end are addressed.
A hosting migration may therefore require DNS changes without requiring a registrar transfer. Confusing these two processes can lead to unnecessary changes and additional risk.
How SSL Certificates Fit In
An SSL or, more accurately, TLS certificate enables a website to use HTTPS.
HTTPS encrypts traffic between the visitor’s browser and the website, helping protect information from interception or alteration while it is being transmitted.
The certificate must be valid for the domain being visited. A certificate for example.com may not automatically cover every possible subdomain unless those names are included or a suitable wildcard certificate is used.
Certificate authorities must verify that the requester controls the relevant domain. Let’s Encrypt, for example, uses the ACME protocol to automate domain validation, certificate issuance and renewal.
An SSL certificate does not replace the domain or hosting. All three are needed:
- The domain gives visitors the address.
- DNS directs them to the correct service.
- Hosting serves the website.
- The SSL certificate enables a trusted encrypted connection.
During a hosting migration, the new server should have a valid certificate before traffic is fully moved wherever possible. Otherwise, visitors may see security warnings even though DNS points to the correct server.
Email Implications When Changing DNS
Email is one of the most commonly overlooked parts of a domain or hosting change.
A business may host its website with one company while using Google Workspace, Microsoft 365, Zoho, a cPanel mail server, or another provider for email. The routing and authentication information for these services lives in DNS.
Important email-related records may include:
- MX records for incoming mail
- SPF records identifying permitted sending services
- DKIM records used to authenticate signed messages
- DMARC records telling receiving systems how to treat failed authentication
- Autodiscover or provider-specific CNAME records
- Verification TXT records
SPF identifies servers authorized to send mail for the domain. DKIM uses cryptographic signatures to authenticate messages, while DMARC defines how receiving providers should handle messages that fail SPF or DKIM checks.
When changing nameservers, every necessary email record must exist in the new DNS zone before the change is completed. Copying only the website’s A record may keep the website online while breaking incoming mail, outgoing authentication, or both.
After any DNS change, test:
- Sending email from the domain
- Receiving email from an external address
- Replies in both directions
- Contact-form delivery
- SPF, DKIM and DMARC authentication
- Any email marketing or transactional systems
Website forms may also send through separate providers, such as SMTP services or transactional-email platforms. Their DNS records must be preserved even when they are not part of the main business inbox.
Common Domain and DNS Mistakes
Domain and DNS problems are often caused not by complex failures but by simple administrative mistakes.
Allowing the domain to expire
A missed renewal can interrupt the website, email and every other service connected to the domain. Auto-renewal and current billing details reduce this risk.
Registering the domain in the wrong person’s name
A designer, employee or supplier should not be the only person controlling a company’s primary domain. The business should retain ownership-level access and accurate registrant information.
Changing nameservers without copying the DNS zone
This can disconnect websites, email, verification records, subdomains and external applications simultaneously.
Deleting unfamiliar TXT or CNAME records
A record may look unnecessary while actually supporting email authentication, SSL validation, analytics, cloud software, payment services or another important system.
Confusing a registrar transfer with a hosting migration
Transferring a domain is not normally required when moving a WordPress website. Unnecessary simultaneous changes make troubleshooting harder.
Pointing DNS before the new website is ready
The new hosting environment should be tested first. Files, database content, forms, SSL, redirects and other services should be verified before public traffic is directed to it.
Forgetting the www or non-www version
Both versions should be configured, and one should redirect consistently to the preferred address.
Incorrect WordPress URL settings
Changing DNS alone does not update WordPress URLs. Incorrect values can produce broken assets, login problems, redirect loops or links pointing to the previous domain.
Forgetting email records during migration
Website DNS and email DNS often coexist in the same zone. Changing one service should not unintentionally remove the other.
Creating duplicate or conflicting records
Conflicting A, AAAA or CNAME records can cause unpredictable behaviour. DNS should contain only the records required for the intended setup.
Assuming DNS changes are instantaneous
Some changes take effect quickly, while cached answers may continue to be used until their TTL expires. Testing from one device or network does not always show what every visitor sees.
A Practical Domain and DNS Checklist
Before changing anything, record the current configuration.
Confirm:
- Who is the domain registrar?
- Who is listed as the registrant?
- When does the domain expire?
- Which nameservers are authoritative?
- Where are the DNS records managed?
- Which records serve the website?
- Which records serve email?
- Are there important subdomains?
- Which external services use TXT or CNAME verification?
- Where is WordPress hosted?
- What are the WordPress and Site Address values?
- Is SSL active for all required hostnames?
- Is there a complete website backup?
- Is there a tested rollback plan?
Maintaining this information makes future hosting migrations, email changes and technical support much safer.
Domains, DNS and Hosting Must Work as One System
A domain name may appear simple from the visitor’s perspective, but it sits at the centre of several connected services.
The domain identifies the business. DNS directs requests. Hosting runs WordPress. SSL secures browser connections. MX and authentication records support email. Registrars maintain the registration, while authoritative nameservers publish the technical instructions.
None of these components should be managed in isolation.
When changing hosting, nameservers, email providers, domains or SSL configurations, begin by documenting the current setup and identifying which services depend on each record. Make only the necessary changes, test thoroughly, and keep a path back to the previous configuration until the new arrangement is stable.
At HostingITrust, domain and DNS management is treated as part of the wider WordPress hosting environment. A reliable website depends not only on where WordPress is installed, but also on whether the domain, DNS, SSL, email and hosting layers are configured to work together correctly.

Leave a Reply