Domains, DNS and Email: A Self-Run Setup That Lasts

Separate domain ownership from DNS and mail delivery

A registrar maintains your domain registration, a DNS provider publishes its records, and an email provider handles its messages. For a small team, understanding those separate jobs means you can replace a failed VPS without rebuilding your business identity. Your website and mailbox addresses can survive the move.

For a single VPS running Ubuntu 24.04 LTS, we recommend managed authoritative DNS and hosted mailboxes. Keep the application server focused on the application. Running your own software does not require operating every service attached to its domain.

These services can share a vendor, but treat their configuration as separate responsibilities. Moving authoritative DNS does not transfer domain registration or migrate stored messages. Changing an address record does not move application data either, so document which service owns each part before touching the domain.

Choose accounts you can recover during an outage

Choose your registrar for account security and a clear recovery process. Check that you can manage nameservers and DNSSEC delegation without a support conversation, and enable automatic renewal with a working payment method. Keep an independent reminder because automatic renewal can fail.

Use a recovery address outside the domain you are administering. If broken DNS stops your mailbox receiving mail, a password reset sent to that mailbox cannot help you. Store recovery codes somewhere you can reach without the VPS or the domain's single sign-on service.

We would use Cloudflare for authoritative DNS when its proxy features or scoped automation access solve a real need. Our Cloudflare review covers that provider choice in more detail. If your current managed DNS already meets your needs, keeping it is a reasonable decision.

Using a separate registrar makes the boundary between domain ownership and DNS administration explicit, though it adds another account to maintain. We prefer that arrangement when the registrar permits independent nameserver selection. Record who owns each account and how another trusted operator can recover it if the usual administrator is unavailable.

Map the records before changing providers

Export the current DNS zone and compare it with the applications and services you actually use. A provider's automatic discovery cannot reliably reconstruct every hostname, particularly an obscure verification record or DKIM selector. Keep the original export as a reference even if you decide to remove stale entries later.

An old AAAA record deserves particular attention. If it points somewhere your application no longer works, clients using that address can fail while other visitors succeed. Remove it only after confirming that it is obsolete, rather than assuming the A record makes it irrelevant.

Keep web routing separate from mail routing. An MX record names a mail server, and that server's address must remain reachable for mail protocols. Cloudflare's ordinary web proxy does not carry SMTP traffic, and email-related CNAME records such as DKIM delegation should remain DNS only, as explained in its proxy limitations documentation.

Start a DNS migration with web records set to DNS only as well. After resolution is stable, enable the web proxy deliberately and verify certificate handling at the origin. Use the reverse proxy, load balancer and CDN guide to decide where that additional layer belongs.

Move DNS to Cloudflare without moving email

Move authoritative DNS as its own change, keeping your mailbox provider and application deployment steady. The following sequence follows Cloudflare's full setup procedure. Schedule it when someone can investigate unexpected responses.

1. Export the old zone and record its nameservers. Lower relevant record TTLs in advance, allowing the previous TTLs to expire.
2. Add the domain to Cloudflare and compare its records against your export. Copy missing mail records and keep proxying disabled initially.
3. If DNSSEC is active, remove the old DS record at the registrar and wait for its cached copies to expire before changing nameservers. Keep the old signed zone working during that wait.
4. Replace the registrar's nameserver delegation with the exact nameservers Cloudflare assigns. Keep the old DNS zone available during the transition.
5. Verify authoritative answers and recursive resolution. Then enable DNSSEC at Cloudflare and publish its new DS details at the registrar.
6. Validate signed resolution and mail delivery before retiring the old zone. Save a fresh export of the working configuration.

Lowering a website record's TTL does not shorten every cache involved in a nameserver migration. Delegation and DS records have their own caching behavior. A stale DS record can make a correctly populated new zone fail validation, so changing nameservers is not the moment to guess about DNSSEC state.

Keep both zones consistent while cached delegations remain in use. If you need to reverse the move, coordinate nameservers with the applicable DNSSEC delegation rather than restoring a saved setting blindly. Changing MX records during this process creates an additional mail migration problem that you can avoid.

Put custom-domain mail outside the application VPS

Choose a hosted mailbox service for the addresses people use to contact you. Create the mailboxes before publishing its MX records, then verify incoming messages and replies. An alias can route mail into an existing inbox, but confirm that the service also supports authenticated sending from that address.

