How to Set Up DNS Records: A Simple Guide for 2026

You bought a domain, typed it into your browser, and expected your website to appear. Instead, you landed in a maze of records, host fields, TTL settings, and warnings that sound like they're meant for network engineers.

You're not the problem. DNS setup confuses a lot of smart business owners because the controls are simple, but the labels aren't. The good news is that once you understand what each record is doing, the process gets much easier.

Learning how to set up DNS records doesn't require a huge, complicated zone file. For a basic website, you usually need only a small number of records, and adding extra ones can create conflicts instead of solving problems.

Getting Your Domain Pointed Correctly

Think of DNS as the internet's address book. Your domain name is the easy name people remember. DNS tells browsers where that name should go.

If your website lives on one service and your domain is registered somewhere else, DNS is the bridge between them. You log in to your domain provider, add the right records, and that tells the rest of the internet where your site lives.

What most small business owners actually need

If you're only trying to get a website online, keep it simple. A lot of new domain owners assume they need to set up every record type they see in the dashboard. That usually makes things worse, not better.

Data from web hosting forums shows that 42% of misconfigured domains stem from users adding unnecessary DNS records that cause conflicts (discussion on minimum required records for a simple website).

For a plain website setup, the key job is usually one of these:

• Point the root domain so yourdomain.com loads your site
• Point the www version so www.yourdomain.com also works
• Leave email-related records alone unless you're actively setting up email

Practical rule: If you're launching only a website, don't add MX, SRV, or extra TXT records unless your website platform or email provider specifically tells you to.

What the labels usually mean

Different registrars use different words for the same fields. That's one reason DNS feels harder than it is.

You might see:

• Host, Name, or Alias for the part before your domain
• Value, Points to, or Target for where the record sends traffic
• TTL for how long other systems keep a cached copy

If you want a second walkthrough focused on the domain-connection side, this guide on how to connect a domain to a website is a useful companion.

The main idea to keep in mind

DNS isn't about building a website. It's about telling the internet where your website is. Once you see it that way, the dashboard starts to make sense.

Decoding the Alphabet Soup of DNS Records

You open your DNS settings to connect a new site, and suddenly the screen is full of short labels like A, CNAME, MX, TXT, and SRV. That moment throws off a lot of small business owners, because the names sound more complicated than the job they do.

The good news is that each record answers one simple question: where should this part of your domain go? Once you group records by purpose, DNS starts to feel less like code and more like a routing sheet.

Common DNS Records at a Glance

Record Type	Stands For	What It Does	Common Use Case
A	Address	Sends a domain to an IPv4 server address	Pointing your main website to a hosting server
CNAME	Canonical Name	Sends one hostname to another hostname	Pointing www to another web address
MX	Mail Exchange	Tells email where to go	Setting up business email
TXT	Text	Stores verification or policy text	Domain verification, SPF, DKIM, other service checks
SRV	Service	Defines service-specific connection details	Some communication or device services

A record and CNAME record

For a website, these are usually the two records that matter first.

An A record points a domain name to a specific server IP address. If your website platform gives you a number such as 192.0.2.1, that usually means you need an A record for the root domain.

A CNAME record points one name to another name instead of to a number. This is why www often uses a CNAME. It lets www.yourdomain.com follow another hostname that your website platform manages for you.

Here is the practical difference:

• A record: use it when you are given a server IP address
• CNAME: use it when you are given another hostname
• Root domain: often uses an A record
• Subdomains like www: often use a CNAME

If you plan to use other subdomains later, such as shop.yourdomain.com or help.yourdomain.com, this walkthrough on creating a subdomain and pointing it correctly can help.

One common point of confusion is that both records can send visitors to the same website. The difference is how they do it. An A record goes straight to the server address. A CNAME sends traffic to another name first, which then leads to the final destination.

MX and TXT records

These records usually matter when you add email, verify domain ownership, or connect outside services.

An MX record controls where your email is delivered. If someone sends a message to you@yourdomain.com, the MX record tells the sending system which mail provider should receive it.

A TXT record holds text instructions. That sounds vague, but it is useful. Many services use TXT records to confirm you own the domain. Email providers also use them for security rules such as SPF and DKIM.

