Why it matters
Domains and email should not depend on memory
SME email problems often start with unclear ownership: nobody knows where the domain is registered, who controls DNS, which mailbox provider is live, or why a TXT record was added years ago. A short audit turns the domain from a mystery box into a system that can be changed safely.
Control points
Start by mapping who controls each part
A domain can involve several separate providers. The registrar owns the registration, the DNS host answers lookups, the web host serves the site, and the mail provider receives email. Sometimes one company does all of this; often it is split across two or three accounts.
Registrar and renewal
Record the registrar, account owner, renewal date, billing card owner, two-factor method, and recovery email. Renewal failure is still one of the most avoidable domain outages.
DNS host
Identify where the live zone is hosted. Check nameservers at the registrar and confirm the DNS dashboard you are editing is the one the internet is actually using.
Website routing
Document A, AAAA, CNAME, redirect, canonical, and sitemap locations before changing hosting or nameservers. Note whether the site uses apex, www, or both.
Mailbox provider
Confirm the active MX records, mailbox admin login, shared mailbox ownership, aliases, forwarders, and where password resets or verification codes arrive.
Email delivery
Check SPF, DKIM, and DMARC before deliverability breaks
Email authentication records tell receiving systems which platforms are allowed to send mail for the domain. They should reflect what the business actually uses today: Microsoft 365, Google Workspace, website forms, booking systems, invoices, newsletters, CRM tools, or helpdesk software.
SPF
Keep SPF to one TXT record. Include current senders only, remove abandoned services carefully, and check that the lookup count stays below practical limits.
DKIM
Enable DKIM for the mail platform and any bulk-mail service that supports it. DKIM is especially useful when messages are forwarded or handled by several systems.
DMARC
Start with monitoring where appropriate, then tighten policy once legitimate senders are known. Record the reporting address and who reviews failures.
Transactional senders
Website contact forms, invoices, booking reminders, and ecommerce messages are easy to forget. Confirm they authenticate under the business domain or a suitable subdomain.
Official checks
Use provider guidance before tightening policy
SPF, DKIM, and DMARC are provider-specific in the details. an SME should not copy a record from another domain and hope it works. Check the active mail platform, then use that provider's current setup guidance before changing DNS.
Google Workspace
Google's admin guidance recommends setting up SPF, DKIM, and DMARC so Gmail can authenticate mail sent from the domain.
Microsoft 365
Microsoft's guidance treats DMARC as part of validating the From domain and reducing spoofing risk for cloud senders.
DMARC monitoring
Start with reporting where appropriate so legitimate senders can be identified before moving toward stricter policies.
Change control
Record the old TXT records, intended new records, sender list, owner, and rollback note before publishing authentication changes.
Change safety
Make every DNS change reversible
DNS changes are small text edits with large consequences. Before changing a record, export the current zone, take screenshots, record the old value, and write down the exact reason for the change. For planned migrations, lower TTLs early enough that rollback is not trapped behind long caches.
Before the change
Capture old records, confirm access to both old and new providers, check backup contact paths, and schedule the change outside peak enquiry hours where possible.
During the change
Change one layer at a time when you can. Test public DNS lookups, website loading, mail receiving, mail sending, and contact-form delivery from outside the office network.
After the change
Monitor bounce messages, spam-folder placement, SSL state, redirects, analytics, and Search Console coverage. Keep old hosting or mail access until the new path is proven.
Handover
Leave a simple record: what changed, why it changed, who approved it, how to reverse it, and where the current credentials live.
A sensible handover checklist
A handover should make the next change boring: domain access confirmed, DNS exported, mailbox provider known, billing visible, recovery email current, and a plain-English note explaining how the pieces fit together.
Professional context
Where this fits in current support work
This checklist sits alongside John Finnerty's broader Christchurch and New Zealand technical work: practical DNS, email, website, and handover support for small teams that need clear ownership and recoverable systems.
Current profile
About John Finnerty connects this article to the wider software, support, and technical consulting profile.
Project evidence
The project hub shows public web and software work that uses the same evidence-led approach.
Local relevance
The Christchurch profile explains the local service context for practical business technology support.
Related reading
The website launch checklist covers the site-side checks that often sit beside DNS and email work.
Related services
DNS, email, and SME support
If you need help making domain and email ownership boring again, start with the services overview and the IT support page. For deeper DNS escalation context, the DNS and routing page lists the kind of evidence providers expect.