Domain names collect folklore faster than almost anything else in web hosting. Part of the reason is that the system is old, built from several independent layers (registries, registrars, nameservers, resolvers), and each layer has its own rules and its own delays. Advice that was true for one layer in 2003 gets repeated as if it applied to all of them today.
Below are nine claims we hear on support tickets, in sales chats and in forum threads. Each one gets a verdict, and then the reasoning, because a verdict without the mechanism behind it is just another opinion you have to take on trust. Where a claim can be checked from a terminal in under a minute, we show how.
Eight of the nine come out as myths. One is only partly true, and that is the one that costs people the most money, because it involves email.
1. DNS changes take 48 hours
Myth
A change takes as long as the old record's TTL says, and that is commonly an hour or less. The 48 hour rule of thumb is a worst case that comes from times when TTLs of a day or more were standard, and from changing nameservers at the registry, which can be slower.
If you lower the TTL ahead of time, a typical record change is visible nearly everywhere within minutes.
The mechanism is caching. When a resolver (your ISP's, or a public one) looks up www.example.com, it keeps the answer for as many seconds as the TTL on that record says. Until those seconds run out it will not ask again, so it keeps handing out the old address even after you have changed it at the source. Nothing is "propagating" in the sense of being pushed around the world. Thousands of separate caches are expiring on their own schedules, each one started at a different moment.
That is why a record with a TTL of 300 seconds changes over almost immediately, while one with a TTL of 86400 can linger for a day. The detail people miss is that the old TTL governs. If you lower the TTL from 86400 to 300 and change the address five minutes later, caches that fetched the record an hour ago are still holding the day-long version. The order that works is: lower the TTL, wait out the previous TTL, make the change, then raise it again afterwards.
Nameserver changes are the exception that deserves its reputation. Those are stored as delegation records at the registry for the extension, and the registry sets their lifetime, not you. For .com the delegation records in the registry's zone typically carry a TTL of two days, which is where the 48 hours came from. You can shorten the pain by keeping the old nameservers answering with correct data until that window has passed.
Two other caches add lag that you cannot control: the operating system's own resolver cache, and the browser's. Closing the browser, or flushing the DNS cache on your machine, clears those. Some ISP resolvers also stretch very low TTLs to a minimum of a few minutes. None of this adds up to 48 hours.
2. Your registrar and your web host must be the same company
Myth
They are separate services and it is quite normal to split them. Many people prefer to, because if the hosting company has a problem, or you want to leave, you still control your domain and can repoint it.
Having everything in one place is convenient, and for a beginner convenience is a fair reason. Just know where the domain is registered and keep that login safe.
It helps to see the three jobs as separate. The registrar holds the registration: your contact details, the renewal date, the lock status and the list of nameservers. The DNS provider answers questions about the domain, such as where the website is and where mail goes. The web host runs the server that actually serves pages. One company can do all three, or three companies can do one each, and the internet cannot tell the difference. The only thing that links them is the nameserver list at the registrar and the records inside the zone.
There is a practical reason to keep the registrar separate. If your hosting account is suspended over a billing dispute, or the company disappears, a domain held at a different registrar is untouched. You log in, change the nameservers, and the site reappears elsewhere. If both live in the same account, a suspension can freeze the domain management along with the website, and you are negotiating with the one party you are trying to get away from.
The reverse risk is real too. The most common sad story is a domain registered years ago by a web designer or an ex-colleague, in their name and on their email address. The business has the website and the hosting but cannot renew, transfer or change anything, because the registrant is somebody else. Whoever you choose, make sure the registrant is you or your organisation, the contact email is one you actually read, and the login is stored in your password manager.
3. WHOIS privacy hides who you are
Myth
It keeps your name, address, email and phone number out of public lookups, which cuts down on spam and cold calls. The registrar still knows exactly who you are and must hand over details when legally required.
Many registrars now redact personal data by default for individuals, partly because of privacy law, so check what your registrar already does before paying extra.
The phrase "hides who you are" promises too much. What the service does is replace the public contact fields with a forwarding address or a generic entry. The record of who registered the domain, with a verified email and usually a payment trail, stays with the registrar and, for some extensions, the registry. A court order, a law enforcement request or a formal dispute about the domain can all lead to that data being disclosed. Registrars also have to verify and keep contact data accurate, so giving false details to get more privacy can put the registration at risk.
The older WHOIS protocol has been gradually replaced by RDAP, which returns structured data and can handle redaction more cleanly. Since privacy rules such as GDPR came into force in 2018, public records for individuals in most extensions show little more than the registrar, the dates and the nameservers. For a business registering in its own name, some fields may still be public, so read your own record rather than assuming.
It is also worth knowing what privacy does not cover. The nameservers, and therefore your DNS provider, are public. The IP address your website resolves to is public, and so are certificate transparency logs, which list every hostname that has ever been issued an HTTPS certificate. A determined person can learn a good deal about a site without ever seeing a name in WHOIS. If anonymity matters for a legal or safety reason, treat WHOIS privacy as one small layer and not as a disguise.
4. Registering a domain for ten years helps your search ranking
Myth
Google representatives have said more than once that registration length is not something they use for ranking. Registering for longer is still worth doing for another reason: it protects you from an accidental expiry.
If you are certain the name matters to you, a longer registration or reliable auto-renewal is cheap insurance.
The idea comes from a reasonable-sounding guess: a spammer registers a throwaway domain for one year, a serious business registers for ten, so search engines should favour the long one. The trouble is that registration length is a weak signal to rely on. Spammers can pay for ten years as easily as anyone, and plenty of legitimate sites renew annually for decades. A signal that is cheap to fake and does not separate good from bad is one that search engines have little reason to use, and the people who work on search have said so publicly.
What search does reward is the actual site: pages that answer questions, links from other sites, a server that responds quickly and reliably over HTTPS. None of that is affected by the number of years on the registration record.
The better argument for multi-year registration is operational. The commonest cause of a website vanishing is not a hacker, it is a renewal email sent to an old address and a card that expired. Registering for several years, and also turning on auto-renew, removes two separate ways to fail. Most registrars cap a single registration at ten years for the common extensions, and renewal can be added at any time before expiry.
A few cautions apply. Do not stretch to ten years on a name you are only testing, since renewal fees are not usually refunded if you change your mind. Do not rely on auto-renew alone either: check that the payment card on file is current at least once a year. And keep the registrant email on a domain you do not depend on that same registration for, otherwise an expired domain also means expired notification mail.
5. You own your domain forever once you buy it
Myth
A domain is a registration, normally for one to ten years. If it expires and nobody renews it, it returns to the pool and anyone can register it. It can also be lost through a trademark dispute or a registry rule.
The word owner is convenient, but registrant is more accurate. Renew on time and keep your contact details current.
What you buy is the exclusive right to use a name in a registry's database for a fixed period. The registry (the organisation that runs the extension) sets the rules, and the registrar is its authorised retailer. When the period ends the registration does not vanish at once; it moves through a sequence of stages whose exact length varies by registrar and by extension.
During the early stages the website and email normally stop working, because the registrar replaces your nameservers with a parking page. Renewing in the grace period is usually normal price. Recovering from redemption typically carries an extra fee, often a substantial one. After that the name is deleted and goes back on general sale, where automated services watch for valuable drops and register them within seconds.
Loss can happen while the registration is current, too. Trademark owners can bring a complaint under the Uniform Domain-Name Dispute-Resolution Policy, which applies to the common generic extensions and can end with a domain being transferred. Country extensions have their own rules, and some require a local presence or can suspend names for false registrant details. These cases are uncommon, but they explain why the careful word is registrant.
6. .com is the only extension that ranks
Myth
Search engines treat the major generic extensions equally, and they treat new ones such as .blog or .shop equally too. For country-specific audiences, a country code can be a mild advantage.
The reason .com still matters is people. It is what they type from habit, and a different ending can send some of them to a competitor.
Search engines have said that new generic extensions are treated like .com, with no built-in handicap. Plenty of sites rank well on .org, .net, .io and .co.uk, and a well-built site on an unusual ending will beat a thin one on .com. Country codes do something slightly different: a .de or a .fr gives a clear signal about the target country, which is useful if you want to be shown to German or French users, and less so if you want a global audience. A few country-code endings are marketed as generic and treated that way, so check before assuming.
The human side is where .com keeps its edge. Many people, especially older visitors, finish any web address with .com without thinking. If you run example.shop and a competitor holds example.com, a fraction of your word-of-mouth traffic and of mistyped addresses goes to them. That is a brand problem rather than a search problem, but it can be a real cost.
Some practical points when choosing:
- Say the name aloud. If you have to spell it or explain the ending, the extension is costing you.
- Check whether the .com is held by an active business in your field. If so, a different ending may confuse customers about which firm is which.
- If you take an unusual extension, register the obvious typo and .com versions where affordable, and redirect them to the real site.
- Some extensions have a reputation among spam filters for abuse, and mail from them can face more scrutiny. That is about the individual domain's history, not a formal penalty, but it is worth searching for before committing.
Renewal pricing differs widely between extensions, and some novelty endings are cheap in year one and much dearer afterwards. Look at the renewal price, not the introductory one.
7. Exact-match keyword domains rank easily
Myth
There was a time when a domain like cheap-red-shoes.com gave a head start. Search engines have long since stopped giving it much weight, and may even be wary of obvious keyword stuffing.
A brandable name that people remember is a better long-term asset than a string of search terms.
The belief has a historical basis. In the early years of search, the words in a domain were a strong signal, and a page on a domain that matched the query could rank with little else going for it. Around 2012, search engines publicly adjusted so that low-quality sites relying on an exact-match name lost that boost. A keyword domain can still rank today, but then it ranks because the site is good, not because of the name.
There are costs beyond ranking. A domain made of search terms is hard to remember, hard to say over the phone and awkward on a business card. It tends to look like a low-effort affiliate site, and visitors judge that in a fraction of a second. It also locks you in: when you add a product line that is not red shoes, the name works against you.
A modest version of the idea is fine. A name that contains one relevant word, such as a trade or a town, can work because it tells people what you do. The difference is between a name that describes and one that is trying to game a system. Hyphens are a warning sign: long hyphenated names are associated with spam and are error-prone to type and dictate.
If you must test demand for a niche, do it with a cheap name and judge it on the content and links you earn. Do not pay a premium for a keyword domain on the theory that it will pull rankings by itself. The money is better spent on a clean brand name, and on the site.
8. Changing nameservers breaks your email
Partly true
It does if the new DNS zone lacks the mail records. Nameservers decide where all DNS answers come from, including MX, SPF and DKIM. If you switch and forget to recreate them, mail stops arriving.
Before changing nameservers, copy every record from the old zone to the new one, and check the mail records twice.
The switch itself is harmless. What breaks mail is the new zone being incomplete. When you point a domain at new nameservers, you are telling the world to stop asking the old ones and start asking the new ones, and the new ones only know what is in their zone. If the website records were copied but the mail ones were not, web traffic carries on, and the first sign of trouble is a customer saying you never replied.
Beyond MX, the records people forget are the less obvious ones. SPF and DMARC are TXT records at the domain and at _dmarc; DKIM lives at a selector name such as selector1._domainkey; mail clients often rely on autodiscover or mail hostnames; and verification records for third-party services sit in TXT. Without SPF and DKIM your outgoing mail may still go, but it lands in spam.
A safe sequence looks like this:
- Export or list every record in the old zone, including ones you do not recognise. Unfamiliar TXT records usually belong to a service someone set up.
- Recreate all of them in the new zone before touching the registrar.
- Query the new nameservers directly to confirm the answers, for example
dig @ns1.newdns.example MX example.com +short. - Lower the delegation-adjacent TTLs a day ahead where you can, then change the nameservers at the registrar.
- Leave the old zone running for at least two days, so resolvers that still hold the old delegation get correct answers.
The SPF builder can help you rebuild the SPF line, and the DNS cheatsheet lists what each record type is for. The claim is only partly true because the risk is real but entirely avoidable.
9. An old domain automatically ranks better
Myth
Age alone is not a ranking factor that anyone has shown to matter. Older domains tend to have accumulated links and history, and those are what help, not the date of registration.
A ten-year-old domain with no content has no advantage over a one-year-old site that earns links.
Correlation explains most of this one. If you look at the top results for a competitive query, they are often old domains. That tells you that sites which have been useful for a long time pick up links, mentions and returning visitors, and that old domains are survivors. It does not show that the registration date is doing the work. Take a domain registered in 2009 and left parked, and it carries none of that.
The history can also cut the other way. People buy expired domains hoping to inherit the previous owner's authority. Sometimes there is some left, but search engines are aware of the tactic, and a domain that was used for spam or a hacked site can come with baggage. Before buying a used name, check what it was used for: look at archived copies, and search for the name together with words such as casino or pills to see whether it carries an unsavoury past.
For a new site, the practical conclusion is hopeful. You are not stuck behind a clock. Publish useful pages, get them linked from relevant places, keep the site fast and on HTTPS, and results build from there. A fresh domain can rank for specific, less contested queries in a matter of weeks or months, depending on the field.
One honest caveat: a long-standing domain does bring non-search benefits. Old addresses are on people's business cards, in other sites' links and in email contacts. Dropping one for a new name means redirects and some lost visitors. So if you already have an old domain in use, the advice is not to abandon it for something fashionable; keep it, renew it, and redirect properly if you ever must move.
Commands worth running
Most of the claims above can be tested in a terminal, without trusting us or anybody else. These commands work on Linux and macOS; on Windows, nslookup gives similar answers.
dig example.com A
# the second column of the answer is the remaining TTL in seconds
dig example.com A
# run it again a minute later: the number has counted down
dig NS example.com +short
# which nameservers the world currently believes
dig @ns1.example.net example.com MX +short
# ask the nameserver directly, bypassing every cache
dig example.com TXT +short
# SPF and verification records live hereRepeat the first command and watch the TTL count down: that is a cache doing exactly what claim 1 describes. To see the registry's view of dates and status, use whois example.com or look up the domain through your registrar's panel, and note the expiry date and whether auto-renew is on. For a quick check of record lifetimes before a move, the TTL planner works out when it is safe to switch. If something looks wrong after a change, the troubleshooting guide walks through what to test first.