Domain setup mistakes that break websites and business email

Domains break in a particular way: everything is fine for two years, someone makes one edit, and within hours the website is unreachable and email has stopped arriving. Because both symptoms appear together, people usually blame the hosting company, which is rarely where the problem is. This article walks through the domain setup mistakes that cause the most damage for Indian small businesses, how to recognise each one from its symptoms, and what to do first.

Wiping MX records while changing web hosting

This is the single most expensive mistake. Your website and your email are usually two separate services connected to the same domain. The A record points visitors at the web server; the MX records point mail at the mail server, which might be Google Workspace, Microsoft 365, Zoho or your host.

When a new hosting provider says “point your nameservers to us”, the domain starts using their DNS zone, which contains a default set of records. If that default zone has no MX records, or MX records pointing at their own unused mail server, incoming mail stops or bounces from the moment the change takes effect.

The fix: before changing nameservers, export or screenshot the entire existing DNS zone. Recreate every record in the new zone before switching, especially MX, plus the TXT records for SPF, DKIM and DMARC. Missing those three does not stop mail, but it quietly sends your invoices to spam.

Conflicting or leftover A records

An A record maps a name to an IP address. Problems start when more than one answer exists for the same name.

• Two A records for the root domain pointing at the old and new server, so visitors randomly see the old site.
• An A record and a CNAME for the same name, which is invalid and produces unpredictable behaviour.
• A www CNAME pointing to the root while the root still points to a decommissioned server.
• A record left behind after a migration, which later gets reassigned to someone else's server, so your subdomain serves a stranger's content.

The fix: after any migration, list every record in the zone and delete what no longer has a purpose. One name should have one clear destination.

Forgotten subdomains

Subdomains accumulate: a shop subdomain from an abandoned experiment, a staging copy, an old mail gateway, a tracking subdomain created for an ad platform years ago.

They matter for two reasons. A staging subdomain left public can be indexed by search engines, competing with your real pages. More seriously, a subdomain pointing at a cloud service you no longer use can be claimed by somebody else, letting them serve content on your brand's address.

The fix: audit the zone twice a year. For each subdomain ask what it serves, whether it is still needed and whether it has a valid certificate. Delete the rest.

Registrar account problems nobody notices until renewal

The registrar is where the domain itself lives, separate from DNS and hosting. Access problems here are the hardest to fix under pressure.

• The account is in a former employee's or a previous agency's personal email.
• Two-factor codes go to a phone number that is no longer in use.
• The registrant contact email is an address on the same domain, so if the domain lapses you cannot receive the recovery mail.
• Auto-renew is off, or on but attached to an expired card.
• Registrar lock is disabled, leaving the domain easier to transfer away.

The fix: move the domain into an account owned by the business, use an external contact address that does not depend on the domain, turn on auto-renew and registrar lock, and keep the login in your documented recovery plan. Set a calendar reminder a month before expiry regardless of auto-renew.

Changes that look broken but are only caching

Not every post-change problem is a mistake. DNS answers are cached by resolvers for the length of the record's TTL, so a change can be live for you and invisible to a customer for hours. Before undoing a correct change, check the domain from a different network, such as mobile data, and verify what the authoritative nameservers are actually returning.

Repeatedly editing records during this window is what turns a wait into a genuine outage, because you end up with several half-applied configurations in circulation.

Reading the symptoms before you touch anything

1. Website down, email fine: look at the A record or web hosting, not the domain.
2. Email down, website fine: look at MX and TXT records.
3. Both down together: suspect nameservers, domain expiry or a zone that was replaced.
4. Security warning in the browser: a certificate problem, usually because the certificate does not cover the name being used or was not reissued after a move.
5. Site works for some people only: almost always caching or duplicate records.
6. Outgoing mail lands in spam: SPF, DKIM or DMARC records missing after a DNS change.

Work out which category you are in before editing, because the wrong guess adds a second fault on top of the first.

A short pre-flight checklist for any domain change

• Export the full current DNS zone and save it outside the website.
• Lower TTLs a day or two ahead if you are planning a migration.
• Recreate every record at the new provider before switching.
• Schedule the change for a quiet period, never a Friday evening.
• Immediately after, test the website on two networks and send a test email to and from the domain.
• Keep the old server running for at least a week so late traffic still finds something.

Audit your domain before the next change

Open your registrar and DNS panel today and check four things: the expiry date, who can log in, whether MX records are present, and which subdomains still exist. Fixing those calmly takes half an hour, while fixing them during an outage takes a day. If you would rather have the domain, DNS and hosting managed together with a documented record of the zone, our team can take that on alongside your hosting.

Frequently asked questions

Why did my email stop after changing web hosting?

Almost certainly because the nameserver change moved DNS to a new zone that did not contain your MX records. Recreate the MX and mail-related TXT records exactly as they were.

How do I find out what my DNS records were before the change?

Ask the previous DNS provider for the zone export; many keep it briefly after a switch. Your mail provider can also supply the correct MX, SPF and DKIM values for reconstruction.

Who really owns my domain?

Whoever controls the registrar account, regardless of who paid. If an agency registered it for you, ask to be made the account owner or to transfer the domain into your own account.

Is it risky to delete DNS records I do not recognise?

Yes, some are verification or mail records that look meaningless. Note the value, disable or comment it if the panel allows, and confirm with your mail and hosting providers before deleting permanently.