Connect a domain to hosting without losing existing email

Separate the domain, DNS and website hosting

A domain registration gives you control of a name. DNS records describe destinations for that name, while hosting runs the website. These services may be managed in different accounts. You need access to the authoritative DNS configuration to connect an existing domain to a new website environment.

Entering a domain in the VPSLibre configurator records the name you intend to use. It does not register the domain, transfer it, change its nameservers or edit its DNS. Wait for the actual hosting destination and setup instructions before making a website cutover.

Identify the hosting environment behind your domain

Find the authoritative DNS and save the current settings

Check which nameservers your domain currently uses, then locate the account that manages that DNS zone. The registrar’s DNS editor may not be authoritative if the domain uses another DNS service. Record the existing website, email and verification settings before editing them.

Changing nameservers moves DNS management for the domain and can affect records beyond the website. If you only need to point a website to a new destination, follow the supplied record instructions rather than changing delegation unnecessarily. If delegation must change, prepare and verify the complete destination zone first.

Use the record type that matches the supplied destination

Use only the IP address or hostname actually supplied for your service. Decide how the root domain and the www name will behave, and configure the website to recognise the names visitors will use. A DNS record can reach a server without selecting the correct website on that server.

Review existing records for the exact name being changed. A leftover destination can send some requests elsewhere, especially when an old IPv6 record remains alongside a new IPv4 destination. Alias records also have restrictions on coexisting record types and root-domain use; follow your DNS service’s supported method.

Scroll the table horizontally if needed.

Preserve the domain’s existing email setup

Website records and mail routing have different roles. If your email stays with its current provider, retain its required MX and authentication records, including relevant SPF, DKIM and DMARC settings. Some configurations also depend on a mail hostname; review that hostname before changing an address used by several services.

Use the exact values from the email provider. Do not replace mail records with the website destination or delete verification records simply because they are unfamiliar. Pointing a website to hosting does not create mailboxes or establish a working outbound email service. Test existing mail separately after DNS changes.

Keep website and email changes separate during a move

Verify DNS, the website and HTTPS separately

After saving the intended changes, inspect the authoritative records and compare DNS answers from the networks you need to support. Cached answers can differ while earlier records remain cached, so an immediate result from one device is not proof of a complete cutover. Avoid promising a fixed worldwide propagation deadline.

Check that each intended hostname serves the right site. Then verify HTTPS has a valid certificate for those names and that redirects, forms and application URLs behave correctly. A correct DNS answer alone does not prove certificate issuance or renewal works. The checkout HTTPS preference records requested setup; confirm the delivered result.

• Check the root domain and www separately if both will be used.
• Compare IPv4 and IPv6 destinations where both records exist.
• Verify the certificate names and expiry in a browser without bypassing warnings.
• Check redirects and pages for resources still using an incorrect address.
• Test existing incoming and outgoing email with the email provider’s tools.

Check the web server and TLS after DNS is ready

Use the failed check to narrow down the problem

If DNS shows the old destination, confirm you edited the authoritative zone and consider cached answers. If it reaches the correct destination but displays another site, check the hosting-side domain assignment and application configuration. If HTTP works but HTTPS fails, examine the certificate and hostname configuration separately.

Keep a record of the changes and previous values so you can reverse the relevant edit if needed. When asking for help, provide the domain, failed hostname, time of the check and a non-sensitive description of the error. Share neither registrar credentials nor private keys. Keep the old hosting available until the intended website and related services have been checked.