Setting up Microsoft 365 from scratch

Setting up Microsoft 365 from scratch isn't hard — the wizards see to that. What the wizards don't tell you is that order matters more than speed. Identity before data, security before users, DNS before anything email-shaped. Follow the sequence below and you end up with a clean, secure tenant; improvise the order and you'll redo the identity and security steps later with users already on the platform, which is ten times the work.

This is written for a small-to-mid organisation standing up a tenant for real use. The steps are the same at enterprise scale; the ceremony around each one just grows.

Several steps here have full how-tos: create break-glass accounts, require MFA for all users, block legacy authentication, set up DKIM, publish sensitivity labels, and register devices for Autopilot. The tenant audit checklist is the way to check the result.

0. Decide the plan before you sign up

Pick the licence anchor first — it's easier than fixing it at the first renewal. Under 300 users the answer is almost always Business Premium; the routing logic is in plans and pricing. While you're deciding: buy through a CSP partner or direct, and note that the trial-tenant path is fine — trials convert to paid without rebuilding.

1. Create the tenant — and take the initial domain seriously

Sign-up creates the tenant with an initial yourcompany.onmicrosoft.com domain. Two things about this moment outlast everything else:

• The onmicrosoft name is permanent. It shows up in SharePoint URLs and various corners forever. Spend the thirty seconds to make it sensible.
• The default region is permanent-ish. Tenant data residency follows the country you pick at sign-up. Pick the right one.

If you plan to develop or test against Microsoft 365 later, note that a separate dev tenant is the pattern — see dev/test tenant strategy — but that's a later problem.

2. Add and verify your domain

In the admin center, add yourcompany.com, prove ownership with the TXT record Microsoft issues, then set the records that make services work: MX for mail, SPF, the Autodiscover CNAME, and DKIM as soon as the mailboxes exist. DMARC follows once SPF and DKIM are stable — start at p=none and monitor before enforcing, per the DMARC rollout guide. The record-by-record walkthrough is in domains and DNS setup.

Don't create users on the onmicrosoft domain "just to get going" — renaming principals later is friction you can avoid by doing DNS first. It's the canonical example of why sequence beats speed.

3. Plan identity: cloud-only unless something forces hybrid

If you don't already run on-premises Active Directory, go cloud-only and never look back. If you do run AD, you'll sync it up with Entra Connect or the newer Cloud Sync — the decision between them is in Entra Connect vs Cloud Sync — and your source of truth for user objects stays on-premises until you deliberately decommission it. Decide this before creating users, because unwinding a wrong identity model with live users is the single most painful correction in the platform.

4. Admin accounts before user accounts

Set the admin scheme up while the tenant is empty:

• Two break-glass Global Admin accounts — cloud-only, excluded from conditional access and MFA policies, credentials stored offline, sign-in alerts armed. The full design is in break-glass accounts.
• Named admin accounts with the narrowest role that does the job — role design covers the split.
• No daily driving as Global Admin. Admins get a normal account for email and a separate identity for privilege.

5. Security baseline before the first real user signs in

This is the step most setups do too late. Empty tenant, no users inconvenienced — there is no cheaper moment to be strict:

• MFA for everyone. Security defaults give you this with zero effort; explicit conditional access policies give you control. Start with defaults, graduate to CA when licensing and skill allow — the starter set is in security baselines.
• Block legacy authentication — it's the loophole that bypasses MFA.
• Enable self-service password reset and save the helpdesk from its dullest ticket.

6. Users and licences

Create users (or let sync create them), and assign licences through groups rather than one at a time — even at 50 users, "new starters get the standard bundle by group membership" is the habit that scales. If you went Business Premium, this is the moment to actually switch on what you paid for: the checklist lives in the Business Premium deep dive.

7. Migrate data — after security, not before

With the baseline enforced, move the data: email via IMAP/Google/Exchange migration into Exchange Online, files via the SharePoint Migration Tool or Migration Manager — the planning is in migrating file shares. The order is deliberate: data that lands in a secured tenant is protected from day one; securing a tenant that already holds everything is a retrofit. And decide the backup story now, while "what would we restore?" is still a hypothetical.

8. Roll out clients

Push Microsoft 365 Apps, Teams, and OneDrive — via Intune if you have it (Business Premium does). Turn on Known Folder Move so Desktop and Documents are protected without users doing anything.

9. Write it down

Admin accounts and where break-glass credentials live, the CA policy set and why each exists, the licence layout, DNS records, the backup answer. One page is enough. The tenant you built in a focused week will be maintained in stolen half-hours for years — documentation is how the next half-hour starts from knowledge instead of archaeology.

The shape of it

Tenant, domain, identity model, admins, security, users, data, clients, documentation. Every step leans on the ones before it, which is the whole argument: a Microsoft 365 setup done in the right order is a series of small tasks; done in the wrong order it's the same tasks plus rework with an audience.