For a simple website launch, you often do not need to touch MX or TXT records unless your website platform or email provider specifically asks for them. That matters for Solo AI users in particular. The fastest setup is usually the smallest one. Add only the records required to get the site live, then test, then add extras later if needed.

SRV records in plain language

SRV records are less common for a basic business website.

They are mainly used by specific apps and services that need to tell devices which server and port to use. Voice tools, chat systems, and some Microsoft services may ask for them. A normal website connection usually does not.

If your goal today is just to get your Solo AI site loading on your domain, you can usually leave SRV records alone.

TTL and why it matters

TTL stands for Time to Live. It controls how long other systems keep an old copy of your DNS record before checking for a fresh one.

TTL works like a refresh timer. If the timer is set high, the internet keeps using the saved answer longer. If the timer is set low, systems check back sooner and pick up changes faster.

This field matters because it explains the DNS waiting game that frustrates so many non-technical users. You can enter the correct record, save it, and still see the old website for a while. That does not always mean the change failed. It often means other systems are still using a cached answer until that timer runs out.

Squarespace's documentation on editing DNS record settings shows that TTL is a real cache setting with a wide range of possible values. For everyday website changes, the practical lesson is simpler:

• Lower TTL can help before a planned DNS change
• Higher TTL is fine once your setup is stable
• Old results can stick around temporarily, even after you save the correct record

That last point saves a lot of unnecessary panic.

Where people usually get stuck

Problems here are usually very ordinary. Someone enters www in the wrong field. An old A record is left in place and conflicts with the new one. Or email-related records get edited during a website setup that never needed them in the first place.

Another common mistake is assuming every DNS record must be filled out before a site can work. It does not. For most AI website builders, including Solo AI, the goal is to identify the few records that matter for web traffic, enter them exactly, and then give DNS time to update.

If your changes do not appear right away, that is often a caching delay, not a disaster.

Configuring DNS for Your Solo AI Website Creator Site

You bought a domain, connected it to your Solo AI site, clicked Save, and expected your new website to appear right away. Instead, you still see the old site, a parking page, or an error. That moment confuses a lot of small business owners because the records may already be correct. The internet just has to catch up.

For a Solo AI website, the goal is usually simple. You are setting the minimum website records needed so people can reach your site at your main domain and, in many cases, the www version too. You do not need to fill out every DNS field you see. You need the right few records, entered in the right place, without conflicts.

Where to make the changes

DNS changes happen where your domain is managed. That is usually your registrar, the company where you bought the domain, or your DNS host if you moved DNS somewhere else.

Look for a menu with names like:

• DNS
• DNS Management
• Advanced DNS
• Zone Editor
• Manage Records

Once you open that area, you are looking for the current record list first, not the Add button. Reading the existing records before changing anything helps you spot old website entries that may still be steering traffic elsewhere.

The safest setup flow

A careful order prevents a lot of avoidable mistakes.

1. Find the website-related records already in place
   Look for an A record on the root domain, often shown as @, and any CNAME for www.

2. Compare them with the values Solo AI gives you
   Solo AI will tell you what each record should be. Treat those instructions like a delivery address. A single wrong character can send visitors to the wrong place.

3. Remove or replace only the records that conflict
   If an old website builder left behind a record for the same host, that old record needs to go. Leave email and verification records alone unless you know they are no longer needed.

4. Add the new records exactly as shown
   Pay close attention to the Host and Value fields. Those two fields cause the most trouble.

5. Save, then refresh the record list
   Confirm the new entry appears and that you do not have two records competing for the same hostname.

Some registrars warn you about formatting mistakes before saving. Others do not. If your panel is one of the quiet ones, slow down and check each field line by line.

What Solo AI usually needs

For many AI site builders, including Solo AI, the setup comes down to two jobs:

• sending the root domain to the website destination
• sending the www version to the correct hostname

That often means an A record for the root domain and a CNAME for www, though your exact values depend on the instructions inside Solo AI. Copy those values exactly. DNS is less like writing a sentence and more like entering a phone number. Close is not good enough.

A common point of confusion is the Host field. If Solo AI says the host is www, enter www. Do not type the full domain unless your registrar specifically asks for the full format. Different panels display this differently, which is why two people can enter the same record in different ways and both be correct.

