Academy › Publishing › Domain and email
The new subdomain doesn't inherit anything from the old setup
After this lesson, you'll have the subdomain record created as a new row, know which DNS rows should never be touched in this step, and have confirmed that the website and email that were already working still respond the same way.
By Yodai · Published on September 6, 2026 · Updated on October 12, 2026
You have minegocio.com up and running: the site loads, email comes in. You've decided the new thing will be a subdomain, store.minegocio.com, instead of a folder inside the same site. Now you have to create it, and the same fear that stops almost everyone before touching DNS shows up: if you create this new row, do you stop receiving email? Does the site you already have go down?
The fear isn't silly, but it's pointed at the wrong thing. Your domain's DNS is a list of independent rows, not a block of text that gets rewritten from scratch every time you add something. Creating a new row for store doesn't change a single letter of the ones you already had. The real risk is somewhere else: inside that same panel, mixing up which row you're supposed to touch.
A new row, not a row that changes
DNS is a list of rows. Each row has a name (the word it responds to: the domain alone, or a subdomain in front), a type (what kind of data it stores: an address where a website lives, a destination for email, a verification text) and a value, which is the actual data.
The row that makes mybusiness.com load your website today is one row. The one that gets email into your inbox, an MX-type row, is a completely different one. They have different names and different jobs, and they coexist in the same list without stepping on each other as long as nobody edits the one they shouldn't.
When you create store.mybusiness.com, you add a row with a new name: store. The root domain doesn't lend it anything, not its website's address, not its email rules, and creating it doesn't take anything away from the root domain either. They're neighbors, not family.
An example helps more than theory. If your provider shows you a table with columns Name, Type, and Value, the @ row today says something like Name: @, Type: A, Value: a string of four numbers. The row you're about to create says Name: store, Type: CNAME, Value: the destination your store's hosting service gave you. These are two separate lines in the same table, and the second one doesn't replace the first just because they look similar.
each name is a separate entry in the list: there's no inheritance between the root domain and whatever hangs off it
What you touch, and what you don't
Before you log in to your domain provider's panel (the site where you bought mybusiness.com, not the program you use to build your website), it helps to have in front of you a list of what already exists and what happens to each row when you create the new record.
- 1Log in to your domain provider's panel
This isn't the program you use to build your website: it's where you bought mybusiness.com, and where the rows that run your current website and email already live. - 2Find the DNS records section
It's usually called DNS, DNS Zone, or Records, depending on the provider. - 3Click add record, never edit one that already has data
If the button you're about to click says edit and the row already has a value, you're at the wrong door. - 4Choose the right type
A if you were given an IP address, CNAME if you were given a destination name. Use whichever one you were told to use, not whichever sounds better to you. - 5In the name field, type only the subdomain word
Store, not store.mybusiness.com: the panel adds the domain on its own, and typing the whole thing usually duplicates the ending. - 6Save it with a low TTL
Three hundred seconds, five minutes, is plenty. If something goes wrong, the error lasts minutes instead of a whole day.
Confirm all three are still alive
The person who notices something broke is almost never you, it's a customer writing through your contact form, or worse, one who doesn't write because they've already assumed you closed. That's why, once the record is saved, you shouldn't close this out without checking three things separately.
Open mybusiness.com in a new tab: it has to load exactly the way it did before you touched anything. Send a test email to your own address at that domain: it has to arrive in under a minute, like always. And open store.mybusiness.com: if you just created the record, it can take anywhere from a few minutes to a couple of hours to resolve, depending on how long that row's absence was cached before you created it. The low TTL you set in the previous step is for the next change you make, not for this first time.
If your existing website or email breaks right after you create the record, check the row you weren't supposed to touch first: the @, the www, or the MX. A row with its own name, like store, can't affect rows that don't share that name.
With this set up, you now have the rule that applies to any row you add later: you create a new one, you don't edit the one that already works.
- The record for the subdomain you chose is created, as a new row and not as a change to an existing one.
- You're clear on which rows don't get touched in this step: the @, the www, the MX, and the email TXT record.
- You confirmed that the website and email that were already working still respond the same way as before.
- If something stopped working, you know to check the row that shouldn't have been touched, not the new record.
Cases to decide
Answer before opening each one. If one gives you trouble, go back to the section that explains it.
1. You log into your provider's panel and only see an A row named @ and a CNAME row named www. There's no row with the name of the subdomain you chose. What do you do?
You add a new row, either type A or CNAME, with the subdomain's name. You don't touch the @ or the www: they're already doing their job, and the subdomain needs its own row because it doesn't inherit anything from the ones that exist.
2. Right after you save the subdomain record, a customer messages you that mybusiness.com won't load. Is the record you just created the culprit?
Only if you created it with the name @ or www by mistake. A row with a different name can't affect the ones that already existed: check whether, while looking for where to add the new one, you accidentally touched the root domain's row.
3. Three hours have passed since you created the record, and store.mybusiness.com still won't load, even though the rest of the domain works fine as always. What do you check first?
The value you typed in the row: that the type is correct, A or CNAME, and that the destination is spelled right, with no extra spaces or periods. After a few hours, it's no longer a caching wait, it's a mistake in what you entered.
The subdomain row is already in place and verified. The next one you might need to touch is different: a TXT record, like the one Meta asks for to verify the domain is yours, at the same name where your email's SPF already lives, and there the margin for error is even smaller.
In Yodai you connect the domain you already have to your site, and it stays registered where it is, in your name. See how your own domain for your website works.
NextIf Meta asks you to verify your domain