Set Up DNS Records for a VPS App Without Breaking Email or Existing Traffic

Before you begin

• Access to your DNS provider or registrar’s DNS control panel.
• The public IPv4 address of your VPS, and IPv6 if you plan to use it.
• Clarity about which hostname should point to the app, such as example.com or app.example.com.
• A way to inspect the current records, either in the DNS panel or with tools like dig.

The safest DNS change is almost never “delete what looks old and add the new thing.” DNS is shared infrastructure. Your website, email, domain verification, and third-party services may all depend on records that sit next to each other.

Step 1: Inventory every existing DNS record before changing anything

Make a checklist of the current records at the exact names you plan to touch. For example:

• Root domain: example.com
• App subdomain: app.example.com
• WWW host: www.example.com

From a terminal, gather current values:

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME app.example.com
dig +short MX example.com
dig +short TXT example.com

Also inspect the DNS provider panel directly, because some records are easier to understand in the UI. Write down or export:

• Record name
• Record type
• Current value
• TTL
• What you believe it is used for

A simple pre-change inventory checklist looks like this:

• A records: Which hostnames point to IPv4 addresses right now?
• AAAA records: Which hostnames point to IPv6 addresses right now?
• CNAME records: Which hostnames alias to another hostname?
• MX records: Where is mail for the domain delivered?
• TXT records: Which values support SPF, DKIM, DMARC, domain verification, or other services?

Expected outcome: You know exactly which records already exist, so you can add or replace only what is necessary.

Step 2: Understand the DNS record types that matter here

You do not need to become a DNS engineer, but you do need a clean mental model:

• A record: Points a hostname to an IPv4 address, such as your VPS public IP.
• AAAA record: Points a hostname to an IPv6 address.
• CNAME record: Makes one hostname an alias of another hostname. Often used for www or vendor-managed subdomains.
• MX record: Tells the world where email for the domain should be delivered.
• TXT record: Stores text-based policy or verification data, often for SPF, DKIM, DMARC, or service ownership checks.

Important practical rules:

• A root domain like example.com often uses A or AAAA records, not a standard CNAME, unless your DNS provider supports flattening or ALIAS behavior.
• A hostname generally cannot have both a normal CNAME and other records at the same name.
• MX and many TXT records are about mail or service verification, not website routing. Leave them alone unless you know why they need to change.

Step 3: Plan the VPS app change before editing live DNS

Decide which hostname should point to the app. Common patterns:

• app.example.com points to the VPS, while example.com stays on the existing site.
• example.com points to the VPS, while www.example.com becomes a CNAME to the root or another target.

If you are moving an existing live hostname, lower the TTL in advance if your DNS provider allows it. For example, reduce it from 3600 seconds to 300 seconds a few hours before the cutover. That can make rollback faster later, though some resolvers still cache aggressively.

Example plans:

New app on a subdomain:

app    A      203.0.113.50
app    AAAA   2001:db8::50   # only if IPv6 is configured and tested

Website on root with WWW redirect pattern:

@      A      203.0.113.50
www    CNAME  example.com.

Before you point traffic, verify the VPS itself is ready:

• The web server or reverse proxy is listening on ports 80 and 443.
• The app or proxy is configured for the intended hostname.
• Firewall rules allow web traffic.
• If HTTPS will be issued after DNS points correctly, you know that expected order ahead of time.

Step 4: Apply the records and verify realistic propagation

Make the smallest change that achieves the goal. Avoid “cleanup” edits in the same moment unless they are necessary.

After saving the new records, verify with DNS lookups:

dig example.com A
dig example.com AAAA
dig app.example.com A
dig app.example.com CNAME

Then test from the browser or with HTTP checks:

curl -I http://app.example.com
curl -I https://app.example.com

If HTTPS is not ready immediately, that can simply mean the certificate has not finished issuing or attaching yet even though the DNS change itself is correct.

TTL and propagation expectations:

• Low TTL values can help changes appear faster, but they do not guarantee instant updates everywhere.
• Some resolvers, browsers, and local systems cache results longer than you expect.
• It is common to see mixed results for a while during a cutover.

If you need to compare views, query a known public resolver directly:

dig @1.1.1.1 app.example.com A
dig @8.8.8.8 app.example.com A

Expected outcome: The intended hostname resolves to the VPS, the app responds, and unrelated mail or verification records remain unchanged.

Step 5: Treat mail-related records as protected unless proven otherwise

Website DNS and email DNS often live in the same zone, but they serve different purposes. A safe operator mindset is:

• Do not edit MX records just because you are changing website hosting.
• Do not remove TXT records that look unfamiliar until you identify whether they are SPF, DKIM, DMARC, Google Workspace, Microsoft 365, Brevo, Mailgun, or other service verification records.
• If you move the root domain to a new provider’s DNS service, migrate every required mail record too, not just the web records.

Common mail-related examples:

example.com.          MX    10 mail.provider.com.
example.com.          TXT   "v=spf1 include:mail.provider.com ~all"
_dmarc.example.com.   TXT   "v=DMARC1; p=none"
default._domainkey    TXT   "k=rsa; p=MIIBIjANBgkq..."

If those disappear during a web cutover, mail delivery or domain verification can break even though the website looks fine.

Troubleshooting common DNS setup mistakes

The app hostname still points to the old server.
Check TTL timing, local DNS cache, and whether you changed the correct record name in the correct DNS zone.

HTTPS fails after the DNS change.
The app may not have the correct virtual host configured yet, or the reverse proxy may still need to obtain a certificate now that the hostname points correctly.

Email broke after changing web DNS.
Compare the current zone against your pre-change inventory and restore missing MX or TXT records immediately.

I added both a CNAME and another record for the same name.
That usually causes conflicts. Decide whether that hostname should be an alias or a direct record target, then remove the invalid combination.

IPv6 users cannot reach the site.
If you added an AAAA record, make sure the VPS and firewall are actually ready for IPv6. If not, remove the AAAA record until IPv6 is configured properly.

What to do next

Once DNS is stable, the next practical layer is securing the public endpoint with a reverse proxy and HTTPS. Continue with Set Up HTTPS on a VPS With Caddy.