How to Point a Domain to a VPS: DNS A Records, CNAME vs A, and Propagation

CodexFuse Team · 2026-11-06T09:15:22.988Z · 28 min read min read

How to Point a Domain to a VPS: DNS A Records, CNAME vs A, and Propagation

Learning how to point a domain to a VPS is the step that turns a server IP address into a real website. You add two small DNS records, wait for the change to spread, and then your domain opens the site running on your server. The whole job takes about five to ten minutes of actual work, according to VPS.us, and the waiting afterwards is the part that confuses most people.

This guide walks through the full beginner arc in one place. You will find where your DNS is managed, add the two A records your domain needs, choose between a CNAME and an A record for www, check the result with dig, and understand how long DNS propagation really takes. Everything here was checked against the providers' own documentation and current guides on 6 November 2026, and every worked number was computed from those published figures.

If you are setting this up on rented infrastructure, the server underneath is almost always a virtual private server, and the guide below assumes that setup throughout. If you are still choosing a server, start with our VPS hosting guide first.

How Do You Point a Domain to a VPS?

To point a domain to a VPS, add an A record for @ and a second A record (or a CNAME) for www at the provider that manages your domain's DNS, both pointing to your VPS IP address. Then delete any old records that point elsewhere, verify with dig, and wait for propagation. That is the whole job, and the five steps below are the complete version.

1. Find where your DNS is managed by checking your domain's nameservers.
2. Add an A record for @ and one for www, both with your VPS IP address as the value.
3. Delete old A and AAAA records for @ and www that still point at your previous host.
4. Verify the change with dig +short and a DNS propagation checker.
5. Tell your web server about the domain, then add a free SSL certificate.

Most of the guides on page one of Google cover the same five moves. Volyte's guide, published 19 October 2026 and updated 5 November 2026, follows exactly this arc, and Hostinger's tutorial covers the same ground with three methods: A record, Cloudflare, or custom nameservers. The difference in this guide is the honesty about the waiting: the old record's TTL decides how fast the change shows up, not the new one you just saved.

What Does "Pointing a Domain" Actually Mean?

Pointing a domain means telling the internet's phone book, the DNS, that your domain name lives at your server's IP address. A visitor types your domain, DNS looks up the A record, and the browser is sent to your VPS. Nothing about the domain itself changes, and no files move.

You are only updating an address listing.

That is why the job is small but easy to get wrong. If you edit the record in the wrong place, nothing changes. If you leave an old record behind, some visitors reach the old server and others reach the new one.

If you touch the wrong record type, your email can stop. Each section below prevents one of those mistakes, and none of them needs a control panel on the server itself.

To point domain to VPS correctly you only need to understand three record types. An A record maps a name to an IPv4 address. A CNAME maps one name to another name.

An MX record decides where email goes, and it has nothing to do with your website. Keep those three apart and the rest is typing. Our DNS beginner guide explains the full record system if you want the background first.

What Do You Need Before You Touch DNS?

You need three things before you start: your VPS IP address, a login to wherever your domain's DNS is managed, and about ten minutes. The IP address is in your VPS provider's welcome email and in its control panel, usually on the server information page. Hostinger's tutorial puts it the same way: open the VPS panel and copy the server IP address before you touch any DNS setting.

Copy the IP address exactly, digit by digit. A single wrong digit sends your domain to someone else's server, or to no server at all. If your provider gave you an IPv6 address as well, note it down separately; you will need it only if you decide to add an AAAA record, and for most first setups the IPv4 A records are enough.

Use documentation-range example addresses when you follow examples online. This guide uses 203.0.113.25, the example address Volyte uses in its tutorial, because it belongs to the 203.0.113.0/24 range reserved for documentation. Never copy an example IP from a tutorial into your own DNS records.

Your VPS IP is the one your provider gave you, and it is the only value that belongs in your A records.

The third thing you need is the answer to one question: how to connect domain to VPS when the domain and the server come from different companies. The answer is that it does not matter where you bought the domain or where the server lives. DNS is the meeting point.

You edit the records wherever the domain's nameservers point, and the next section shows you how to find that place.

Step 1: Find Where Your DNS Is Managed

Your DNS is managed wherever your domain's nameservers point, and that is the first thing to find. Open your registrar's domain page and look at the nameservers field. If they are the registrar's own nameservers, such as ns1.registrar.com, you edit DNS at the registrar.

