Use the smallest necessary DNS change, preserve the full mail dependency chain and verify both website and email; no zero-downtime promise.
Connecting a domain to a new website does not require moving its email. Find where DNS is managed, keep the mail configuration intact and change only the website records the new platform requires. If you must change nameservers, prepare the complete replacement zone first.
Before changing anything
You need authorized access to the domain account and its current DNS service, the new website’s exact instructions, and the existing email provider’s settings. Do not guess an IP address or use records from an unrelated tutorial. Ask the person who runs the mailbox service to review the proposed change when business email is critical.
Our example is a business with a new website but an unchanged mailbox provider. This is a planning example, not an account we migrated. The safe objective is narrow: make the website resolve while preserving incoming and outgoing email.
1. Identify and record the current configuration
The registrar sells the domain; its nameservers indicate the authoritative DNS provider, which may be a different company. Editing an inactive DNS panel will not change the live records. Record the current nameservers and export or securely capture the active zone, including record names, types, values and priorities.
| Record or dependency | Why it matters |
|---|---|
| MX | Directs incoming mail to the existing mailbox service. |
| Mail host A/AAAA | A server name used by MX may depend on its own address record. |
| SPF, DKIM and DMARC | Support authentication for authorized sending services. |
| Verification and other service records | Can belong to services unrelated to the new website. |
Keeping an MX record alone is insufficient if its destination is a name whose address you change. A mailbox on the old hosting server may need a separate email migration if that hosting is cancelled. Confirm the mailbox actually remains available.
2. Decide between pointing and moving DNS
Prefer changing only the required website records when the new platform supports that approach. It leaves the existing DNS and email arrangement easier to reason about. Moving nameservers can be appropriate when a platform requires it, but then the new DNS service must contain every necessary record before delegation changes.
Before changing nameservers, check DNSSEC and the registrar’s DS records. A DS record tied to the previous DNS provider can cause validation failures even when the replacement zone is correct. Follow both providers’ current migration instructions and verify the final DNSSEC state. Our domain transfer checklist explains the distinction between changing DNS and changing the registrar.
Namecheap’s guidance warns that existing records do not automatically transfer between its DNS arrangements. Treat any provider’s record discovery as a convenience to verify, rather than proof that the full zone was copied.
3. Apply the platform’s exact website records
Check both the root domain and www. The platform may require A/AAAA records, a CNAME or a provider-specific alias arrangement. A conventional CNAME at the root can conflict with other records; Namecheap documents its own ALIAS alternative. Do not generalize that button or syntax to another DNS service.
Leave unrelated mail records unchanged. If the platform proposes new email settings, distinguish a website connection from a mailbox migration. Do not add a second independent SPF record simply to make a setup wizard turn green; ask the email provider how the authorized senders should be represented.
4. Verify the outcome from both directions
- Open the root domain and www in a browser and check the intended website and HTTPS.
- Send a message from an unrelated mailbox to an existing business address and confirm receipt.
- Reply to that external mailbox and check delivery and the expected sender identity.
- Test important aliases and website contact-form delivery separately. A working inbox does not prove a form can send.
- Compare the active DNS zone with your inventory and investigate unexplained changes.
If the website or email stops working
Return only the changed records to their recorded values or restore the previous delegation when appropriate. Cached DNS can make recovery gradual; an immediately successful browser check is not a universal propagation measurement. Keep the previous service active until verification is complete, and ask the provider about errors rather than making successive guesses.
Before choosing a registrar, review who should control the account. Website convenience should not require surrendering control of the business address or email.
Our DNS rehearsal: change the website, preserve the mail records
On 8 October 2026, we ran 13 DNS queries with Node v24.19.0 against a deliberately fictional .test zone on this computer. A dedicated resolver used a temporary server on 127.0.0.1. The addresses below are documentation examples, recorded as data and never used as connection targets.
| Scenario | Observed DNS result |
|---|---|
| Initial zone | Website A: 192.0.2.10. MX: priority 10 to mail.example.test; mail host A: 192.0.2.25. TXT: v=spf1 ip4:192.0.2.25 -all. |
| Website-only change | Website A becomes 198.51.100.20. MX priority and destination, mail host A and the TXT value stay unchanged. |
| Removed-MX control | The same name returns NOERROR with no MX answer and an authoritative SOA: NODATA. A separate nonexistent name returns NXDOMAIN. |
NODATA and NXDOMAIN describe different DNS states. Missing explicit MX is not proof of failed delivery: SMTP can use an implicit destination. Unchanged TXT text is not proof of unchanged effective SPF: an SPF a mechanism depends on address records. Our fixture uses an explicit ip4 value and does not evaluate SPF.
We logged datagrams at our own endpoint; this was not an independent packet capture. The 300-second record and negative-answer TTLs are fixture values, not worldwide propagation measurements. We did not test SMTP, inboxes, aliases, provider accounts, DNSSEC, delegation or production.
For a real domain, make the smallest change and inventory the full mail dependency chain. A preserved MX record is insufficient if its destination address changes. Reconfirm your provider’s exact values and test incoming and outgoing mail separately.
Costs alongside this guide
Existing owners can follow the DNS steps without buying a new service. These costs apply only if you need a separate purchase.
Business mailboxes
Fastmail · Standard — annual
- Initial term & commitment
- Initial term amountUS$60.0012 months termUS$5.00per user per month equivalent; 12 months prepaid
- Renewal
Taxes excluded
Price observed 2026-10-16
Plan details & sources
Custom-domain business mail with third-party email apps.
50 GB mail/calendar/contacts and 10 GB files per user; domain registration costs separate.
Choose another option if: You need the larger Professional storage allocation or configured retention archive.
United States USD public pricing reference · Taxes excluded
Published 12-month prepaid total per user; tax excluded.
Renewal: Future renewal amount and invoice term not confirmed.
Taxes excluded
Prices checked 2026-10-16Official price source ↗Observed 2026-10-16
Official price evidence ↗Recorded prices can change. Check eligibility, taxes and the current full bill with the provider. Different currencies and services are shown separately.
Sources and verification
Editorial review 2026-10-09. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Namecheap host recordsChecked Website and email record types; CNAME at the apex requires care.
Limits: Namecheap ALIAS and panel instructions are provider-specific. - Namecheap nameserver changesChecked Existing records are not automatically copied when changing DNS systems.
Limits: Propagation times are estimates, not a universal deadline. - Microsoft 365 external DNS recordsChecked MX routes mail; SPF, DKIM and DMARC support sender authentication.
Limits: Use the values of the actual email provider, not generic Microsoft examples. - RFC 2308: negative DNS answersChecked NODATA differs from NXDOMAIN; authoritative negative answers carry SOA data and use the lower of SOA TTL and SOA.MINIMUM for negative caching.
Limits: These protocol rules do not measure public resolver caches or worldwide propagation. - RFC 5321: SMTP destination resolutionChecked When explicit MX records are absent, SMTP can use an implicit destination at the domain and resolve its address.
Limits: The local DNS experiment does not run SMTP or establish whether a real message is delivered. - RFC 7208: the SPF a mechanismChecked The SPF a mechanism depends on address records, so unchanged TXT text does not guarantee an unchanged effective policy.
Limits: Our fixture preserves an explicit ip4 TXT value; it does not evaluate SPF or a real sending service. - RFC 6761: test namesChecked The .test suffix is reserved for private testing with an explicitly configured test resolver.
Limits: A fictional .test zone is not a registered domain, live delegation or provider configuration. - RFC 5737: documentation IP addressesChecked The example IPv4 addresses belong to documentation-only TEST-NET ranges.
Limits: They appear only as DNS record data and are never connection targets in this experiment. - Cloudflare: transfer a domain and prepare DNSSECChecked DNSSEC signatures and DS data tied to the previous DNS provider can cause resolution failures after a nameserver change.
Limits: Cloudflare-specific migration instructions; do not generalize its DNSSEC disablement procedure to every registrar-only transfer.