Illustrated article hero image for Microsoft 365 SME checklist (NZ).

Technical article

Microsoft 365 SME checklist (NZ)

The goal is boring stability: a tenant you can access, mail that delivers, and a handover path that does not rely on one lost phone.

Microsoft 365 issues usually start as "email is broken" but end up being identity, access, DNS, and device sign-in. This checklist is written for New Zealand SMEs and solo operators who want changes to be reversible and supportable.

1. Confirm who controls the tenant

Before you change anything, confirm where the tenant lives, who is the global admin, and what recovery methods exist. If the tenant was set up by a third party years ago, treat access as a priority item.

Admin accounts

List global admin accounts and confirm they are owned by the business (not a contractor's personal mailbox).

Recovery methods

Record which phone numbers, alternate emails, and authenticator devices are attached to admin accounts.

Billing owner

Confirm who pays the subscription and who can change the plan. Keep proof of purchase and tenant ID.

Evidence pack

Capture screenshots of key settings and an admin contact list so escalation does not start from zero.

2. Identity and MFA: reduce lockout risk

Multi-factor authentication is essential, but it can become a single point of failure if only one phone holds the keys. Aim for redundancy and documented recovery.

Multiple admins

Maintain at least two admin accounts with separate MFA methods so one lost device does not block access.

Authenticator backup

Use the platform's backup and recovery options. Record where recovery codes are stored (securely).

Role separation

Use normal user accounts for daily work. Keep admin accounts for admin work.

Sign-in review

Check recent sign-ins for obvious anomalies and confirm the devices in use are expected.

Admin recovery packet

an SME should be able to answer "who can recover this tenant if the main phone or laptop is gone?" without searching old emails. Keep the packet private, current, and limited to people who genuinely need it.

Emergency access path

Document the backup administrator path, how MFA is protected, and who is allowed to use it. Do not leave it as a mystery account nobody checks.

Tenant identifiers

Record the tenant name, primary domain, billing owner, admin contact, and where support tickets or invoices are stored.

Recovery methods

Record which authenticator apps, security keys, phone numbers, and recovery email addresses are attached to key accounts.

Review rhythm

Check the packet after staff changes, phone replacements, domain changes, billing changes, or any sign-in/security incident.

3. Mailboxes: what "set up" really means

A mailbox is more than a login. Confirm the address policy, aliases, shared mailboxes, and what devices are connected. A calm handover document saves hours later.

  • List all mailbox addresses and aliases (including any "sales@", "info@", and accounting addresses).
  • Record which addresses are shared mailboxes and who has access.
  • Confirm mobile devices, Outlook profiles, and any third-party apps that send mail.
  • Document "where the mail flows" for website forms and transactional senders.

4. DNS and deliverability: SPF, DKIM, DMARC

DNS is where a lot of email problems hide. Export the zone, then make one change at a time. For a broad overview of the control points, use the DNS and email checklist.

SPF

Confirm SPF includes the right senders (Microsoft 365 plus any marketing or invoicing senders). Avoid duplicate SPF records.

DKIM

Enable DKIM where available and confirm the DNS records exist for every domain you send from.

DMARC

Start with monitoring policy, then tighten once you know all legitimate senders are included.

Rollback

Keep a copy of the original DNS zone export and record each change with a timestamp.

DNS change order for Microsoft 365 mail

DNS mistakes can break mail quietly. Before changing MX, SPF, DKIM, DMARC, autodiscover, or verification records, export the current zone, write the intended change, and keep a rollback note.

Map the senders

List Microsoft 365 plus any website forms, invoicing tools, booking systems, CRMs, marketing platforms, and scanners that send as the domain.

Keep one SPF record

Microsoft guidance warns against creating duplicate SPF TXT records. Add legitimate senders into one record instead of publishing several.

Enable DKIM deliberately

Record the DKIM selector CNAMEs and confirm they resolve before relying on DKIM signing for the domain.

Move DMARC carefully

Start with monitoring, review legitimate senders, then tighten policy only when you understand what will pass and fail.

5. Device sign-in and onboarding hygiene

A lot of "Microsoft 365 problems" are actually device enrollment and old cached credentials. Keep onboarding steps consistent and write them down.

  • Confirm Windows/macOS user accounts match the intended work accounts (avoid random personal Microsoft accounts).
  • Check whether devices are joined/enrolled (Azure AD / Entra ID joined, MDM, or unmanaged). Keep it consistent.
  • Document how new staff get set up: account creation, MFA, mailbox, OneDrive/SharePoint access, and device sign-in.
  • Keep a simple "offboarding checklist" so access is removed cleanly when someone leaves.

Official references

Use Microsoft guidance for identity, emergency access, and DNS records

This checklist is an operational guide. Use current Microsoft documentation and professional advice before changing security, administrator access, domain DNS records, or mail authentication settings.

Domain DNS records

Microsoft's domain setup guide covers connecting a custom domain and the DNS records used by Microsoft 365 services.

Microsoft 365 domain DNS records

SPF setup

Microsoft's SPF guidance explains why one SPF TXT record per domain matters and why SPF alone is not a full anti-spoofing strategy.

Microsoft 365 SPF guidance

Professional context

Where this checklist connects to the owned support pages

The stable pattern is: control points first (identity and DNS), then mailbox and device onboarding, then documentation. These owned pages connect the checklist to services, a broader NZ profile, and related technical notes.

Current profile

About John Finnerty links this checklist to the broader support and software work across the owned sites.

Project evidence

The project hub collects public project notes and case studies that sit beside the support material.

DNS and email control points

The DNS and email checklist covers domain ownership, SPF/DKIM/DMARC, and handover-safe change workflow.

Microsoft 365 support

The Microsoft 365 support page describes practical help: identity, tenant access, mail flow, and account recovery planning.

SME IT support

IT support Christchurch covers troubleshooting and handover notes for Microsoft 365, devices, and business email.

Support routing

Route the Microsoft 365 issue to the right next page

A Microsoft 365 checklist often uncovers several possible workstreams. Choose the closest lane before changing DNS, rebuilding devices, removing mailbox rules, or opening provider tickets.

Related services

If you are inheriting an old tenant, recovering access, or stabilising deliverability, these pages describe the support areas this checklist connects to.