If you want a separate area such as blog.yourdomain.com or shop.yourdomain.com, this guide on how to create a subdomain walks through that setup.

How to read the registrar form without overthinking it

Most DNS forms use different labels for the same few ideas. Once you know what each field is doing, the screen gets much less intimidating.

• Type
  The kind of record, such as A or CNAME.

• Host or Name
  The part of the domain this record controls, such as @ or www.

• Value, Target, or Points to
  The destination. This is the IP address or hostname provided by Solo AI.

• TTL
  The cache timer. A higher number can mean you wait longer to see changes in every location.

A good way to picture it is this: the Host is the apartment number, and the Value is the street address. If either one is wrong, the visitor does not arrive where you intended.

If that still feels abstract, this walkthrough shows the process in action:

How to tell whether your changes are working

Saving the record is only half the job. The other half is confirming that DNS is updating, especially during the waiting period.

Start with these checks:

• Refresh your DNS page to confirm the new record is still there
• Check for duplicates on the same host, especially old A records or an extra www record
• Open your site with and without www to see whether one version works before the other
• Try from another device or mobile connection because your current browser may still show a cached result
• Take a screenshot of the final records so you have a clean reference if support needs to help

If the site does not appear right away, do not assume the setup failed. DNS updates often work in stages. One network may see the new destination before another does. For non-technical users, that waiting game is the hardest part of the whole process, but it is normal.

The win here is knowing what "done" looks like. For a basic Solo AI launch, you usually need only the records that point web traffic correctly. Once those are in place and no conflicting records remain, the rest is mostly verification and patience.

Connecting Email and Other Third-Party Services

A common small business scenario goes like this. Your Solo AI site is live, the homepage loads, and then you try to set up hello@yourdomain.com or connect a booking tool. Suddenly the domain feels broken again.

Usually, it is not broken. You are just adding a new layer.

Your website records tell browsers where to find your site. Email and other services use different records on the same domain, more like separate departments sharing one street address. That is why a Solo AI site can be working even while email setup is still incomplete.

MX records for business email

An MX record tells the internet where to deliver mail for your domain. If someone sends a message to you@yourbusiness.com, the MX record points that message to Microsoft 365, Google Workspace, or whichever email service you chose.

The confusing part is Priority. Lower numbers get tried first. So priority 0 beats priority 10. It feels backward, but it helps mail systems know which server should receive mail before any backup option.

If email does not start working right away, do not rush to change your website records. Check the MX record details first:

• Host/Name is entered exactly as your email provider shows it
• Mail server value was copied fully, with no missing characters
• Priority matches the provider's instructions
• Old MX records were removed if your provider told you to replace them
• Time has passed for the new record to spread

TXT records for verification and email trust

TXT records are often the proof step. A service asks you to place a short text value in DNS so it can confirm that you control the domain.

You may see TXT records used for:

• Domain ownership verification for Microsoft 365 or Google Workspace
• SPF, which helps receiving mail servers recognize approved senders
• DKIM or other email signing methods, depending on the provider
• Third-party tools such as forms, CRMs, and marketing platforms

A TXT record is like putting a temporary sign in your shop window that says, "Yes, this is my business." The service checks for that sign before it trusts the connection.

Verification usually fails for simple reasons:

• The record was added to the wrong host, such as www instead of the root domain
• Part of the TXT value was left out during copy and paste
• A required character, quote, or space changed
• The old value is still being shown because DNS has not updated everywhere yet

That last point causes a lot of frustration. You can save the correct record and still see "verification failed" for a while. For non-technical users, this is the hardest part of DNS. The change may be correct, but the internet has not caught up yet.

Keep website records separate from service records

The safest way to work is to treat each service as its own task.

Point the domain to your Solo AI site first. Confirm the site loads. Then add email records. After that, connect extras like a scheduler, CRM, or newsletter tool one at a time.

This approach makes troubleshooting much easier because you know which change caused the problem.

A simple checklist helps:

• Leave your working web records alone unless the website itself has stopped loading
• Add only the records the service asks for
• Change one service at a time
• Test after each save, such as sending a real email or completing the provider's verification check
• Keep a screenshot or note of each record so you can compare later if something stops working

If you are still deciding how to split your website, email, and tools across providers, this guide to web hosting and email options for small business gives a useful overview.

