WhatsApp
Chat on WhatsApp

What Is DNS? How Your Domain Connects to Your Website

When someone types your website address into a browser, they are not thinking about servers, IP addresses or records. They simply expect the site to open. Behind that moment sits one system that most business owners only hear about when something breaks: DNS.

DNS decides where people end up when they type your domain, which server receives your company email and whether Gmail treats your messages as spam. When it is set up correctly, nobody notices it. When it contains a mistake, the website disappears, form submissions stop arriving and emails bounce.

In this guide we cover:

  • what DNS is and why the internet needs it;
  • what happens in the second between typing an address and seeing the page;
  • which DNS records every website owner should know;
  • how DNS affects your business email;
  • how to connect a domain to a website on Webflow, WordPress and Wix;
  • how to move a site to a new platform without downtime, and which mistakes to avoid.

What DNS is, in plain terms

DNS (the Domain Name System) is a distributed system that translates website names into IP addresses. Computers and servers talk to each other using numeric addresses such as 203.0.113.10. People remember names such as rjl.studio. The job of DNS is to bridge those two worlds.

The classic analogy is a phone book. You know the name of the person you want to reach, and the phone book gives you their number. The difference is that DNS has no single book. The information is spread across thousands of servers around the world, and each one is responsible for only a small part of it.

A little history

ARPANET, the network that grew into the internet, had no DNS. The list of every computer on the network lived in a single text file, and anyone who wanted to add a server had to contact the network information centre and ask for the file to be updated by hand. As the network grew, that file became a bottleneck. DNS was defined in the 1980s as an automatic, hierarchical and distributed system in which every organisation manages the records for its own domains.

Domain, IP address and server: what is the difference

Three concepts get mixed up all the time:

  • A domain is the name you buy from a domain registrar, for example example.com. It is yours for as long as you keep renewing it.
  • An IP address is the numeric address of the server where your website lives. It can change when you move to another platform or hosting provider.
  • DNS is the link between the two: the records that tell the internet which IP address your domain points to.

That is why you can switch platforms, for example move from WordPress to Webflow, and keep the same domain. The only thing that changes is the records in DNS.

How DNS works: what happens when you type an address

The whole process usually takes a fraction of a second, but it has several steps. Imagine a visitor typing a website address for the first time:

1. Local memory check. The browser and the operating system check whether they already have the address stored from a previous visit. Every computer also has a hosts file, where you can manually map a name to an address. Developers use it to test a new website before the domain is pointed to it.

2. The resolver. If no answer is found, the request goes to a recursive DNS server, also called a resolver. Usually this is your internet provider's server, but you can use public resolvers such as Google (8.8.8.8), Cloudflare (1.1.1.1) or Quad9 (9.9.9.9).

3. The root server. The resolver asks one of the root servers where to find information about the domain extension, for example .com or .eu.

4. The TLD server. The top-level domain server points the resolver to the servers that manage your specific domain.

5. The authoritative server. This is the server that holds the actual records for the domain. It returns the IP address.

6. Back to the browser. The resolver passes the address to the browser and keeps a copy for a set period of time. The browser then contacts the website's server and loads the page.

A path of glowing light lines leaving a glass laptop, passing through three shiny server cubes at different heights and arriving at a website screen
A DNS request passes through several servers before the browser gets the website's address. Illustration: RJL Studio

Caching and TTL

If every visit had to go through all of these steps, the internet would be far slower. So every server along the way keeps answers in a cache. For how long? That is set by the TTL (Time To Live), a value in seconds attached to each record. A TTL of 3600 means the answer can be cached for up to an hour.

TTL has a very practical meaning for your business: when you change a record, some visitors will keep reaching the old address until their cached copy expires. That is why, after a DNS change, the site "updates" for different people at different times.

