When a website stops opening or business email stops arriving after a hosting change, start with the records responsible for that service. Changing every DNS value at once makes the problem harder to diagnose and can interrupt services that still work.

Collect the expected configuration first

Ask your hosting provider for its current website target and your email provider for its required mail records. Save a screenshot or export of the existing DNS zone. Note which service changed and when. Never assume the website and email use the same provider.

Run a DNS lookup

  1. Open the DNS Lookup tool.
  2. Enter the hostname without a protocol or page path. Check the root domain and the www hostname separately.
  3. Select A or AAAA for address records, MX for mail routing, TXT for published text records, or NS for nameservers.
  4. Run the check and compare the response with the provider's instructions. Save the result before editing the zone.

Match the record to the problem

A records map names to IPv4 addresses; AAAA records map them to IPv6 addresses. MX records identify mail servers. TXT records can carry verification and email-policy information. A CNAME points a name to another name. NS records identify authoritative nameservers. These functions are different, so deleting an unfamiliar record can damage an unrelated service.

Example: the website works but email does not

Imagine you moved the website to a new host and replaced the entire DNS zone with its default values. The site opens, but messages no longer arrive. Compare the MX records with the email provider's settings. Restore its specified mail records and check any required verification values. Do not replace them with the website server's address unless the email provider explicitly requires that setup.

Next, send a test from an external mailbox and check the provider's delivery logs. A correct-looking MX response does not prove that the mailbox exists, that authentication is configured, or that a message will escape spam filtering.

Make one controlled correction

  • Confirm that you are editing the authoritative DNS service, rather than an unused zone at a previous host.
  • Change only the records needed for the affected service.
  • Keep a record of the previous value and the new value.
  • Recheck after caches have had time to expire. Different resolvers can temporarily report different answers.

Know when the problem is elsewhere

If the expected records are present but the site still fails, inspect the HTTP response and hosting configuration. If email still fails, investigate the account and delivery logs. A DNS tool shows published records, not a complete diagnosis of a website or mail system. For a planned migration, agree the website and email cutover together in your website project brief.

Example: diagnosing email delivery after a domain change

For a company domain such as example.com, check the MX records first to identify the advertised receiving mail servers. Next review SPF, DKIM and DMARC at the appropriate hostnames. An MX record answers where incoming mail should go; it does not prove that the mailbox exists or that its SMTP settings are correct.

After a migration, query the authoritative nameservers and compare results with the expected configuration supplied by the email provider. DNS changes can take time to propagate because resolvers cache records. Avoid removing existing mail-related records until you understand their purpose.

Sources and further reading

Turn the next step into a project

Need help with a brand identity, business website or launch assets? Explore SOPIDOTECH services and client projects, or discuss your brief.

Keep learning