Assign the domain to the intended Premium project, change only its required website records at the authoritative DNS provider, and preserve the email service and its complete DNS dependencies unless a separate mail migration is intended.
You can connect a domain you already own to a Webnode website while keeping email with another provider. Treat the website address, domain registration, DNS and mailboxes as separate services. Connecting the website does not require moving every service at once.
This guide uses official documentation checked on 13 October 2026. The change plan and examples are editorial recommendations, not results from a live migration. Use the DNS records shown for your own project and the instructions for your existing email service; there is no universal set of values to paste.
Choose connection rather than an unnecessary transfer
Webnode supports assigning an existing domain without transferring its registration. Custom-domain use requires an active Premium package for the project. See the official domain-assignment instructions and Premium explanation. Premium applies to one website, so upgrading another project does not automatically cover this one.
A registrar transfer changes who manages the registration. Pointing a website changes where visitors reach the site. You can choose the second task first, then consider the first later. Keeping a familiar registrar and a working mail provider may be preferable when the immediate goal is simply to publish a new brochure site.
For example, a repair business has a domain at a registrar and two working mailboxes with an email host. It has built a replacement site in Webnode. Its change request should say: connect this domain to this project; preserve the two mailboxes and the current email provider. It should not say: move everything, unless that is the intended project.
Record what works before changing it
Prepare a small change sheet. Record the registrar, the service operating the authoritative DNS, the mail provider and the Webnode project. These may be four different places. Editing a DNS panel that does not control the active nameservers will not update the public domain.
- Save the existing DNS zone using the provider’s export option, or record the current entries and values in a private change log.
- Identify website records for the main domain and www, plus other subdomains that must remain available.
- Identify all mail-related records, including MX priorities, email verification and authentication entries, and any hostname on which the mail service depends.
- Confirm you can sign in to the registrar and email administration. Use a recovery address that remains available if the domain has a problem.
- Record a working website page and confirm that the current mailbox can receive and send an ordinary message. This provides a meaningful baseline.
Do not cancel the old hosting bundle simply because the website is moving. That bundle may also provide the mailbox or DNS service you intend to retain. Establish which separate services would end when you cancel it.
Understand which records are changing
Webnode’s DNS reference distinguishes the main record types. This table is a planning aid and contains no production values.
| Record or setting | What to check |
|---|---|
| A or website CNAME | Use the project-specific destination for the website hostname. An address from another Webnode project may not be suitable. |
| MX | Keep the existing mail provider’s required destinations and priorities when email is staying there. |
| TXT and mail authentication | Preserve relevant verification, SPF, DKIM and DMARC settings according to the mail provider’s instructions. |
| Mail hostnames | Check whether a mail server name depends on an address record that a website change might overwrite. |
| Nameservers | Changing nameservers moves authority for the whole DNS zone. This is a larger change than updating website records in the current zone. |
An important edge case is an MX destination that depends on a hostname whose address you are replacing. Leaving the MX row untouched would not necessarily preserve delivery. Ask the email provider to confirm the complete dependency rather than checking only whether an MX entry still exists.
Add the domain to the correct project
- Open the intended website project and confirm its Premium status. Check the project name before choosing a domain.
- In the editor, open Settings, then Domains and Manage domains. The documented route includes Transfer your domain; use the explanation for connecting without transfer on that screen.
- Enter the existing domain and choose Add domain. Webnode displays the records for that project.
- Compare the displayed website changes with your saved zone. At the active DNS service, change only what the connection requires.
- If email is staying elsewhere, preserve its working configuration instead of replacing it with the optional Webnode email records.
These labels follow the current Webnode guide. If the interface differs, consult that guide for the project instead of guessing at an equivalent button. If your registrar is separate from your DNS service, apply the changes at the authoritative DNS provider.
Verify the website and email separately
After the records update, return to the project’s domain management and refresh its status. Set the verified domain as the primary address using the primary-domain guide.
Check the main domain and www in a fresh browser session, then open an inner page. Confirm that you see the intended project and the address you want to publish. A successful homepage alone does not prove that old links, images or contact routes work.
Test receipt from an unrelated mailbox and send a reply. Check the mailbox directly and in any mail application you normally use. If you use forwarding or a website form, test those paths separately; receiving one ordinary email does not prove them.
Webnode describes automatic HTTPS deployment within 24 hours of successful verification when DNS is correct, and identifies conflicting AAAA records as a possible verification problem. Treat these as diagnostic guidance, not a promise that every migration finishes at the same minute.
Diagnose the symptom before changing more records
- If the old website still appears, confirm the active DNS service and the hostname being tested. Mail settings do not solve a website-address problem.
- If domain verification fails, compare the required records with your project’s instructions and check conflicting website destinations.
- If the website works but incoming mail fails, compare the mail-related zone with the saved baseline and the email provider’s requirements.
- If mail arrives but replies fail or are rejected, inspect the sending service and its authentication instructions. Replacing MX repeatedly is not a useful response to every sending problem.
- If HTTPS still fails after the documented verification interval, contact Webnode with the domain and status rather than disabling secure access.
Log each change and its time. Changing several unrelated settings at once makes the cause harder to identify. For a serious interruption, use the saved baseline with the relevant provider to decide whether to restore a changed record or complete a missing dependency.
If registration or email is also moving
Make that a separate decision. Webnode’s transfer guidance tells customers keeping external email to notify support and supply their MX records during a transfer. Moving mailboxes requires preparation, including preserving messages: changing DNS does not copy mailbox history.
Read our domain-transfer checklist if registration is moving, or the custom-domain guide for free builders before choosing a subscription. When replacing an existing builder, prepare your content with the export-before-cancelling guide.
Webnode is worth considering when its hosted editing workflow fits the site and the selected package covers the required domain connection. Keep a working email provider when there is no clear reason to migrate it. Compare the actual project requirements before buying or changing services.
Sources and verification
Editorial review 2026-10-19. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Webnode: assign a domain using DNSChecked Assignment without transfer, project-specific records, optional mail records and verification.
Limits: No account-specific DNS values or live cutover observed; timing is provider guidance. - Webnode: what Premium includesChecked Own-domain requirement and Premium applied to an individual website.
Limits: No checkout price verified; project requirements determine the package. - Webnode: DNS record settingsChecked Record roles, external email requirements and TXT verification.
Limits: Its editor steps apply to Webnode-managed DNS; example values are not production settings. - Webnode: set a primary domainChecked Primary-domain selection.
Limits: Does not verify this reader’s redirects or old URL migration. - Webnode: domain transfer basicsChecked Separate transfer workflow and preserving external mail configuration.
Limits: Transfer is outside the main connection workflow; no universal fees or delivery guarantee.