SME DNS and Email Checklist NZ
Registrar ownership, DNS exports, SPF/DKIM/DMARC, transactional senders, and a safe change workflow.
Reading path
Domains, DNS, and email
A practical order to work through domain ownership, DNS, website routing, and email authentication. If you are inheriting a business domain, changing providers, or fixing deliverability, start here.
Start here
Get the control points and the rollback plan first
Most outages come from unknown ownership or undocumented changes. The first goal is to map who controls registration, DNS hosting, website routing, and mail delivery, then make changes reversible.
Website Launch Checklist for SME NZ
Canonical URLs, redirects, form delivery, analytics, backups, and post-launch checks that prevent mystery breakage.
What to Do If Your Business Email Gets Hacked
Containment, mailbox rules, MFA, recovery details, and follow-up checks after suspicious access or account takeover.
Routing, DNS and BGP support NZ
Use this when DNS changes, nameservers, TTL, provider routing, partial reachability, or escalation evidence are the real problem.
Email deliverability support NZ
Use this when mail lands in spam, bounces, fails authentication, or needs SPF, DKIM, DMARC, and sender-inventory work.
Microsoft 365 support NZ
Use this when the domain/email issue crosses into tenant admin access, MFA recovery, mailbox rules, or Microsoft 365 DNS records.
Decision path
Choose the page that matches the control point
Domains, DNS, and email problems can look similar from the outside. The useful split is ownership, DNS/routing, deliverability, Microsoft 365 setup, and recovery. Choosing the right path avoids changing records when the actual issue is mailbox access, provider routing, or an unlisted sender.
Ownership and handover
Start with the DNS/email checklist when the registrar, DNS host, nameservers, mail provider, and rollback owner are unclear.
DNS, TTL, and partial reachability
Use the routing/DNS page when the symptom involves nameserver delegation, record changes, resolver cache, propagation, or different results across networks.
Deliverability and authentication
Use the deliverability page when SPF, DKIM, DMARC, bounce messages, spam-folder placement, sender reputation, or third-party senders are involved.
Microsoft 365 setup baseline
Use the setup page for new or inherited tenants: admin accounts, MFA methods, mail DNS, Teams/OneDrive, and handover notes.
Microsoft 365 recovery and support
Use the support page when the problem is sign-in, MFA recovery, mailbox rules, shared mailboxes, admin ownership, or escalation evidence.
Email security and recovery
Use the recovery hub when suspicious access, forwarding, payment-detail changes, or mailbox persistence checks are part of the work.
Ownership map
Separate ownership, routing, and delivery
A domain problem is rarely just one thing. The domain may be registered with one provider, DNS hosted somewhere else, the website served by a third company, and email delivered through Microsoft 365, Google Workspace, or another mail platform.
Domain registration
Confirm the registrar, renewal date, account owner, contact email, and nameserver settings. This is the control point that decides where DNS is hosted.
DNS hosting
Export the current zone before changes. Record A, CNAME, MX, TXT, SPF, DKIM, DMARC, autodiscover, and verification records so rollback is realistic.
Website routing
Check the canonical hostname, redirects, SSL certificate, hosting account, CDN or proxy layer, and form delivery path before moving a website.
Email delivery
List every service that sends as the domain: Microsoft 365, website forms, invoice software, booking systems, CRM tools, and marketing platforms.
Use the path
Work from ownership to delivery
The safest order is not always the order the problem appears in. First confirm who controls the domain registration and DNS zone. Then record the current website host, mail provider, transactional senders, and any third-party systems that send as the domain. Only after that should you change records.
Before a DNS change
Export the zone, screenshot the registrar nameservers, record the current TTLs, and write down the rollback record values.
Before an email change
List every sender that uses the domain, including Microsoft 365, website forms, invoices, booking tools, CRMs, and bulk mail platforms.
Before a website handover
Confirm the canonical domain, SSL certificate, redirect rules, analytics access, form delivery, backups, and who can update DNS quickly.
After the change
Check the live website, contact forms, SPF/DKIM/DMARC alignment, mail delivery, Search Console coverage, and any provider warning banners.
Handover sequence
Make the domain handover boring before changing records
A domain handover is safest when the ownership record, DNS host, mail platform, and website host are all named before anyone changes a TXT, MX, A, or CNAME record. If those facts are missing, the first task is discovery, not migration.
Domain holder known
Registrar access proven
DNS zone exported
TTL plan written
Rollback owner named
Domain holder
Confirm who the domain is registered to, who can authorise registrar changes, and whether billing or recovery details still belong to the business.
Nameserver control
Record the nameservers at the registrar and the dashboard that controls the live DNS zone. Editing the wrong DNS dashboard is a common handover failure.
TTL and timing
Document current TTLs and planned timing. Lowering TTLs before a planned move can make rollback faster, but nameserver and resolver caching still need patience.
Rollback authority
Name the person who can reverse the change, the old record values, and the cutover window where someone will watch website, form, and mail behavior.
Related support
When a domain and routing problem needs hands-on debugging
These pages are the next step when the checklist identifies a real routing or provider problem. They focus on practical diagnostics and clear handover notes rather than vague SEO theory.
Search and launch impact
When DNS or email changes affect website visibility
Domain, DNS, and email work can spill into search visibility when it changes redirects, canonicals, sitemap URLs, contact-form delivery, analytics, verification records, or Search Console ownership. Treat those as launch and technical SEO checks, not just DNS edits.
Technical SEO audit checklist
Use this when DNS or hosting changes affect crawl access, robots rules, canonicals, redirects, sitemap entries, or structured data.
SEO consulting NZ
Use this when Search Console evidence, indexing state, page intent, metadata, or internal links need a controlled cleanup pass.
Websites and search basics
Use the reading path when domain work overlaps with launch checks, measurement, project proof, or search-surface planning.
Launch checklist tool
Use the launch checklist tool to capture canonical URLs, forms, analytics, sitemap, backups, and handover notes after a DNS change.
Maintenance calendar tool
Use the maintenance calendar when DNS, mail authentication, backups, profile accuracy, and sitemap checks need regular review.
Tools hub
Use the tools hub when you need a reusable checklist before changing records, launch settings, or public profile details.
Reference checks
Use official provider guidance for authentication changes
SPF, DKIM, DMARC, and sitemap/canonical changes can look like tiny text edits, but they affect trust, mail delivery, and crawl signals. Use the checklist article for the practical workflow, then verify the final record shape against the active provider's own documentation before publishing changes.
.nz domain ownership
Use InternetNZ context when the handover involves a `.nz` domain, registrar relationship, or domain-holder responsibility.
DNS TTL
Use provider TTL documentation when planning propagation, cache behavior, and rollback timing around DNS changes.
Google Workspace
Check Google's SPF/DKIM/DMARC guidance when Gmail or Google Workspace is part of the sending path.
Microsoft 365
Use Microsoft's DMARC guidance when the domain sends through Microsoft 365 or Defender-managed mail flows.
Microsoft DNS records
Use Microsoft's DNS-record setup guidance when connecting a domain to Microsoft 365 and adding provider-specific records.
Google Search
Use Search Central guidance when sitemap, canonical, or recrawl decisions are part of a website handover.
Local handover
Keep the official links beside the DNS export and change note so the next person can verify why each record exists.
Context
Professional and project evidence
If you need current professional context or software project notes, start with the About page and Projects hub.