SSL, DNS, and Email Setup for New Hosting Sites
Start with the three records that affect launch day
Most support tickets on a new site are not about code. They come from an incomplete SSL, DNS, and email setup, or from waiting too long for DNS changes to settle. If you are launching on shared hosting, moving to a VPS, or handing a site over to a client, get these three pieces working before you announce the domain.
If you are still choosing the right plan, Hostperl’s shared hosting and Hostperl VPS options both suit this workflow. Shared hosting keeps the setup simple. A VPS gives you more room for custom mail, DNS, and control panel work.
- SSL keeps browser warnings away and protects logins.
- DNS points the domain to the right web and mail servers.
- Email makes the domain look professional and helps messages deliver reliably.
Prepare the domain before you change anything
Before you touch the website, log in to the registrar and confirm where DNS is managed. If the domain uses Hostperl nameservers, your record changes should happen where the zone is hosted. If DNS sits elsewhere, updating the wrong panel only creates delay.
Use a simple pre-launch check:
- Confirm the domain is unlocked and the contact email is current.
- Check the current nameservers with a lookup or the registrar dashboard.
- Make a note of the existing A, AAAA, MX, and TXT records.
- Lower the DNS TTL to 300 seconds a few hours before the move if you expect a cutover.
That TTL change does not make DNS instant, but it reduces how long stale answers stay in caches. For a new site, that difference is noticeable.
Set the web record first, then issue the certificate
Point the domain to the hosting account before you request SSL. In cPanel, Plesk, or DirectAdmin, the certificate tool usually checks domain ownership through DNS or the web root. If the A record still points to the old server, certificate issuance often fails or loops.
For a typical cPanel setup, open Domains and confirm the domain resolves to the server IP. Then use AutoSSL or the SSL/TLS status page. On Plesk, check Websites & Domains and run the SSL certificate action from there. On a VPS, make sure the firewall allows ports 80 and 443 before you test renewal.
If you want a cleaner domain path later, our rent IP address option is useful for customers who want to keep mail and web traffic separated in a more controlled setup.
Build the DNS zone without common launch mistakes
A good DNS zone is small and boring. That is a good sign. Use only the records you need, and avoid mixing old host values with the new server.
For a fresh website, these records usually cover the basics:
- A record for
example.compointing to the server IPv4 address. - CNAME for
wwwpointing toexample.comif your setup allows it. - AAAA only if the server has working IPv6 and the site is ready for it.
- MX records for mail delivery, if you host email on the same domain.
- TXT records for SPF, DKIM, DMARC, and any domain verification needed by your mail service.
Do not create duplicate A records for the same host unless you intend load sharing. Keep the zone tidy. When a client later asks why mail is delayed or the site opens on the old server, messy DNS is often the reason.
Issue SSL and force one clean version of the site
Once the DNS points to the right server, request the certificate. Then redirect all traffic to HTTPS. You want one canonical version of the site, not four variants that split cookies, analytics, and trust signals.
On Apache-based hosting, a typical redirect looks like this in .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]On Nginx, place the redirect in the server block that listens on port 80:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}If you are using a control panel, let it manage the certificate when possible. That reduces renewal mistakes. If you manage the server yourself, check your certificate paths carefully and make sure the renewal job runs before expiry. A broken renewal usually shows up as a browser warning on a Monday morning, which is the wrong time to learn about it.
Set up mail so it can actually deliver
Email is where new hosting setups fail most often. The mailbox may exist, but messages land in spam or bounce because the domain has no proper authentication. Start with SPF, DKIM, and DMARC. If you are on cPanel, the email tools usually expose these directly. If you are on Plesk or DirectAdmin, the wording changes, but the goal stays the same.
For a self-managed or VPS-based mail setup, check the following in order:
- MX records point to the correct mail host.
- SPF includes the right sending server or service.
- DKIM is enabled and publishing a valid public key.
- DMARC exists, even if it starts in monitor mode.
- The server hostname has forward and reverse DNS that match the mail identity where possible.
If you want a deeper walk-through, our SSL, DNS, and Email Setup Checklist for Hosting Customers covers the exact records to verify before go-live. For customers relying on VPS mail, the related email deliverability checklist for VPS hosting is worth keeping open while you test.
Test the setup from a real browser and a real inbox
Do not rely on one quick ping or a single login test. Open the site in a private browser window, then check both the root domain and www. If you see a certificate warning, a mixed-content alert, or a redirect loop, fix that before sharing the URL.
Then send and receive a few test emails. Use one mailbox inside the new domain and one external mailbox such as Gmail or Outlook. You are checking three things at once: whether the mail leaves, whether it arrives, and whether replies come back to the right place.
Try this small validation list:
- Website loads on HTTPS without warnings.
wwwredirects to the chosen canonical host.- Incoming mail reaches the mailbox within a few minutes.
- Outgoing mail includes the correct display name and signature.
- Spam score stays low on a sample message.
Fix the most common launch-day issues quickly
When something breaks, start with the simplest layer. Most issues are either DNS, certificate, or mailbox configuration problems. You do not need a full rebuild.
If the site still shows the old server: check the A record, the TTL, and your local DNS cache. Try the domain on a different network or with a public resolver after flushing your device cache.
If SSL will not issue: confirm the domain resolves to the new server, port 80 is open, and no redirect is blocking the ACME check. If the site is behind another proxy, disable that path until the certificate is live.
If mail bounces: compare the MX records with the actual mail host, then inspect SPF and DKIM. A valid mailbox does not help if the domain advertises the wrong sender.
For control panel buyers comparing options before they settle on a stack, these guides can help: cPanel vs Plesk and cPanel vs DirectAdmin. The right panel makes DNS and email less painful for your team.
Keep the setup stable after launch
After the site is live, do one more pass the next day. Recheck SSL expiry dates, inspect the DNS zone for unwanted changes, and confirm that outbound email still passes authentication. Many problems appear only after caches expire or the first scheduled renewal runs.
If this launch is part of a move from shared hosting to a larger platform, Hostperl can help you plan the next step without redoing the same work twice. Our safe server move guide pairs well with this checklist, and our managed VPS hosting is a sensible fit when you want more control over DNS, SSL renewals, and mail services.
If you want a launch that does not turn into a support thread, Hostperl can help you choose the right hosting path from the start. For sites that need simple management, choose shared hosting; for custom DNS, mail, or app control, start with Hostperl VPS.
Our team works with real migrations, DNS cutovers, and SSL renewals every day, so you are not left guessing when a record or certificate needs attention.
FAQ
How long should I wait after changing DNS?
For most launches, check again after 15 to 30 minutes, then keep monitoring for up to 24 hours. Lower TTL values help, but some resolvers cache longer than expected.
Should I issue SSL before or after changing nameservers?
After the domain points to the new server. SSL tools usually verify the live destination, so the certificate step is far less likely to fail once DNS is aligned.
Do I need separate mail hosting for a new website?
Not always. Shared hosting often includes mail that works well for small sites. For heavier email use, a VPS or dedicated setup gives you more control over reputation and routing.
Why does my site load but email still fails?
Web and mail depend on different records. The A record can be correct while MX, SPF, or DKIM are still pointing to the old host or missing entirely.