When you handle DNS this way, the waiting game becomes less stressful. You are no longer guessing whether the whole domain failed. You are checking one service, one record type, and one result at a time.

Troubleshooting Propagation and Common Errors

The most common DNS problem isn't a broken setup. It's assuming the setup failed when it's still spreading.

DNS changes officially require up to 24 hours to propagate globally (Dyn's guide to setting up DNS for a new website). During that window, some people may reach the new site while others still see the old one. The same source notes that this confusion leads 78% of small business users to abandon setup attempts prematurely.

What propagation actually means

When you save a DNS change, the whole internet doesn't update at once. Different systems keep cached copies for a while. Some refresh quickly. Others take longer.

That's why you might see the new site on your phone but the old site on your laptop. Or your client in another city may report a different result than you see in your office.

This doesn't always mean something is wrong.

What to do instead of refreshing the browser

Use a DNS propagation checker or your registrar's DNS lookup tools. These tools show whether your new record is appearing in different places.

Check the exact record you changed. If the tool shows the expected value in some locations but not others, propagation is in progress.

Then do these checks:

• Clear your browser cache if your browser keeps showing an old page
• Try a different network such as mobile data instead of office Wi-Fi
• Check for typos in the Host or Value field
• Look for conflicts such as two records controlling the same hostname

Mistakes that commonly slow people down

Some errors look like propagation but aren't.

1. Wrong Host entry
   People enter the full domain when the form expects only the subdomain, or the other way around.

2. Conflicting records
   An old A record and a new CNAME can fight for the same hostname.

3. Editing the wrong DNS provider
   If your nameservers point elsewhere, changes at the registrar you first bought the domain from may have no effect.

4. Fixing a typo after the first save
   Dyn notes that if a CNAME is entered incorrectly and then corrected, the propagation cycle has to begin again from the time of the correction in that same documented propagation window.

Don't use your own browser as the only test. DNS is global, and your browser sees only one cached version of the world.

A calm troubleshooting routine

When a DNS change doesn't seem to work, use this order:

• Verify you're editing the active DNS host
• Check that the record type matches the provider's instructions
• Confirm the Host field format
• Use a propagation checker
• Wait before making random extra changes

That last step matters. Panic-editing creates more variables, which makes the original issue harder to find.

DNS Best Practices for Long-Term Success

DNS works a lot like a set of business instructions taped behind the front desk. If those instructions are current, customers reach the right website, email goes to the right inbox, and outside services can verify your domain without trouble. If the notes are outdated or messy, small problems pile up over time.

Keep records tidy

Set a reminder to review your DNS records a few times a year, especially after switching website platforms, email providers, or booking tools. Remove records for services you no longer use, and label the ones you keep if your DNS provider allows notes.

DNS problems often come from leftovers, not from new changes. An old record can misdirect traffic or block a new setup from working the way it should.

Use TTL intentionally

TTL controls how long other systems are allowed to remember your DNS information before they ask for a fresh copy. A shorter TTL is like telling people, "Check back soon, these directions may change." A longer TTL is better once everything is settled, because it reduces repeated lookups.

For a planned change, such as connecting a Solo AI site, lowering TTL ahead of time can make the waiting game less frustrating. After the new records are working and you have confirmed the site loads correctly, you can raise it again for day-to-day stability. If you forget to do this before a change, do not panic. The update can still work. It may just take longer for old cached answers to disappear.

Protect the registrar account

Your domain account controls where your website and email point. Treat it like a bank login. Use a unique password, turn on two-step verification if it is available, and limit account access to the few people who need it.

A stolen registrar login is not just an admin problem. It can send customers to the wrong site or stop email from arriving.

Save a record of changes

Before you edit anything, take a screenshot or export your DNS zone if your provider offers that option. Keep a simple dated note of what you changed, why you changed it, and what the old value was.

That record helps in two common situations. First, if something breaks, you have a clean rollback point. Second, if a change seems delayed, you can confirm whether you are still waiting on propagation or whether the value entered was wrong from the start.

If you want to launch a professional site without getting buried in setup screens, Solo AI Website Creator gives you a fast path to publish your online presence and connect your domain with less friction. It's a practical option for small business owners who want a polished website without turning DNS into a weekend project.