If they say something like xxx.ns.cloudflare.com, you edit DNS in your Cloudflare account. Volyte states this rule plainly, and it is the single most useful sentence in the whole job.

You can check the nameservers from a terminal instead of trusting a panel. Hostinger's tutorial gives the command dig NS +short domain.tld, replacing domain.tld with your own domain. The output lists the nameservers currently in charge of your domain, and that list tells you where to log in and edit.

There are only a few places DNS usually lives. It lives at your domain registrar, at your hosting provider, at a DNS service such as Cloudflare, or at your VPS provider if you delegated the domain there. DigitalOcean's own documentation describes the delegation case: before adding a domain to DigitalOcean you delegate the domain to DigitalOcean's nameservers, ns1.digitalocean.com, ns2.digitalocean.com and ns3.digitalocean.com, and then you manage the records in the DigitalOcean panel under Networking, then Domains.

Do not start editing until you know which of these places is yours. The exact clicks differ from registrar to registrar, and Hostinger itself notes that the steps may differ depending on your domain registrar, so this guide gives the record values rather than a single click path that only works in one panel. Editing records at a provider that no longer controls your DNS changes nothing, and it is the most common reason a "finished" change never takes effect.

Step 2: Add the Two VPS DNS A Records (@ and www)

An A record connects a name to an IPv4 address, and your domain needs two of them. Add one A record for @, which means the domain itself, and one A record for www, both with your VPS IP address as the value. That pair is the standard answer in every current guide: Volyte, Domain India and Hostinger all list the same two records, and Namecheap's VPS guide describes the same single step as "creating an A record that connects the domain to your server".

To point domain to server IP you type the same IPv4 address into both rows. The @ row makes example.com open your server, and the www row makes www.example.com open it too. Skip the www row and the www version of your site simply will not resolve, which is a common beginner mistake that looks like a broken server but is only a missing record.

Some panels want the full name instead of @. Volyte notes that some panels want you to type example.com in the name field, and that is the same record with different labelling. Other panels leave the name field blank to mean the apex.

The value is what matters: your VPS IPv4 address in both rows, with nothing else.

For the TTL field, leave the default or pick 3600 seconds, which is one hour. Volyte recommends "Auto or 1 hour", and Cloudflare's own documentation says proxied records use an automatic TTL of 300 seconds while DNS-only records accept a custom value. Hostinger's tutorial shows 14400 seconds in its example table, which is 4 hours, but that is an example value in a tutorial, not a universal default.

There is no single default TTL across providers, so do not copy a number from a tutorial; use your own panel's default unless you have a reason to change it. The propagation section below explains when a lower TTL is worth setting on purpose.

If a record for @ or www already exists, edit it in place instead of adding a second one. Hostinger's tutorial describes it this way: find the existing A and CNAME records in the DNS zone and replace their values with your VPS IP address. Adding a duplicate alongside the old one is exactly the mistake the next-but-one section warns about.

CNAME vs A Record for a VPS: Which One Should www Use?

For www you can use either a second A record or a CNAME, and both work. A CNAME for www points at your domain itself, so www.example.com follows example.com wherever its A record points. Volyte puts it simply: instead of the second A record, you can use a CNAME with the name www and the value example.com, and either works.

The difference is what the record's value holds. A CNAME maps one hostname to another hostname, and its value is always a name, never an IP address. An A record maps a name directly to an IPv4 address.

That is why a CNAME adds one extra lookup hop: the resolver follows the alias to the canonical name and then looks up that name's A record. An A record answers in one hop but pins you to a specific address you must maintain yourself.

One rule is absolute, and it is not a preference. You cannot place a CNAME at the zone apex, the bare domain itself. The apex must carry SOA and NS records to define the zone, and the DNS standards forbid a CNAME from coexisting with any other record type at the same name.

The rule comes from RFC 1034 and is clarified by RFC 2181, and both who.is and a dev.to explainer on CNAME records state it the same way: a CNAME at the apex would be invalid DNS. If your panel refuses to save a CNAME for @, it is protecting you, not malfunctioning.

Cloudflare offers a workaround called CNAME flattening, and it is worth understanding because many people meet it by accident. With flattening, Cloudflare follows the CNAME itself and returns an IP address to the visitor instead of the target hostname. Its documentation gives a worked example: a CNAME for domain.test pointing at external-origin.test, where the target has the A record 192.0.2.1, produces the answer 192.0.2.1 for domain.test.