Types of DNS servers

  • Recursive resolvers do the work on behalf of the user: they ask the questions, collect the answers and cache them.
  • Root servers sit at the top of the hierarchy. There are 13 root server names, from A to M, operated by 12 organisations. Behind those names there are more than 1,500 instances spread around the world, so a failure in one place does not take the system down.
  • TLD servers manage extensions such as .com, .org or country-code domains like .pt, .de and .eu. Each extension is run by its own registry; .eu, for example, is managed by EURid.
  • Authoritative servers hold the records for specific domains. Most often these are the servers of your domain registrar, your hosting provider or a service such as Cloudflare.
A hierarchical tree of glass server cubes: one large cube at the top, three below it and smaller cubes on the next levels, connected by purple and light blue beams of light
DNS servers are organised like a tree: each level points to the one below it. Illustration: RJL Studio

DNS records every website owner should know

All the information about a domain is stored in a DNS zone made up of records. When you log in to your registrar's dashboard, you will see a table with columns for type, name, value and TTL. These are the records you will meet most often:

A and AAAA records

An A record points the domain to an IPv4 address. An AAAA record does the same for an IPv6 address, the newer and longer format. When a platform asks you to "add an A record for the root domain", this is exactly what it means.

CNAME record

A CNAME is an alias: it says that a particular subdomain points to another name rather than directly to an IP address. The most common use is www, which points to an address provided by your website platform. The advantage is that if the platform changes its server addresses, you do not need to update anything.

MX record

An MX record decides which server receives email sent to addresses on your domain, for example office@example.com. If you use Google Workspace or Microsoft 365, your MX records point to them.

TXT record

A TXT record holds free-form text. It is used mainly for verification and security: Google Search Console, Meta Business and many other services ask you to add a TXT record to prove that the domain is yours. SPF, DKIM and DMARC records, which we cover below, are also usually stored as TXT.

NS and SOA records

NS records define which servers are authoritative for the domain, in other words who manages all of the other records. The SOA record is the opening record of the zone, with technical details such as the primary server and the version number. You will almost never need to edit the SOA record by hand.

CAA record

A CAA record specifies which certificate authorities are allowed to issue SSL certificates for your domain. It is an extra layer of protection, but it is worth remembering: if a CAA record exists and does not include the authority your platform works with, the certificate will not be issued and the site will not open over HTTPS.

A floating glass table with five colourful rows, next to an envelope, a small website screen and a white shield, each connected to a different row by a line of light
Each record type is responsible for something different: the website, email or verification. Illustration: RJL Studio

DNS and business email: SPF, DKIM and DMARC

Many businesses discover DNS through email problems. The proposals you send land in spam, or messages from your website form never arrive. In most cases the cause is missing or incorrect authentication records.

  • SPF is a list of the servers allowed to send email on behalf of your domain. If you send through Google Workspace, an email marketing platform and your CRM, all of them need to appear in a single record. Two separate SPF records on the same domain are a mistake, and they break authentication.
  • DKIM adds a digital signature to every email. The public key used to check the signature is published in DNS, so the receiving server can confirm that the message was not changed in transit and really came from you.
  • DMARC tells receiving servers what to do with email that fails SPF or DKIM: accept it, send it to spam or reject it. It also sends you reports about who is sending email in your domain's name.

Since February 2024, Google and Yahoo have required every sender to have at least SPF or DKIM, and they require all three from bulk senders. Microsoft introduced similar requirements for high-volume senders to Outlook.com addresses in 2025. The details are in Google's email sender guidelines. Even if you never send newsletters, a correct setup improves the chances that a quote reaches the primary inbox rather than the spam folder.

If you collect contacts through your website and email them, authentication is only one part of the picture. In the EU, GDPR and the ePrivacy rules also cover how you obtain consent and handle personal data. This is general information, not legal advice, so check the specifics with a qualified adviser.

Emails from website forms

A website form sends its message from your platform's server or from an automation tool, not from your mailbox. If the service that sends the message is not listed in SPF and has no DKIM for your domain, those messages can be blocked. When you connect forms to a CRM, WhatsApp or automation workflows, it is worth checking this part at setup time. A quick check like this saves you from leads that quietly disappear.

How to connect a domain to Webflow, WordPress and Wix

