After a DNS change, a website and business email can fail for different reasons even though they share a domain. Work out whether nameservers changed, individual records changed, or both. Keep a copy of the previous zone and note the time of each edit.
Find where the domain’s live DNS is hosted. Records left at a previous provider do not affect visitors after nameservers move. Compare the active zone with the old copy, including website, mail and verification records. Correct missing records at the authoritative provider before waiting for caches to update. Check that the zone belongs to the correct domain.
Inspect A, AAAA and CNAME answers for root and www. Confirm they reach the intended server and HTTPS has a certificate for the requested name. If the site redirects repeatedly, compare hosting, WordPress and proxy rules rather than changing unrelated DNS records. Test an internal page as well as the homepage.
Compare public MX records with the mail provider’s required values. Review SPF, DKIM and DMARC for outgoing mail. A successful website test does not confirm inbound mail works. Send a labelled external message and reply, then inspect any non-delivery report. Confirm that form notifications still reach the correct inbox.
A resolver may use an old answer until TTL expires. Compare the authoritative answer with several public resolvers and another network where useful. If the authoritative answer remains wrong, propagation is not the explanation. Avoid repeatedly changing values while old answers are circulating.
Website forms, transactional mail, analytics, payment callbacks and verification records may rely on the domain. Test paths the business uses and record results. Keep old hosting available until the new site, email and forms are confirmed on the public domain. Make changes in a controlled order and retain a rollback record.
Related: DNS and hosting support and DNS propagation explanation.