Choose an email service and create the required mailboxes there. Then publish its exact MX and authentication records at your current DNS host. Registering a domain alone does not create an inbox.
Before you begin
- An email service with the required mailboxes or forwarding addresses
- The provider’s current MX and authentication instructions
- Access to the DNS host for your current nameservers
- A migration plan if the domain already receives email
Create the email service first
Decide whether you need a full mailbox, forwarding or another mail service. Create the addresses at that provider before redirecting incoming mail. Domain registration and DNS management do not include a mailbox by themselves. NameUK domain registration does not include an email-hosting package.
Verify the domain with the provider
The email service may ask for a verification TXT or CNAME record. Add exactly what its account setup screen supplies at the domain’s current DNS host. Verification checks control of the domain; it does not by itself route mail or create users. Follow the provider’s confirmation step before changing incoming mail.
Add the provider’s MX records
MX records direct incoming email to mail servers. Copy every required server name and its priority. Lower priority numbers are preferred. The target is a hostname, not an email address or an IP address. Replace the previous provider’s MX set only at the planned switchover; mixing providers is not a mailbox migration.
Sources: Cloudflare: setting up email records ↗ · Cloudflare: MX and authentication record types ↗
Review the sending authentication records
SPF lists authorised sending services. DKIM lets the mail service sign messages so recipients can verify them. DMARC defines how receivers should handle messages that fail the relevant checks. These serve different purposes from MX records and do not create inboxes.
| Record | Purpose |
|---|---|
| MX | Route incoming messages |
| SPF (TXT) | Identify authorised senders |
| DKIM (TXT or provider-specified CNAME) | Publish the provider’s signing-key information |
| DMARC (TXT) | Publish an authentication policy |
Sources: Cloudflare: MX and authentication record types ↗ · Gmail: email authentication guidance ↗
Include every legitimate sender
Your mailbox service may not be the only sender: website forms, invoices or mailing tools can use the same domain. A domain has one SPF policy, which can include multiple authorised services. Ask the mail provider to help combine required senders with the existing policy. Do not add a second SPF policy or remove unrelated TXT records.
Sources: Google Workspace: SPF records ↗
Plan existing-mailbox moves separately
Changing MX records does not copy old messages, contacts or calendars. Agree the data migration and switchover with the email provider. Keep access to the old service while checking the new one. Cached DNS answers can continue pointing to the old mail route during the transition. Protect website records when changing only email.
Test receiving and sending
Send a message from an unrelated external mailbox to each important address and send a reply back. Check the provider’s authentication results and any delivery errors. Authentication improves verification but cannot guarantee inbox placement. If mail fails, give support the domain, affected address, time and error message; never include mailbox passwords, private signing keys or API credentials.
Extension rules and provider processes can change. Check the current registrar instructions before a registration, transfer or renewal.
Check the domain before changing email
Your dashboard shows domain controls and request history. Keep the email provider’s current instructions beside you when making changes.