Do I have to change my nameservers to get email on my own domain?

What you are actually choosing between

Every domain has a set of nameservers. They are the servers the rest of the internet asks when it wants to know anything about your domain: where the website is, where mail goes, which services you have verified. Whoever runs your nameservers holds the master copy of all those answers, and every route to connecting a domain is a decision about how much of that master copy the email service is allowed to write.

There are three answers, and they are not three levels of the same thing. Two records at your DNS host hands over one small corner of the domain, mail.yourdomain.com, and nothing else. Scoped access hands over a key to your existing DNS account that is limited to that one domain's records. Moving the whole domain hands over the master copy itself, by changing the nameservers.

• Two records at your DNS host: you add an NS record set for mail.yourdomain.com and one CNAME for _dmarc.yourdomain.com where your domain already lives. Addresses read [email protected]. This is the recommended route, and the rest of this guide explains why.
• Scoped access to your DNS account: when the domain already lives on a DNS account the service can connect to, you grant a token limited to that domain, and the mail records are published and repaired inside your own account. Nameservers stay where they are.
• Moving the whole domain: the nameservers change to the service's, and from then on every record on the domain is managed there. It carries the most work up front and is the only route that changes where your website's records are served from.

Moving the whole domain is not the riskier option because it is more technical. It is riskier only in proportion to how much is already running on the domain, and the two-record route removes that proportion entirely.

The two-record route, and why it is the default

An NS record for a subdomain tells the internet that questions about that subdomain, and only that subdomain, should be sent to a different set of nameservers. Publishing one for mail.yourdomain.com means the service can host every record that email needs inside that corner: the DKIM keys that sign your messages, the SPF record that authorises the sending path, the DMARC policy, and the return path that bounces come back to. It can also change them, rotate a key, or repair a record that drifted, without ever writing to the rest of your domain, because it cannot.

The second record is a CNAME at _dmarc.yourdomain.com pointing at the DMARC record the service hosts. That is what lets the policy for your bare domain be kept correct from the service's side rather than pasted by hand and forgotten. Between them the two records make [email protected] a fully authenticated sending address, and neither of them touches your website, your existing mail, or any record you did not add.

Two conditions apply, and the scan checks both before the route is offered. The DNS host must accept an NS record on a subdomain, which nearly every host does; a few registrar panels refuse, and on those the route is shown as unavailable rather than failing later. And if the domain already publishes a DMARC record, it must not use strict alignment, written as adkim=s or aspf=s. Strict alignment demands that the signing domain be exactly the bare domain, and mail signed in mail.yourdomain.com would fail it. Relaxed alignment, which is the default and what most domains have, accepts a subdomain, and relaxing a strict record is a one-word edit.

1. 1

   Run the scan

   It reads what is published today, confirms the host accepts an NS record, and checks any existing DMARC record for strict alignment. Nothing changes.

2. 2

   Add the NS set for mail

   In your DNS record editor, add one NS record per name server you were given, all with the name mail. Leave every existing record alone.

3. 3

   Add the CNAME for _dmarc

   One record, name _dmarc, pointing at the target you were given. If a TXT record already exists at that name, it has to be removed first; a name cannot carry both.

4. 4

   Optionally, add the MX

   Only if you want to receive at the bare domain. Skip it to send only, and add it later at any time.

5. 5

   Send a real message once it settles

   A subdomain NS change is quick, usually minutes. A message that arrives in a real inbox is the only proof that matters; a green tick means the records look right, which is a different claim.

Scoped access, when the domain already lives on your own DNS account

Some DNS providers let an account holder create a key that is limited to one domain's records and nothing else. When your domain already lives on such an account, the service can use a key like that instead of asking you to add records by hand: it publishes the mail records inside your account, checks them, and repairs one that drifts, while your nameservers stay exactly where they are.

It gives the same outcome as the two-record route with one fewer thing to paste, at the cost of a grant you have to make and can revoke. Setup shows the exact permissions before you grant anything, and the key covers that one domain only; it cannot read or change any other domain in the account, and the service has nothing to hold once you revoke it.

• Choose it when the domain is already on an account of that kind and you would rather grant a key than publish records.
• Choose two records instead when the account belongs to an agency or an IT department that will not hand out a key, or when you simply prefer not to. Two records is a routine request for them to review.
• It is offered only when the scan finds the domain on a provider that supports it; on every other host it is not shown, and that is not a fault.

Moving the whole domain, and when it is worth it

Choose this when you want the website and the mail run in one place, or when the domain has little on it and you would rather not maintain records anywhere. The nameservers change at the registrar, and from then on every record on the domain is created, checked and repaired by the service, mail or not.

• The domain was registered recently and nothing is on it yet, which is the easiest case.
• It is a name you bought to protect a brand and never built on.
• You want the website hosted alongside the mail, with the security and speed that come from running the whole domain.
• You would rather the service notice and repair any drift, on any record, than be emailed about it.

The work is front-loaded and it is all in one place: every record that exists today must exist in the new zone before the switch takes effect. The service scans the domain, takes a backup, and carries over what it finds, which handles the great majority of records. A scan reads only what is published, though, so a record that was never published, or one on a name the scan could not guess, has to come from your own inventory. That inventory is what the preflight guide asks you to make, and this is the route where it earns its keep.

1. 1

   Do the preflight inventory first

   You cannot confirm the new zone is complete without a list of what the old one held. Ten minutes, before anything changes.

2. 2

   Let the service scan, back up and rebuild your records

   It reads your published records and recreates them. Review that list against your inventory and add anything the scan could not see.

3. 3

   Change the nameservers at your registrar

   Replace all existing entries with the name servers you were given. This is the moment the change begins; nothing before it affected your live domain.

4. 4

   Watch your website, not just your mail

   Load the site, the shop checkout and anything on a subdomain within the first hour. Mail is the thing you are changing; the website is the thing that tells you whether the rebuild was complete.

5. 5

   Send a real message once it settles

   Commonly a few hours, occasionally up to two days. A message that actually arrives is the proof; a green tick in a dashboard means the records look right, which is a different claim.

How to undo each choice

All three are reversible, and the difference in how easily is a fair part of the decision.

The two records are removed as easily as they were added: delete the NS set and the CNAME, and the domain is exactly as it was within minutes, because nothing else was ever changed. Scoped access ends the moment you revoke the key, and the records it published remain yours to keep or delete. Moving the whole domain is undone by setting the old nameservers back at the registrar, which works, and takes the same hours to settle as the original change did. That is why the preflight asks you to write down your current nameservers before a full move: it is the one value that turns the reversal into a two-minute job instead of a support ticket.