Business systems / Checklist
Changing website DNS? Account for the business email first.
A website move can involve changing a web address record, or it can involve moving the domain’s authoritative DNS to another provider. The second change puts more of the domain’s services into the plan.
I want the email setup accounted for before that work starts. People should be able to see which service is changing and which existing records the business still needs.
Be specific about what is moving
Write down whether the job changes the website destination, the DNS provider or the mail provider. Those are different changes, even when someone describes all of them as moving the website.
If email is staying where it is, keep that as an explicit requirement. If the mail service is also changing, plan the accounts, records and verification separately rather than assuming the website cutover takes care of them.
Keep the current records and their purpose
Collect the existing DNS records and identify the website entries, mail-routing records and the authentication records required by the services that send mail for the business. Use the actual providers’ instructions to check the values.
Cloudflare’s email troubleshooting guide covers checking MX answers against the mail provider and reviewing missing SPF, DKIM or DMARC records. Provider-specific details matter, including CNAME records that a service may use.
Keep the record list with a named owner for the change. An automatic scan can be a starting point, but the plan should account for the services the business uses, including ones that are not obvious from the homepage.
Allow for cached DNS answers
Record the current values and TTLs before making the change, and agree what a recovery would involve if the result differs from the plan. The person making the change should know which old and new services need to remain available during that period.
TTL controls how long DNS records are cached. Cloudflare explains that longer caching can delay the visibility of a changed answer, and local caches can take longer than a simple timing estimate suggests.
Avoid promising an instant change for every user. Check the relevant authoritative answers and account for caching when interpreting what different devices or networks report.
Source: Cloudflare: DNS caching and TTL
Agree how each service will be checked
Make the intended result explicit: the website should reach its new destination, and mail records should match the provider the business is keeping or moving to. Check each against the agreed plan.
Plan any sending and receiving checks with approved test addresses and messages. Record what has actually been verified, including the time, so the business has a clear picture of the result.
| Before the change | Evidence to keep |
|---|---|
| Define the scope | Website, DNS and mail changes named separately |
| Identify dependencies | Current records and provider requirements |
| Plan the transition | Owner, values, timing and recovery route |
| Agree verification | Expected answers and authorised service checks |
Bring the current setup to the conversation
Start with the domain and provider details you already have. We can map what is staying and what is moving, then plan the DNS work around those dependencies.
Sources
Checked on 23 October 2026.
- Cloudflare: DNS and email troubleshooting
Check mail routing and authentication records against the provider’s requirements, including service-specific CNAME behaviour.
- Cloudflare: DNS caching and TTL
TTL controls record caching; the time a user observes a change can also be affected by local caches.