For application messages, we prefer a transactional email provider with domain authentication and useful delivery logs. Use its authenticated SMTP service or API from the application. Do not assume a successful API response means the message reached an inbox; it may only mean the provider accepted the request.

A dedicated sending subdomain can make application authentication and troubleshooting easier to manage. Configure the provider's custom signing domain and return-path domain where supported. This separation gives you clearer records, but it does not guarantee that reputation problems stay isolated from the rest of your domain.

We would not host the primary mailbox on the application VPS for a small team. Self-hosting mail adds queue management and reputation work, and outbound delivery also depends on the host's network policy and reverse DNS controls. If operating mail infrastructure is an explicit project, give it a separate recovery plan and an administrator who intends to maintain it.

Authenticate every sender before enforcing DMARC

SPF authorizes sending infrastructure for the SMTP envelope domain, which can differ from the address a person sees in the From field. Publish a single SPF policy at each relevant hostname and combine authorized sources within that policy. Follow each provider's instructions, remove retired senders, and check nested includes against SPF's DNS lookup limit.

DKIM attaches a domain signature to a message, with verification material available through DNS. Enable signing in the sending service as well as publishing its records; creating a selector alone does not turn signing on. Keep private signing keys out of public DNS and follow the provider's rotation procedure.

Treat these as maintained configuration, with an owner for each authorized sender. The Spamhaus sender guidelines provide an operational reference for SPF and DKIM hygiene. Neither mechanism certifies that a message is wanted or that its content is trustworthy.

DMARC connects authentication to the visible From domain. It passes when SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain. Under relaxed alignment, the domains can share the same organizational domain; unrelated provider domains do not qualify.

Begin with p=none and a working aggregate-report destination, then inspect every legitimate sending service. Move toward p=quarantine and finally p=reject after fixing failures. Microsoft's DMARC configuration documentation explains alignment and staged enforcement, including authorization for reports sent to another domain.

Forwarding can break SPF because the forwarding server becomes the connecting sender. A surviving aligned DKIM signature can still satisfy DMARC, although message modifications can break that signature too. Review forwarded mail and mailing-list traffic before tightening enforcement, and remember that receivers apply their own delivery policies.

Verify delivery and give Claude Code bounded access

Use DNS queries to confirm publication, then use actual received messages to confirm authentication. On Ubuntu 24.04 LTS, dig is available through the dnsutils package. The commands below use a documentation domain; replace it with your registered domain, and replace the selector with the one your sending provider supplies.

dig example.com NS +short
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector._domainkey.example.com TXT +short
dig selector._domainkey.example.com CNAME +short

Send a message from each real sending path to an independent mailbox, then inspect that receiver's original headers. Check its trusted Authentication-Results for SPF and DKIM results and a DMARC pass associated with your visible From domain. Also send mail into your hosted mailbox and reply from it.

We recommend Claude Code for inventorying records and explaining proposed changes, with read-only access as the default. Ask it to show each changed hostname and its expected effect before granting write access. Keep registrar recovery credentials outside its environment, and retain human approval for MX changes, delegation changes and DMARC enforcement.

When automation needs DNS writes, use a short-lived token limited to the required zone and permissions. Zone access may still permit more record changes than the task needs, so check the token's actual scope. Follow the scoped API token and agent secrets guide and keep credentials out of prompts and saved reports.

Schedule your first delivery and recovery check

Before ending the setup session, create a short runbook containing account ownership and the current DNS export. Include the mailbox provider and every application sender, with a note identifying the records each requires. Store recovery material separately from that ordinary operational document.

1. Send an external message into your domain, reply, and trigger an application message such as a password reset.
2. Assign someone to review aggregate DMARC reports and investigate unknown or misaligned senders.
3. Create an independent domain-expiry reminder and confirm that account recovery messages reach an external address.
4. Add DNS resolution and certificate checks to your monitoring, with alerts delivered outside the application VPS.

Use the minimum viable monitoring guide to keep those alerts manageable. Add a recurring end-to-end email check because a healthy website does not prove that password resets arrive. Make the next DMARC enforcement review a dated task with an owner, rather than leaving observation mode indefinitely.