What should I check before pointing my domain at an email service?

Why a preflight, and not just a backup

A domain is not only your email. For most small businesses it is also the website, sometimes a shop, an appointment booker, a payment processor's verification, and a mailing list that was set up years ago by somebody who has left. All of that is held in one place — the domain's DNS zone — and email work touches that same place.

The failures people report after an email move are almost never about email. They are: the website went blank, the online shop stopped taking payments, a verification badge disappeared. Each one is the same root cause — a record that existed before was not carried across, and nobody wrote it down while it still worked.

A backup of your DNS is only useful if you notice something is missing. A written inventory is useful because it tells you what to look for.

The five things to write down

Open your registrar's DNS page — the place you would go to add a record — and copy the following into a text file. Do not change anything yet.

1. 1

   Every record that points at your website

   Look for A, AAAA or CNAME records whose name is @ (the bare domain) or www. These are what make your site load. There may be others for a blog, a shop or a landing page tool — copy all of them.

2. 2

   Your current MX records

   MX records say where mail for the domain is delivered. Each one has a priority number and a hostname. Copy both. If there are no MX records at all, nobody currently receives mail on this domain, which is useful to know and makes the move simpler.

3. 3

   Your SPF record

   One TXT record on the bare domain starting v=spf1. There must never be two — that is itself a fault, and if you find two, you have found a problem that already exists. Copy the whole line.

4. 4

   Ownership proofs left by other services

   TXT records that look like a long random string or something-site-verification=…. Each one is a service proving you own the domain: a search console, a payment processor, a shop platform. Deleting one silently un-verifies that service, often without an email to tell you.

5. 5

   Your current nameservers

   Usually shown on the domain's overview page rather than the DNS page, as two or more ns1.…/ns2.… hostnames. This is the single value you need in order to undo a move, so copy it even if you are certain you will not need it.

What each finding means for the move

Now read your list back. Every entry falls on one side of a single line — either it has nothing to do with mail and must survive the move untouched, or it describes mail and is the thing you are deliberately changing.

If you found two SPF records

Fix that first, and treat it as a discovery rather than an inconvenience. The specification allows exactly one SPF record per domain; when a receiving server finds two it is entitled to treat the check as permanently broken, and many do. Two SPF records usually means two services were set up years apart and neither knew about the other. They must be merged into a single record that lists both — not stacked.

If you found no MX records

Then nothing currently receives mail on this domain, and the whole move is much lower risk: there is no live mail flow to interrupt and no cutover to time. This is the common case for a domain bought for a website, or a name registered and parked.

The order that keeps mail flowing

If the domain currently receives mail that somebody depends on, the sequence matters more than the speed. Changes to DNS are not instant everywhere at once: the internet caches answers for as long as each record's time-to-live says to, so for a period both the old and new answers are in circulation.

What a scan does, and what it cannot see

Any competent service will offer to scan your domain and read its public records before you commit to anything. Ours does, it is free, and it changes nothing — it reads the same public data any mail server can read. That scan will find your website records, your MX, your SPF and the ownership proofs that are published.

It is worth being precise about the limits, because an automatic scan that is trusted too far is how records get lost. A scan reads what the domain publishes now. It cannot see a record that was configured to be private, it cannot know that a subdomain points at a service you are about to stop paying for, and it cannot tell which of two similar records is the one that matters to you.

Treat an automatic scan as a very good first draft of your inventory, and your own ten minutes as the review of it. The scan is faster than you; you know things it does not.