Guides / Concepts explained

How Domains and DNS Work: A Guide for Non-Developers

How domain names and DNS connect example.com to your app: registrars, nameservers, A, CNAME, MX and TXT records, propagation, and connecting a custom domain.

Mythex Team · 2026-09-29 · 6 min read

A domain is the name people type to reach your site, like example.com, and DNS (the Domain Name System) is the internet's directory that translates that name into where your site actually lives. You rent the domain from a registrar, then add DNS records that say "the website is over there" and "email goes over here." Connecting a custom domain to an app is mostly a matter of adding the right record in the right place and waiting for it to take effect.

Why it matters when you build with AI

An AI app builder can write and host your app, but your domain lives outside it — often with a separate company, in a control panel full of unfamiliar record types. This is where many launches stall: the app is ready, but the domain shows an error, or email mysteriously stops working after a DNS change.

A little understanding goes a long way. You'll know which record your host is asking for, why it hasn't worked yet, and how to avoid breaking the things (like email) that already rely on your domain.

An everyday analogy

Think of your phone's contacts list.

You don't remember your friend's number; you tap their name and the phone looks it up. DNS does the same for the internet: you type example.com, and DNS looks up the number (the IP address) of the server to connect to.

• The domain is the contact's name.
• The registrar is the company that officially records that the name is yours.
• DNS records are the details saved under the name: phone number, email address, home address.
• Nameservers are which contacts book is the official one for that name.
• Caching is your phone remembering a number for a while. If your friend changes numbers, some phones will keep calling the old one until their saved copy is refreshed — that's DNS "propagation."

The parts of a domain name

Take app.example.com:

You don't buy a domain outright; you register it for a period (usually a year or more) and renew it. Let it lapse and someone else can register it.

How a DNS lookup works

When someone types app.example.com:

1. The browser asks a DNS resolver — usually run by their internet provider or a public service — for the address.
2. If the resolver has a fresh cached answer, it replies immediately.
3. If not, it works down the hierarchy: the root servers point it to the .com servers, which point it to your domain's nameservers.
4. Your nameservers return the record you set, such as a CNAME to your host or an A record with an IP address.
5. The resolver caches the answer for the record's TTL (time to live) and hands it to the browser, which connects to the server.

This all usually happens in milliseconds.

DNS record types you'll actually use

A few rules worth knowing:

• A CNAME can't share a name with other records. That's why a standard CNAME can't go on the root domain, which always has NS and other records. Many DNS providers offer workarounds called ALIAS, ANAME or CNAME flattening.
• TXT records do a lot of email work. SPF lists who may send mail for your domain; DKIM publishes a key to verify signatures; DMARC tells receivers what to do with mail that fails those checks.
• Lower MX numbers mean higher priority. Mail tries the lowest first.

Propagation and TTL

"Propagation" makes it sound like changes spread slowly across the internet. What actually happens is caching: resolvers keep a copy of each answer for its TTL, and only ask again once that expires. So:

• A new record that has never been looked up often works within minutes.
• Changing an existing record takes up to its old TTL to be seen everywhere.
• Changing nameservers can take up to a day or two, because those records are cached for longer at the TLD level.

A useful trick: before a planned change, lower the record's TTL (say to a few minutes), wait for the old TTL to pass, then make the change.

A worked example: connecting a booking app to your domain

You own yoursalon.com. Your current website and Google Workspace email already use it. You've built a booking app and want it at book.yoursalon.com.

1. Find where your DNS is managed. It may be your registrar or a separate DNS provider. Your NS records tell you.
2. Add a CNAME for book pointing to the target your app host gives you.
3. Add any TXT record your host asks for to prove ownership, if it uses one.
4. Leave MX and email TXT records alone. Email keeps working because you haven't touched it.
5. Verify in your host once DNS has updated. The host then issues an HTTPS certificate for book.yoursalon.com.
6. Test on a phone using mobile data, which uses a different resolver and cache than your home Wi-Fi.

If you wanted the app on the root yoursalon.com instead, you'd need A records or your DNS provider's ALIAS/flattening feature — and you'd be replacing your current website there. For more steps, see how to connect a custom domain.

Common mistakes and misconceptions

• "The domain and hosting are the same thing." The domain is the name; hosting is where the app runs. DNS links them.
• Using an A record when the host asked for a CNAME (or the reverse). Follow the host's instructions exactly.
• Typos in the target. One wrong character in a CNAME target and verification fails.
• Switching nameservers without copying records. Moving DNS to a new provider without recreating MX and TXT records is a classic way to break email.
• Proxying when you shouldn't. Some DNS providers, such as Cloudflare, can proxy traffic. Some hosts need the record set to "DNS only" so they can issue certificates.
• Deleting "unknown" TXT records. They're often verification or email security records something depends on.
• Letting the domain expire. Turn on auto-renew and keep the payment card current.

What to ask your AI builder for

DNS lives outside your code, so this is more about what to ask about:

• "What exact DNS record do I need for app.mydomain.com — type, name and value?"
• "Will this change affect my email?"
• "My domain shows an error after adding the record. What should I check?"
• "Add the correct canonical URL and redirects so www and non-www don't both show the site."
• "Set up sending email from my domain — which SPF, DKIM and DMARC records will I need?" See how to send emails from your app.

Custom domains on Mythex

Every published Mythex app gets a yourname.mythex.ai address. On Pro you can use your own domain instead: buy one inside Mythex (registration is billed separately, and DNS for bought domains is managed for you), or connect one you already own by adding a CNAME from a subdomain such as app.example.com to your app's yourname.mythex.ai address, then clicking Verify. HTTPS is issued automatically. If your DNS is on Cloudflare, set that record to "DNS only." Subdomains are recommended; root domains depend on your DNS provider's ALIAS or flattening support. The custom domain docs walk through each step, and pricing shows what Pro includes.