If the record is proxied, the answer is Cloudflare's own IPs with a TTL of 300 seconds. If it is DNS-only, the answer carries the lower of the two TTL values. Flattening is a provider feature, not a standard CNAME, and other providers sell the same idea under names such as ALIAS or ANAME records.

The cname vs a record vps choice therefore has a short answer. Use an A record for the apex, always. Use a CNAME for www when both names live on the same server, because then you only maintain one IP address.

Use an A record for www when it needs a different address. That covers every normal VPS setup.

Custom Nameservers vs A Records: Which Method Fits You?

Custom nameservers and A records are two different ways to reach the same result, and for most people the A record method wins. With A records, your DNS stays where it is today and you change two values. With custom nameservers, you move the whole DNS zone onto your VPS, which means installing and running a DNS server such as BIND, creating child nameservers like ns1.yourdomain.com, and then changing the nameservers at your registrar.

Hostinger's tutorial calls the nameserver method trickier for exactly this reason, and VPS.us puts numbers on the gap: A records take 5 to 10 minutes to set up, while custom nameservers take 15 to 30 minutes.

The setup-time gap is larger than it looks. Fifteen minutes against five is 3 times as long, and thirty against ten is also 3 times as long, so the nameserver method costs about 3 times the setup time at both ends of the range. That is before counting the ongoing work: a DNS server on your VPS needs maintenance, monitoring and patching, while records at your registrar or Cloudflare need none.

Nameservers do have real advantages. Hostinger's tutorial lists them: custom nameservers automatically match the DNS zone with your VPS IP address, so you do not reconfigure records when the IP changes, and they remove the provider's branding from your nameservers, which matters for agencies and resellers. They also make switching hosting providers easier, since your DNS zone travels with you rather than living inside a provider's panel.

Hostinger gives one clear decision rule: if your server IP address is static, use the A record method. A static IP never changes, so the A record's one weakness, that you must update it when the IP changes, never bites. Most VPS plans come with a static IP, which is why the A record method is the default recommendation in every guide on page one.

There is also a middle path that many people miss. You can delegate DNS to your VPS provider without running your own DNS server, for example by pointing your nameservers at DigitalOcean's ns1.digitalocean.com, ns2.digitalocean.com and ns3.digitalocean.com and managing records in their panel. Or you can leave the nameservers exactly where they are at the registrar and just add an A record there.

The runxbuild guide to DigitalOcean puts it plainly: leaving the nameservers at the registrar and adding an A record is the simpler option for a single droplet with no load balancer involved. If you are unsure which method fits, our Cloudflare beginner guide covers the managed-DNS route, which gives you Cloudflare's panel and CNAME flattening without running any DNS software yourself.

Step 3: Delete the Old Records (and Leave Your Mail Alone)

Delete any old A records for @ and www that still point somewhere else, such as a parked page or your previous host. Two different A records for the same name make visitors land on either server at random, which Volyte states as the direct consequence and which is the most confusing failure in this whole job: the site works for you and fails for your friend, or works on one refresh and fails on the next. If there is an AAAA record for IPv6 pointing to your old host, delete it too, or change it to your VPS's IPv6 address if it has one.

Editing in place achieves the same thing, and some panels make it the natural move. The dev.to guide for connecting a Namecheap domain to DigitalOcean says the same thing in the other direction: if there are old A or CNAME records pointing somewhere else, remove them or update them to the new IP. Whichever way your panel works, the end state must be exactly one A record per name, pointing at your VPS.

Do not touch your MX records. They decide where your email goes, and changing A records moves your website only, so your email keeps working where it is. Volyte states this warning in plain language, and Domain India states it even more bluntly: if your email lives somewhere else, change only the A records, and leave the MX and TXT records alone, or email stops arriving.

Mail records are a separate record type from A records, and Cloudflare's own documentation confirms the separation: an MX record is required to deliver email to a mail server, and it is independent of the A record that serves your website.

The same rule covers TXT records. Email authentication records such as SPF and DKIM live in TXT records, and deleting them breaks deliverability even though the website looks fine. The safe rule is simple: in this job you touch A, AAAA and CNAME records only.

Everything else stays exactly as it was.

Step 4: Verify the Change with dig

Do not test by loading the site in your browser. Your browser caches DNS aggressively, so it can show the old site long after the records are correct, or the new site while the rest of the world still sees the old one. A dev.to guide on DNS propagation, published 28 October 2026, makes this the first rule: query resolvers directly instead.

