What to check after moving hosting: email, SSL, redirects and forms
Updated 6 min readBy the DNSPeek team
Right after a hosting move, confirm that DNS points at the new server everywhere, that a valid certificate is installed, and that redirects still go from HTTP to HTTPS and to one canonical hostname. Then check email delivery (MX, SPF, DKIM and DMARC), contact forms, scheduled tasks and the search engine settings. Most post-migration problems fall into one of these groups and are quick to fix once found.
DNS: is everyone on the new server?
Check that the domain and www resolve to the new IP from public resolvers worldwide with the DNS propagation checker, and that the site actually answers there with Is my domain switched?. An old AAAA (IPv6) record is the classic leftover: IPv6 visitors keep reaching the old host and see stale content.
If you moved DNS to another provider, compare the old and new zones with DNS compare. A missing TXT or CNAME record breaks things quietly: domain verification for Google or Microsoft, email signing, or a subdomain used by a third-party service.
SSL certificate
Many hosts issue the certificate only after the domain points at them, so check it once DNS has moved. The SSL checker shows the issuer, expiry date, the names the certificate covers and whether browsers trust the chain. Make sure it covers both example.com and www.example.com, and any other hostnames you serve.
If you tested with a DNSPeek preview link in Skip verification mode, switch it to Verify after the move: the preview then fails on any certificate error, which is a quick confirmation. See SSL modes.
Redirects and headers
Server configuration does not always travel with the files. .htaccess rules do not work on nginx, and a new host may handle www differently. Run the redirect checker on your domain: http:// should reach the final https:// page in one or two hops, with permanent (301 or 308) redirects and no loop.
Then run the security headers check. HSTS, Content-Security-Policy and similar headers are set by the server or CDN and are easy to lose in a move. Compare the grade with what you had before.
Email: MX, SPF, DKIM and DMARC
Email is where moves go wrong most quietly: the website looks fine, and nobody notices for days that mail is bouncing or landing in spam.
| Record | What to check | Tool |
|---|---|---|
| MX | Points at the mail provider you actually use; mail did not follow the website by accident | MX lookup |
| SPF (TXT) | Lists every server that sends mail for the domain, including the new web server if forms send directly; one SPF record only; no more than 10 DNS lookups | SPF checker |
| DKIM (TXT or CNAME) | The signing key records of your mail provider exist in the current zone | Your mail provider’s admin panel |
| DMARC (TXT) | A _dmarc record exists, with the policy you intend | DMARC checker |
Then send a real test: write to a mailbox on the domain from an outside address, and reply. If mail was hosted on the old server, check that messages received during the switch were copied over.
Forms and transactional email
Contact forms, password resets and order confirmations often send mail from the web server itself. On a new server, PHP mail() may be disabled, port 25 may be blocked (common on cloud VPS), or the new IP may not be in SPF. Submit every form and trigger a password reset. If messages do not arrive, send through an authenticated SMTP service instead of the server’s local mail.
Application, cron jobs and integrations
- Cron jobs and scheduled tasks: backups, feeds, cache warmers and newsletter queues. Recreate them on the new server and check that the old server no longer runs them, or they will run twice.
- IP allowlists: payment gateways, APIs, firewalls and remote databases that only accept the old server’s IP.
- Webhooks: services that call your site, such as payment providers, keep working through DNS, but check their delivery logs for errors around the switch.
- File permissions and uploads: upload an image or a file through the CMS.
- Caching: clear page caches and CDN caches so visitors do not get pages built on the old server.
Search engines and analytics
A staging setting carried over can hide the whole site from search. Look for a noindex robots meta tag or X-Robots-Tag header, a robots.txt that disallows everything, and canonical URLs that point at a temporary host. Check that the analytics tag still fires and that the sitemap is reachable. A DNSPeek QA report flags these search-engine leftovers, along with broken pages, missing files and mixed content.
Let the checks run themselves
If you tested the new server with a DNSPeek preview link before the switch, turn on DNS propagation alerts for it (paid plans). When the domain has propagated, DNSPeek re-runs the QA report on the live domain and compares it with the last report from before the switch: pages that broke, redirect somewhere else or lost their title. See After the DNS switch.
The post-move routine
Step 1: Confirm DNS has moved
Check the domain and www from public resolvers and confirm the site answers from the new IP.
Step 2: Verify the certificate
Check issuer, expiry and hostname coverage with the SSL checker.
Step 3: Test redirects and headers
Follow
http://to the final page with the redirect checker and compare security headers with the old setup.Step 4: Check email records and send a test
Look up MX, SPF and DMARC, confirm DKIM in your mail provider, then send and receive a test message.
Step 5: Submit every form
Send each contact form and a password reset, and confirm the emails arrive and are not marked as spam.
Step 6: Check scheduled tasks and integrations
Recreate cron jobs, update IP allowlists, check webhook logs and clear caches.
Step 7: Check search settings and keep the old host briefly
Remove staging noindex rules, confirm robots.txt and the sitemap, and keep the old hosting until its logs show no more visitors.
Post-migration checklist
After the move
- Domain and www resolve to the new IP worldwide
- Old AAAA record updated or removed
- All records present in the new DNS zone
- Valid certificate for every hostname
- http → https and www handling in one or two permanent redirects
- Security headers same as before, or better
- MX correct, test email sent and received
- SPF includes every sending server, one record, 10 lookups or fewer
- DKIM and DMARC records present
- Every form and password reset email delivered
- Cron jobs recreated; none left running on the old server
- IP allowlists updated for the new server
- No noindex, robots.txt allows crawling, canonical URLs correct
- Caches cleared, analytics firing
- Backups configured on the new host
Frequently asked questions
Why did my email stop working after changing hosts?
Usually the MX records pointed at the old host, or the DNS zone was moved without them. Check MX first, then SPF, DKIM and DMARC. If mail was stored on the old server, messages that arrived during the switch may still be there.
Why do my contact form emails go to spam after a move?
The new server sends mail from an IP that is not listed in your SPF record, without DKIM signing, or from a cloud IP with a poor reputation. Send form mail through an authenticated SMTP service and add it to SPF.
How soon after a move should the SSL certificate work?
Within minutes of DNS reaching the new server on most hosts with automatic certificates. If it has not appeared after an hour or two, check that every hostname points at the new server and ask the host to issue it.
Do redirects move with my website files?
Only if they live in files the new server reads. Rules in .htaccess work on Apache and LiteSpeed but not on nginx, and redirects set in the old host’s panel or CDN stay behind. Test them with a redirect checker after the move.
When can I cancel my old hosting?
When DNS has propagated, the old server’s access logs show no more real visitors, mail no longer arrives there, and you have a final backup. Waiting a few days after the switch is a safe default.