Before you start, it helps to understand that there are two different roles, and sometimes they sit with different providers:

  • The domain registrar is the company you bought the domain from and where you renew it. Country-code domains such as .pt or .de are sold through registrars accredited by the national registry.
  • The DNS host is the service where the table of records actually lives. Most often this is the registrar itself, but you can move DNS management to Cloudflare, your hosting provider or your website platform.

Two ways to connect a domain

1. Adding records. You keep DNS management at your registrar and add the A and CNAME records the platform gives you. This is the most common approach, and it keeps your existing email records intact.

2. Changing nameservers. You hand over all DNS management to the platform. It is simpler to set up, but if you do not copy your MX and TXT records first, your business email stops working.

Webflow

In the site settings, under the Publishing tab, you add your domain and Webflow shows you the records you need: usually an A record for the root domain and a CNAME for www. Once the records have updated, Webflow issues an SSL certificate automatically. If your DNS is managed in Cloudflare, keep the records that point to Webflow in DNS only mode, as the Webflow documentation recommends. You can learn more about the platform in our Webflow guide, and if you would rather have someone do it for you, we build and launch Webflow websites.

WordPress

With WordPress, everything depends on your hosting company. Most hosts give you an IP address for an A record, or ask you to point your nameservers to them. After connecting, enable SSL in the hosting dashboard and make sure the site redirects from HTTP to HTTPS and from one version of the address to the other, with or without www. Choose a host that offers both a convenient DNS interface and free SSL.

Wix

Wix offers both options: connecting through its nameservers, in which case Wix manages all of your DNS, or connecting by adding records. If you have business email on the domain, make sure your MX and TXT records have been copied into Wix before you change the nameservers.

A 3D golden key entering a glowing keyhole in a glass website screen, next to three shiny cubes in light blue, pink and orange
Connecting a domain to a platform mostly means adding two or three records. Illustration: RJL Studio

Moving a website with no downtime: TTL, propagation and a work plan

The most sensitive moment in the life of your DNS is a move to a new platform. A clear plan reduces the risk to almost zero:

1. Capture the current state. Save a screenshot or an export of every record: A, CNAME, MX, TXT and everything else. Without it, it is easy to delete a record that someone added years ago to verify some service.

2. Lower the TTL in advance. A day or two before the move, lower the TTL of the records that will change to a small value, for example 300 seconds. That way, when you change them, the update reaches everyone within minutes.

3. Test the new site before the switch. Check it on the platform's temporary address or through your hosts file: forms, payments, tracking pixels and redirects.

4. Prepare 301 redirects. If page URLs change, every old URL needs a permanent redirect to its new address. Otherwise you lose Google rankings and traffic from existing links.

5. Switch records at a quiet time. Change only what needs to change and leave your email records alone.

6. Confirm the change has gone through. Check with tools such as dig or nslookup, or with Dig in the Google Admin Toolbox, and make sure the SSL certificate has been issued.

7. Restore the normal TTL. After a day or two of stable operation, set the TTL back to its usual value, for example 3600.

What "DNS propagation" really means

After a change, you will often hear that you need to "wait 48 hours for propagation". In reality, nothing actively propagates: the record changes immediately on the authoritative server, and other servers simply keep using the old answer until its TTL expires. That is why lowering the TTL in advance is the whole secret. Nameserver changes at the registry level can take longer, because those records have a longer TTL.

Moving a website combines DNS, redirects and protecting your rankings. We handle it as part of our SEO and migration services, and our technical SEO audit guide explains what to check after launch.

Security and speed: DNSSEC, encrypted DNS and CDN

DNS was designed at a time when nobody was thinking about attackers, so layers of protection have been added over the years.

DNSSEC

DNSSEC adds digital signatures to records. This lets the resolver confirm that an answer really came from the authoritative server and was not swapped along the way. It prevents attacks in which someone "poisons" the cache and sends visitors to a fake website. Most registrars and large DNS providers let you turn DNSSEC on in a few clicks.

Encrypted DNS