The command to run depends on your system. On Mac and Linux, run dig +short example.com @8.8.8.8, replacing example.com with your domain. Volyte gives exactly this command and states the pass condition: when it shows your VPS IP, DNS is ready.

Hostinger's tutorial gives the shorter form dig A +short domain.tld and states the same result: if configured correctly, the terminal returns your VPS IP address as the A record. On Windows without dig, run nslookup example.com 8.8.8.8 instead.

Query more than one resolver, because a single resolver only tells you what that resolver sees. The dev.to propagation guide recommends checking Google's 8.8.8.8 and Cloudflare's 1.1.1.1 separately: dig @1.1.1.1 example.com +short and dig @8.8.8.8 example.com +short. If both return your VPS IP, the change has spread to the big public resolvers.

You can also ask your authoritative nameserver directly with dig @ns1.yourprovider.com example.com +short, which bypasses every cache. The guide's reasoning is worth quoting: your authoritative nameserver is the source of truth, so if it returns the new IP, your change is live and everything after that is just caching.

For a worldwide picture, check whatsmydns.net, which queries 20 to 50 resolvers at once across many countries. Mixed results are completely normal partway through a TTL window, and the guide says to expect resolvers to disagree for a while. Green ticks appearing country by country is the change spreading, not a problem.

A second option on this site is the DNS lookup tool, which performs the same kind of check without a terminal.

One result confuses people every time, so it is worth stating once. If your records are proxied through Cloudflare, dig shows Cloudflare's IP addresses, not your VPS IP, and that is expected. A proxied record hides the origin IP by design, so a Cloudflare address in the dig output is not proof the A record is wrong.

Check the record value inside your Cloudflare panel instead, or temporarily switch the record to DNS-only and run dig again.

How Long Does DNS Propagation Take for a VPS?

How long DNS propagation takes for a VPS depends almost entirely on the TTL that was on the record before you changed it, not the one you set afterwards. That is the central mechanism, and the dev.to propagation guide states it directly: the TTL you set afterwards barely matters, because every resolver that already cached the old record keeps serving it until the old TTL runs out. Once the change is made, nothing can force it faster; you cannot reach into someone else's resolver and expire their cache.

The honest answer is therefore a range, and search results for how long does dns propagation take vps quote everything from five minutes to three days, because the sources genuinely disagree about it, so this guide gives each figure with its source instead of pretending there is one number. Volyte says changes usually show within 5 to 60 minutes, and sometimes take a few hours. Hostinger says propagation may take up to 24 hours.

VPS.us says most DNS updates take 1 to 4 hours, with full propagation across all global DNS servers taking up to 48 hours. Whatsmydns.net, which exists to measure exactly this, says propagation can take from only a few minutes but often takes up to 48 to 72 hours, and sometimes longer. FalconCloud gives 24 to 48 hours as typical, with as little as 30 minutes and up to 72 hours at the extremes.

The TTL table below, taken from the dev.to propagation guide, turns the mechanism into numbers you can plan around. Each row shows the old TTL and how long the old address stays visible after you change the record.

The conversions in that table are simple division, and they were recomputed for this article: 14400 divided by 3600 is 4 hours, and 86400 divided by 3600 is 24 hours. The 24 to 48 hours that hosting companies quote is a safety margin to cover the slowest cache in the chain, according to the same dev.to guide, and some ISPs ignore TTL rules and keep a cached record even after it has expired, which whatsmydns.net lists as a cause of delay.

The practical move is to lower the TTL before you change anything. Set the TTL to 60 seconds at least 24 hours before the change, then raise it back to 3600 or higher once the new server has been stable for a couple of days. That advice appears in both the dev.to guide and the FalconCloud guide, which suggests lowering to 300 to 1800 seconds at least 24 hours before the change.

A low TTL costs a few extra DNS lookups and nothing else, and it is the only lever you actually control.

While you wait, you can flush your own computer's DNS cache, which only affects your own machine. On Windows run ipconfig /flushdns. On macOS run sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder.

On Linux with systemd run sudo resolvectl flush-caches. In Chrome you can open chrome://net-internals/#dns. None of these speeds up anyone else's view of your domain; they only clear your own stale answer.

The following Python block recomputes the TTL conversions and the setup-time comparison used in this guide, so the numbers above can be checked rather than trusted. It was run on 6 November 2026.

from datetime import date

