Troubleshooting areaReviewed 2026-08-13By HostWithShery technical editorial

Troubleshooting Guides

Follow symptom-based repair guides for DNS changes, migrations, root/www problems, business email, indexing signals and provider configuration.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

Complete Website Health Check

This page is preconfigured with the Complete Website Health Check that best matches this problem.

No accountPublic evidence only
Live public check

Enter the domain only. We will test root + www, DNS, HTTPS, redirects, mail and crawler access.

No account · Public configuration only
On this page
Browse this section

Choose the symptom or change that matches your problem

Every important page in this area is linked here with a normal crawlable link, so you can choose by task instead of searching through a long generic list.

Website, DNS & migration symptoms

Website stopped working after DNS changeA DNS change can send visitors to the wrong server, remove a required record or expose a broken IPv6 endpoint.Open →Website not working after changing nameserversChanging nameservers replaces the authoritative DNS zone. Any website record that was not copied to the new provider stops being published.Open →Website works for me but not othersDifferent DNS caches, IPv4/IPv6 paths or regional routing can make the same domain behave differently for different visitors.Open →Website works on Wi-Fi but not mobile dataMobile and Wi-Fi networks can use different DNS resolvers and IP versions, exposing propagation or IPv6 problems.Open →Domain points to old websiteThe active A/AAAA/CNAME still leads to an old host or one network has cached the previous answer.Open →Domain points to parking pageDNS resolves, but the destination server is serving a registrar, host or default parking response instead of the intended site.Open →Website works without www but not with wwwThe www hostname usually has a missing/wrong DNS record, is not attached to the hosting platform, or is not covered by the certificate.Open →Website works with www but not without itThe apex/root record is missing, points elsewhere or is not attached to the site/certificate.Open →New website not showing after migrationA hosting migration can be complete while public DNS still points to the previous server.Open →DNS changed but old website still appearsA cached DNS answer or forgotten record—often AAAA—can continue sending some visitors to the old server.Open →Subdomain not workingThe subdomain needs its own A/AAAA/CNAME or platform mapping; the root domain working does not make every subdomain resolve automatically.Open →Website shows server IP instead of domainThe server or application is generating redirects/canonical URLs with the IP, or the virtual host is not configured for the requested domain.Open →Sitemap submitted but pages are not indexedA successful XML sitemap helps search engines discover preferred URLs, but sitemap submission does not guarantee crawling or indexing. First confirm that important pages are internally linked, crawlable, self-canonical and return useful indexable content.Open →

Business email & authentication

Email stopped working after changing nameserversThe new authoritative DNS zone is probably missing MX or mail-authentication records that existed at the previous DNS provider.Open →Email stopped after moving websiteMoving the website should not require moving email, but replacing DNS records or nameservers can accidentally remove the mail configuration.Open →Email works but website does notMail and web traffic use different DNS records, so healthy MX records do not prove the A/AAAA/CNAME and HTTPS setup is correct.Open →Website works but email does notThe website can be healthy while MX, SPF, DKIM or mail-host resolution is missing or wrong.Open →MX records missing after migrationMX records are often lost when a DNS zone is recreated for a website migration. The correct fix is to restore the mail provider’s records, not move the email service unintentionally.Open →SPF record missingA domain without SPF does not publish which sending systems are authorized. Add one policy that reflects the services that really send mail for the domain.Open →Multiple SPF records foundA domain should publish one SPF policy. Multiple v=spf1 records create an invalid evaluation state; merge the legitimate mechanisms into a single record.Open →SPF too many DNS lookupsSPF evaluation permits a limited number of DNS-query-causing mechanisms. Exceeding the allowance can produce a permanent error.Open →DKIM selector not foundDKIM cannot be tested without the selector used by the sender. Automatic guessing is incomplete; obtain the selector from the mail provider or message headers.Open →DMARC record missingA domain without _dmarc does not publish a DMARC policy or aggregate-report destination.Open →DMARC authentication failedDMARC fails when neither aligned SPF nor aligned DKIM passes for the message.Open →Email going to spam after domain transferA transfer or DNS move can preserve delivery but remove or weaken SPF, DKIM and DMARC, which damages authentication signals.Open →Google Workspace email not receiving messagesIncoming mail reaches Google only when the public MX configuration points to the Google Workspace service enabled for the domain.Open →Microsoft 365 custom-domain email not workingExchange Online requires the domain’s public DNS to match the records assigned in Microsoft 365.Open →Zoho Mail DNS records not workingZoho uses region-specific verification and mail records, so values should be copied from the tenant’s current Admin Console rather than from an unrelated example.Open →

Troubleshooting Guides: what this section covers

Troubleshooting Guides begin with a real symptom or change event—such as a nameserver move, site migration, root/www mismatch, mail outage or sitemap/indexing concern—and connect it to public evidence. Similar queries are consolidated when the diagnosis and repair path are the same.

Signals that matter for website and domain troubleshooting guides

The pages here interpret business-email DNS and mail authentication evidence through the following search tasks and configuration concepts. They are included because they help separate causes, not to repeat a keyword a fixed number of times.

  • Website troubleshooting guidesVerify website troubleshooting guides from the public Internet and compare it with the value the responsible provider says should be live.
  • Dns migration fixesVerify dns migration fixes from the public Internet and compare it with the value the responsible provider says should be live.
  • Email dns fixesVerify email dns fixes from the public Internet and compare it with the value the responsible provider says should be live.
  • Indexing troubleshootingVerify indexing troubleshooting from the public Internet and compare it with the value the responsible provider says should be live.

Which Troubleshooting Guides check to start with

Open the guide that matches what changed or what the user sees, then run the embedded focused diagnostic before editing configuration. If the symptom is unclear or several services failed together, begin with the complete website health check and follow the layer it isolates.

Diagnosis first, raw evidence second

The interface surfaces the highest-impact explanation and its confidence before raw protocol output. For website and domain troubleshooting guides, that means a visitor can see what probably failed and what to change while an advanced user can still inspect the DNS, certificate, header, resolver or provider evidence behind the conclusion.

What a repaired website and domain troubleshooting guides problem should look like

A useful guide ends with a verifiable public state rather than a generic checklist. The same record, redirect, certificate, mail route or crawler directive that demonstrated the failure should be rechecked after the smallest necessary change.

Validate the business-email DNS and mail authentication change

The public MX/authentication records should match the intended mail provider, required hostnames should resolve, and the relevant SPF/DKIM/DMARC check should no longer show the original failure. Re-run the same focused tool that exposed the problem so a dashboard status, cache or unrelated healthy signal is not mistaken for proof of the repair.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.