Ordinary DNS requests travel across the network unencrypted, so anyone along the path can see which websites you visit. The DNS over HTTPS and DNS over TLS protocols encrypt those requests. Browsers such as Chrome, Firefox and Edge support DNS over HTTPS.

Securing your registrar account

The most common breach has nothing to do with the protocol: someone gets hold of the password for your registrar account and changes the records. Turn on two-factor authentication, use an email address that stays with the business rather than with an employee or a former contractor, and enable a transfer lock if your registrar offers one. That way, even a leaked password is not enough to take over your domain.

DNS and website speed

DNS response time is part of the load time of every first visit. Large DNS providers keep servers close to users and answer quickly. DNS is often combined with a CDN, a network that serves your website files from the server closest to the visitor. We explain how that works in our guide What is a CDN.

A 3D glass shield with a padlock and a small globe at its centre, surrounded by light blue and purple beams of light and two small server cubes
Signatures, encryption and two-factor authentication protect your domain from takeover. Illustration: RJL Studio

Common DNS mistakes and how to avoid them

Forgetting to renew the domain

An expired domain stops working, and your website and email go down with it. In the worst case, someone else registers it. Turn on auto-renewal and keep your payment details up to date.

Changing nameservers without copying the records

This is the most common reason email stops working the day after a new website goes live. Before you change nameservers, copy every record to the new provider.

Two SPF records, or an SPF record missing some senders

Each domain should have exactly one SPF record that includes every service sending email in its name. When you add a new email marketing tool or CRM, update the existing record instead of adding another one.

DNS managed in someone else's account

If the domain is registered in the name of a designer, a developer or an employee who has left, you depend on them for every change. The domain should be registered to the business, in your own account, and you give providers access permissions.

A website that opens only with www, or only without it

Set up both versions and choose one as the primary. The other should redirect to it permanently, so Google does not see two identical websites.

How RJL Studio helps with domains, DNS and website launches

In most of our projects, DNS takes the least time of any task, and it is also the part where a missed detail is most dangerous. When we launch a new website or move an existing one to Webflow, WordPress or Wix, we:

  • map every existing record and make sure email and integrations keep working;
  • plan the switch with a low TTL, 301 redirects and testing of forms, pixels and payments;
  • set up SPF, DKIM and DMARC so that emails from your website and CRM reach the primary inbox;
  • connect the site to Search Console and your analytics tools, and check indexing after launch.

Planning a new website or a move without losing traffic and email? Get in touch and we will come back to you with a work plan.

Frequently asked questions

How long does a DNS change take to update?

It depends on the record's TTL. If the TTL was 300 seconds, most visitors will see the change within minutes. If it was 86,400 seconds, which is a full day, some visitors may keep reaching the old address for up to 24 hours. Nameserver changes can take longer.

Can I switch platforms and keep the same domain?

Yes. The domain belongs to you, not to the platform. When you move, you change only the records that point to the website, leave your email records as they are and set up 301 redirects for every URL that has changed.

Why do emails from my website land in spam?

In most cases the service that sends the messages is missing from your SPF record or has no DKIM, or there is no DMARC record. Check which services send email in your domain's name, and make sure every one of them is included in SPF and has DKIM set up.

What is the difference between a domain registrar and a hosting company?

The registrar sells and renews your domain, and usually also manages its DNS records. The hosting company stores your website files on a server. On platforms such as Webflow and Wix, hosting is included in the plan, and you simply point your domain to them.

Should I move my DNS management to Cloudflare?

It makes sense if you want a convenient interface, fast DNS, DNSSEC and protection against attacks. When you move, copy every record and check what your website platform requires for the proxy setting. If you run a small site that works well at your registrar, there is no need to move.

Disclaimer: blog content is for general information and learning only and is accurate as of its publication date. It is not professional, legal, financial or business advice, nor a recommendation or call to take any action. Any use of this information is at the reader's own risk, and we accept no liability for any resulting loss. Links to external websites and tools are provided for convenience only. We recommend consulting a qualified professional before making decisions.