Treat the web and mail paths as connected until checked
Check where MX, its target and SPF mechanisms lead before changing a web address; an unchanged MX value alone cannot protect mail.
A web move may change A, AAAA or a provider-directed alias while leaving the mailbox provider in place. First trace MX targets, any no-MX fallback to the apex, SPF a or mx mechanisms, and form mail sent by the old host. An unchanged MX label alone does not protect those dependencies.
This guide covers a web-only cutover. The domain owner controls the authoritative DNS provider and the application owner controls form mail. Use the actual new hosting target supplied for the site; no example IP is a Novasean target.
Trace MX targets and sending dependencies
Write down the current apex and www A, AAAA and CNAME answers, TTL, nameservers and new provider target. Record MX targets and priorities, then resolve every MX target to its A/AAAA address. If an MX points to example.com or another hostname whose address you intend to replace, stop: inbound mail may move to the new web host. If no MX exists, RFC 5321 permits an implicit MX to the domain itself; changing the apex address can change attempted inbound delivery. Ask the mail operator to establish an explicit, correct mail route before the web move.
Inspect SPF at the actual sending domain for a or mx mechanisms tied to these names; changing an address can change which server passes SPF. Inventory DKIM, DMARC and mail-client hostnames as a preservation check, even though a web-only edit should not replace them. Ask the application owner how forms, notifications and scheduled jobs submit mail. A form that currently uses local sendmail may require an approved SMTP route on the new host.
Prove the new site before a public DNS edit
Use an approved preview method with the real hostname to test the new site, HTTPS, key pages and forms without changing public DNS. The migration-preview guide explains that test. Confirm that both apex and www are configured on the new host and covered by the intended certificate. Save the old record values and a rollback route. If mail dependencies remain uncertain, do not cut over on the assumption that the MX text looks unchanged.
If the DNS provider supports it, lowering the web record TTL in advance can shorten later cache overlap, but existing caches retain their earlier TTL. Arrange a period when the old and new web services can both serve visitors while answers diverge.
Change only the verified web records
At the authoritative DNS provider, replace the relevant apex or www web record with the exact provider-supplied target. Publish an AAAA record only if the new site actually serves that assigned IPv6 target. A CNAME choice at the apex depends on the provider’s supported flattening or alias feature and other records at that name; do not replace apex MX/TXT records with an ordinary incompatible CNAME. Check the panel’s final hostname preview and retain unrelated MX, mail-host A/AAAA and TXT records.
Query a delegated server directly, for example dig @ns1.provider.example example.com A +noall +answer, replacing the illustrative server. Query A and AAAA for each web name and MX plus its target addresses for mail. Then compare ordinary resolver answers as old TTLs expire.
Test both website and mail
Visit the apex and www from an ordinary connection and check HTTPS, redirects and the main application tasks. Send an external message into a representative mailbox and verify arrival at the existing mail provider. Send a reply or application-generated test message, inspect its authentication result and confirm the form actually delivered rather than merely displaying “sent”. Different senders can cache DNS differently, so continue observing the overlap period.
For a domain whose MX target is mail.example.com, confirm that this name still resolves to the mail service after the apex web change; then test an external inbound message.
If the site fails, restore the recorded web record after checking whether the new target or certificate is wrong. If mail fails, compare the MX and target-address answers and the sending path before changing another record. Rolling back the apex may repair an accidental implicit-MX or shared-target change, but cached answers can persist; involve the mail operator and keep both hosts available. Share timestamps and redacted results, never passwords.
Common questions
Is unchanged MX enough to protect mail? No. Resolve its target and check no-MX fallback and SPF dependencies.
Does a website move require changing nameservers? Usually a web record at the current authority is enough.
Why is the contact form broken while mailbox delivery works? The form’s outgoing mail route is a separate application dependency.
Does leaving MX untouched keep application mail working? No. Check the form or application's actual outgoing sender separately.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.