Running your website and corporate email side by side on one domain

You already send and receive mail as @yourcompany.com, and you want your official website to live at www.yourcompany.com — the same name buyers already trust. The usual worry is that the site will somehow break your email, or that the two will fight over the domain.

They don’t. A website and a mailbox use different records in the same DNS zone, and running both on one domain is a standard, well-trodden setup. This guide explains the model in plain terms, gives you the safe split, and a checklist to verify nothing broke.

Same domain, two different jobs

Think of your domain as an address book that the whole internet reads. Each entry is a record, and each type answers a different question:

A / AAAA / CNAME records answer “where does this hostname’s website live?” — they point www.yourcompany.com (and often the bare apex yourcompany.com) at a web host. Your site uses these.
MX records answer “where should mail addressed to this domain be delivered?” — they point at your email provider’s servers. Your mailbox uses these.
TXT records carry things like SPF (“which servers are allowed to send mail as this domain?”) and DKIM keys (“is this message signed by the domain’s mail provider?”). Your email provider publishes these.

When a buyer opens your site, their browser asks for the A/CNAME answer and never looks at MX. When someone emails you, the sending server asks for the MX answer and never looks at the web record. Two different questions, two different answers, same address book — no conflict in the mechanics.

The one real risk isn’t the coexistence. It’s that, during a move, one party ends up holding the whole address book and forgets to copy the other party’s records into it.

The split you actually want

The clean division is:

Your email provider stays authoritative for mail. The MX, SPF and DKIM records that keep your inbox working keep pointing where they point today. You don’t retrain your team, and deliverability history is undisturbed.
Only the web records point at your site host. A records (and any CNAME for www) resolve to your site’s edge. That is the only part Nodipe asks to control.

Exactly where the zone lives is a small decision with two common shapes:

Your current DNS host stays primary. If the registrar or DNS host you already use lets you set apex A and www CNAME records, keep it as the single source. Your email provider’s MX/SPF/DKIM stay untouched, and you (or Nodipe, on your behalf) just add or update the web records. This is the least disruptive option.
Nodipe hosts the web zone and mirrors your mail records. Some DNS hosts won’t let you point an apex domain anywhere except their own parking page. In that case the zone moves to Nodipe — and we re-create your email provider’s MX, SPF and DKIM records at the exact same values before anything goes live. Mail keeps resolving to the same servers; nothing about the mailbox changes.

Whichever shape fits, the rule is identical: whichever party holds the zone must carry both the web records and the mail records. A zone that only knows about the website will silently drop your email.

A note on providers

Coexistence is provider-agnostic — the DNS mechanics are the same whether your corporate mail runs on Google Workspace, Microsoft 365, Zoho, or a self-hosted server. The same instructions apply to providers commonly used by sellers serving mainland China, such as Tencent Exmail or Alibaba Enterprise Mail; they publish MX, SPF and DKIM records like anyone else. If you’re not sure which provider your mail is on, ask whoever set it up — you’ll want to know before you touch anything.

Before you switch anything

Spend ten minutes capturing the current state. You need, from your email provider’s admin panel (or from whoever runs your mail):

The MX records for yourcompany.com (the hostnames and their priority numbers).
The SPF TXT record (it usually looks like v=spf1 include:_spf.provider.com ~all).
The DKIM TXT record for the selector your provider lists (e.g. google._domainkey for Workspace — ask your provider which selector it uses).

Store them somewhere you can reach if the zone changes hands. If you can read your current DNS, dig gives you the same snapshot:

dig +short MX yourcompany.com
dig +short TXT yourcompany.com          # look for the v=spf1 line
dig +short TXT <selector>._domainkey.yourcompany.com

Keep those outputs. Then make the change at a low-traffic moment, and confirm with the person who administers your mail that they’re on board — the handover is a five-minute coordination task, not a migration.

After the switch: what “working” looks like

Once the records are live (DNS propagation is usually fast, but allow up to an hour or two), verify the three things that matter:

The site loads. www.yourcompany.com and the apex both resolve and serve your site over HTTPS.
Inbound mail still arrives. Send a test message from a personal account to your company address.
Outbound mail still passes checks. Send a test message from your company address to a personal inbox at Gmail or Outlook, and check it isn’t marked spam. If you can, look at the raw headers and confirm SPF and DKIM both show pass.

The dig commands below confirm the records independently of any mail client:

dig +short A www.yourcompany.com     # → your site's edge
dig +short MX yourcompany.com        # → your mail provider's servers
dig +short TXT yourcompany.com       # → SPF includes your provider

Troubleshooting: symptoms, cause, fix

If something looks off after a switch, it’s almost always one of three things. Work from the symptom:

Symptom	Likely cause	Fix
Email to the domain bounces or sits undelivered	MX records missing or wrong in the live zone	Restore the exact MX records from your provider (captured above) and wait for propagation
Outgoing mail lands in spam, or SPF/DKIM fail in headers	The zone moved and the new host only carried web records — SPF/DKIM TXT are gone	Re-add the provider’s SPF and DKIM TXT records exactly as captured
Website returns an error, or the browser can’t connect	Web record points at the wrong target, or is still propagating	Confirm the A/CNAME target with your site host and wait; if it persists, contact support
Everything worked in preview but broke at cutover	A second, older zone (e.g. an old hosting panel) is still answering for the domain	Find every place that manages DNS for the domain and consolidate to one

If your site is a Nodipe node and mail still isn’t arriving after the MX values look correct, write to us with the output of the three dig commands above — that tells us in seconds whether the issue is the zone, the records, or something in between.

The same records that make it safe to stay, make it safe to leave

Nothing about coexistence locks you in. Your mail records stay your email provider’s; your web records point at a host you chose; and your domain stays registered in your name. Every asset that matters — your domain, your content, your inquiry history — remains exportable. See one-click data export & how your assets stay yours for what leaves with you and in what form.

next → One-click data export — how your assets stay yours