Academy › Publishing › Domain and email
The map you'll never have to improvise again
By the end, you'll have written down, line by line, what each DNS record is for, so you never touch it blindly again.
By Yodai · Published September 6, 2026 · Updated October 13, 2026
Months have gone by. Your website works, the store lives on its own subdomain, the WhatsApp number is already verified, the checkout button charges without a hitch, and you even have the English version. One day you go back to your domain's DNS zone, in the account where you bought it, to renew something, switch email providers, or verify the domain for another service, and there they are: twelve or fifteen lines, each with a strange name and an even stranger value. You don't remember what half of them are for.
That moment is the real danger. Someone looks at that list, doesn't recognize three or four lines, and decides they're not needed. They delete them to "clean things up." Two days later the business's email stops arriving, or Google can't find the proof that the domain is yours and warns that your Search Console access is about to expire, or the checkout button starts failing right at payment. Nobody touched the website. They touched the DNS, and DNS doesn't give you a warning. Servers that look up your domain can keep a cached copy of each line for as long as its TTL says, according to the DNS standard (RFC 1035), so a change doesn't reach everyone at once. Google, for example, notes in its help guide for setting up MX records that a new MX record can take up to 72 hours to be recognized. The failure shows up quietly, hours or days later, by which point nobody remembers what was changed.
The fix isn't technical. It's a matter of discipline: the first time you understand what a line does, you write it down. Not in your head, in a document. This lesson is that document.
Why that screen fills up without anyone deciding to fill it
Every yes you said over these past weeks left a mark there. The subdomain for the store, which didn't inherit anything from the main website. The proof for Google, for Search Console, that the domain is yours. The checkout button, with its own separate proof: if the payment page runs on one of your subdomains, Stripe asks you for a TXT record to confirm the domain is yours before it can issue its security certificate, according to its documentation on custom domains. The decision on whether the new marketplace would live on the same domain or get its own. Each of those decisions added a line to the DNS, and that line made sense when it was created. The problem is that the sense behind it lived only in the head of whoever created it, you or whoever helped you, and that's not always the person looking at it six months later.
A CNAME says "this subdomain lives at such-and-such place": it's the one you used for the store, for the English version, maybe for a sister brand. An MX says where the business's email comes in, and you've usually had it since day one, even before you had a website. A TXT almost never moves anything: it just stores a bit of text that a third party reads to confirm something. For example, that the domain is yours: a TXT record is one of the methods Google accepts in its help guide for verifying site ownership in Search Console, and it asks you not to remove it even after verification, because it checks periodically. Or that the email coming from your domain is really sent by you and not someone pretending to be you: that's what SPF and DKIM are for, according to Gmail's guidelines for senders. SPF, in fact, can only be published as a TXT record, according to its standard (RFC 7208). Three types, three jobs, and yet they all show up mixed together in the same list, in the same font size, with no clue as to which one matters more.
This is an example of a website built from separate pieces: if your website, your store, and your payments all run on a single platform, your DNS might only have the lines for your website and your email.
- 1Open your domain's DNS zone
It's in the account where you bought the domain or wherever you manage it now, under a name like "DNS Zone" or "DNS Records." All the lines are there, even ones you never touched yourself. Write down how many there are, without deciding yet which ones are extra. - 2Identify each one before deciding anything about it
For every line, ask yourself what service it serves: website, store, email, Google verification, payments, language. If you don't know, don't delete it: mark it as pending identification and move on to the next one. - 3Write down the month it went live
You don't need the exact day. "March 2026, when we turned on payments" is enough. Later on, the date tells you whether a recent change lines up with a recent glitch. - 4Save the document somewhere you'll find it in six months
Not on a sticky note, not in the memory of whoever set it up. In the same folder where you keep your business invoices, or in the notes app you use every day.
Before you touch anything, check the type
- The document listing every DNS line, its type, and what it's for, written down and kept in one fixed place.
- The date each one was activated, so you can connect a change to a problem if one shows up.
- The rule: never delete or touch anything that isn't identified in that document.
- The habit of checking the record type before you act: MX is email, CNAME or A is the website or a subdomain, TXT is a verification record.
Test yourself
Answer before opening each one. If one gives you trouble, go back to the section that explains it.
1. You switch payment processors, and the new provider's support team asks you to delete the old verification TXT record. What do you check before deleting it?
That on your map, that TXT record is labeled as belonging to the old payment gateway and doesn't match the one used for email or Google verification; sometimes two services share a similar prefix and the wrong one gets deleted.
That on your map, that TXT record is labeled as belonging to the old payment processor and doesn't match the one used for email or Google verification; sometimes two services share a similar prefix and the wrong one gets deleted.
When you set up the new one, if the new provider asks you to: Google, for example, in its help guide for setting up MX records, asks you to remove the other MX records because keeping the old ones can keep email from working properly. What you shouldn't do yet is close the old mailbox: a new MX record can take up to 72 hours to be recognized, and in the meantime, some email may still arrive at the old provider.
3. You hire someone to manage the domain from now on. It's their first day. What do you hand them before giving them access to the domain account?
The written map of every line, not just the password; that way they can identify each record before touching anything, instead of learning by breaking something and seeing what stops working.
Sources
- RFC 1035: Domain Names - Implementation and Specification. IETF, 1987 (accessed October 2026).
- RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF, 2014 (accessed October 2026).
- Email sender guidelines. Gmail Help, Google (accessed October 2026).
- Set up MX records for Google Workspace. Google Workspace Help, Google, updated October 2026.
- Verify you own a website. Search Console Help, Google (accessed October 2026).
- Use your custom domain. Stripe documentation (accessed October 2026).
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.
NextThe account you log in with can't be your everyday one