ttl_seconds = [60, 300, 3600, 14400, 86400]
for s in ttl_seconds:
    print(s, "seconds =", s / 60, "minutes =", s / 3600, "hours")
# 60 seconds = 1.0 minutes = 0.016666666666666666 hours
# 300 seconds = 5.0 minutes = 0.08333333333333333 hours
# 3600 seconds = 60.0 minutes = 1.0 hours
# 14400 seconds = 240.0 minutes = 4.0 hours
# 86400 seconds = 1440.0 minutes = 24.0 hours
print("A-record setup 5-10 min vs nameservers 15-30 min:",
      15 / 5, "x at the low end,", 30 / 10, "x at the high end")
# 3.0 x at the low end, 3.0 x at the high end
print("Cloudflare API TTL range ratio:", 86400 / 60)
# 1440.0
print("Volyte guide age on 2026-11-06:",
      (date(2026, 11, 6) - date(2026, 10, 19)).days, "days")
# 18 days
print("dev.to propagation guide age on 2026-11-06:",
      (date(2026, 11, 6) - date(2026, 10, 28)).days, "days")
# 9 days

If you want a visual check while the numbers above work themselves out, use the DNS propagation checker on this site, which queries resolvers around the world and shows which ones have picked up the new address. Expect disagreement for a while; that is propagation working, not failing.

Step 5: Tell Your Web Server, Then Add Free SSL

DNS sends visitors to your server, and now the server must know which website to show for that domain. This is the step people forget, and its symptom is distinctive: the domain resolves to the VPS, but the browser shows the server's default page or another site entirely. Volyte states the rule directly, and then gives the fix per setup: in cPanel or Plesk, add the domain in the panel; in IIS Manager, add a binding for the domain on port 80; with Nginx, set the server_name directive to your domain.

For Nginx, the line to add inside the server block is server_name example.com www.example.com;, with your own domain in place of example.com. For Apache, the equivalent is a ServerName line for the apex and a ServerAlias line for www. Make sure ports 80 and 443 are open in your server's firewall, because a closed port 80 breaks both the website and the certificate step that follows.

Our Nginx beginner guide walks through the full server-block setup if you have not configured a site on Nginx before.

Once the domain opens your site, add HTTPS so browsers show the padlock. It is free with Let's Encrypt, and the tool that does it is Certbot. On Ubuntu or Debian with Nginx, the commands are sudo apt install certbot python3-certbot-nginx followed by sudo certbot --nginx -d example.com -d www.example.com.

Certbot sets up HTTPS and renews the certificate automatically. Volyte lists the same two commands, and the cPanel and Plesk equivalents, AutoSSL and the Let's Encrypt extension, do the same job automatically, usually within minutes.

SSL only works after DNS points to your VPS, so do not run Certbot first. Let's Encrypt proves control with the HTTP-01 challenge: it connects to your domain on port 80 and asks for a temporary file that Certbot places there, which means the domain must already resolve to your server. The flaviocopes guide on Nginx and Certbot, updated 2 October 2026, gives the precondition as a command: dig +short my.domain.com must print your server's IP address, and if it prints nothing or a different IP, fix the record or wait, because Certbot will fail until it is right.

Two details from the same guide are worth keeping. Keep port 80 open even after HTTPS works, because renewals use it. And if an AAAA record exists, Let's Encrypt tries IPv6 first, so a stale AAAA record pointing at your old host makes Certbot fail with a confusing error about reaching the wrong server.

That is the same stale-record cleanup from step 3, now with a second reason to do it. Let's Encrypt certificates last 90 days, and Certbot handles renewal automatically, which you can confirm with sudo certbot renew --dry-run. The weekly limit of 50 certificates per registered domain is reported by youstable, a third-party guide, so treat it as a planning figure rather than an official number.

Troubleshooting: 5 Fixes When the Domain Still Won't Load

When the domain still will not load, work through this table in order. Most failures are one of these five, and each has a one-command check.

Two more checks cover the remaining cases. First, check the www version and the apex separately, because they are separate records and one can be right while the other is wrong. Second, remember that your browser cache and your operating system's DNS cache can both lie to you after a correct change; the flush commands from the propagation section clear your own machine, and a private browsing window removes the browser cache from the test.

If everything checks out with dig but the site still fails, the problem is on the server, not in DNS. Confirm the web server is running, confirm ports 80 and 443 are open in the firewall, and confirm the virtual host matches the domain exactly, including the www variant. DNS can only deliver visitors to the server; it cannot make the server answer.

Sources

1. Volyte, "How to Point Your Domain to Your VPS (DNS A Record + Free SSL)", published 19 October 2026, updated 5 November 2026 — https://volyte.com/blog/point-domain-to-vps
2. Hostinger, "How to Point a Domain Name to VPS" — https://www.hostinger.com/in/tutorials/how-to-point-domain-to-vps/
3. VPS.us, "How to Point a Domain to VPS" — https://vps.us/blog/how-to-point-a-domain-to-vps/
4. Domain India, "Manage a VPS Without a Control Panel" — https://domainindia.com/support/kb/managing-your-domain-and-vps-without-a-control-panel
5. Namecheap, "How to set up a VPS: Beginner-Friendly Step-by-Step Guide" — https://www.namecheap.com/support/knowledgebase/article.aspx/10777/48/how-to-set-up-a-vps-beginnerfriendly-stepbystep-guide/
6. DigitalOcean Docs, "How to Add Domains" — https://docs.digitalocean.com/products/networking/dns/how-to/add-domains/
7. Cloudflare Docs, "DNS record types" — https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/
8. Cloudflare Docs, "CNAME flattening diagram" — https://developers.cloudflare.com/dns/cname-flattening/cname-flattening-diagram/
9. Cloudflare API Docs, "Records" — https://developers.cloudflare.com/api/resources/dns/subresources/records/
10. who.is, "CNAME Records: How DNS Aliases Work (and Their Limits)" — https://who.is/learn/cname-records
11. dev.to, "CNAME Records: When and How to Use Them" — https://dev.to/toolbox_starnomina/cname-records-when-and-how-to-use-them-with-common-pitfalls-4j7h
12. dev.to, "DNS propagation: how long it really takes", published 28 October 2026 — https://dev.to/romailshah/dns-propagation-how-long-it-really-takes-4nal
13. whatsmydns.net, "Global DNS Checker" — https://www.whatsmydns.net/
14. FalconCloud, "What is DNS propagation and how long does it take?" — https://falconcloud.ae/about/blog/what-is-dns-propagation-and-how-long-does-it-take/
15. runxbuild, "Add a Domain to a DigitalOcean Droplet" — https://www.runxbuild.com/blog/add-domain-to-digitalocean-droplet/
16. flaviocopes, "How to configure Nginx for HTTPS", updated 2 October 2026 — https://flaviocopes.com/nginx-https-certbot/
17. ezdevops, "SSL/TLS Guide 2026" — https://www.ezdevops.cloud/ssl-certificates-basics.html
18. youstable, "How to Create Let's Encrypt on Linux Server with Certbot" — https://www.youstable.com/blog/create-lets-encrypt-on-linux-server/

Frequently Asked Questions

How do I point a domain to a VPS?

Add an A record for @ and a second A record (or a CNAME) for www at the provider that manages your domain's DNS, both pointing to your VPS IP address. Delete any old records that point elsewhere, then verify with dig +short and wait for propagation. The whole edit takes about five to ten minutes, according to VPS.us.

How long does DNS propagation take for a VPS?

It depends on the TTL that was on the old record before you changed it. Volyte says changes usually show within 5 to 60 minutes, Hostinger says up to 24 hours, and VPS.us says most updates take 1 to 4 hours with full propagation up to 48 hours. The table in the propagation section above turns the old TTL into a wait: a 3600-second TTL means about an hour, and an 86400-second TTL means up to 24 hours.

Should I use a CNAME or an A record for www?

Either works when www lives on the same server as the apex. A CNAME for www pointing at example.com means you maintain only one IP address, while a second A record means www can point at a different address if it ever needs to. Never use a CNAME at the apex itself, because the DNS standards forbid it.

Will changing my A record affect my email?

No, as long as you leave the MX and TXT records unchanged. Email is controlled by MX records, and changing A records moves your website only. Volyte and Domain India both state this directly, and both warn that deleting or changing MX records is what actually breaks email.

Do I need an SSL certificate after pointing the domain?

Yes, if you want browsers to show the padlock and load the site over HTTPS. Run Certbot only after DNS points at your VPS, because Let's Encrypt verifies control by connecting to your domain on port 80. The command for Nginx on Ubuntu or Debian is sudo certbot --nginx -d example.com -d www.example.com, and the certificate renews automatically.