Microsoft 365 security: a hardening order for a small tenant

A small Microsoft 365 tenant ships with reasonable defaults and a very large number of settings. The usual failure is not a missing feature; it is a long list of things that could be done with no sense of which ones come first. This guide gives an order, explains what each step is protecting against, and tells you how to find the setting in your own tenant rather than pointing at menus that Microsoft rearranges.

Product names, plan names and portal layouts change. Where a fact depends on your licence or on current product behaviour, this guide says how to check it rather than asserting it.

Know what you are licensed for

Almost every “should I turn this on” question is answered by licensing first. The broad picture, to be confirmed against Microsoft’s current licensing documentation for your plan:

• Every Exchange Online mailbox is covered by Exchange Online Protection, the baseline spam, malware and basic phishing filtering.
• Defender for Office 365 adds more: safe links and attachment handling, and stronger anti-phishing and impersonation protection. It is sold as Plan 1 and Plan 2, and some business bundles include Plan 1. Check whether yours does.
• Conditional Access and several identity protection features come with Microsoft Entra ID plans above the free tier. Some business bundles include the P1 level.
• If you have none of the above beyond the basics, the free tenant-wide baseline called security defaults is the minimum worth having. It and Conditional Access are alternatives: you cannot run both at once.

Find your actual entitlements in the admin centre’s subscriptions and licences pages, not in a price list. Write down what you find; the rest of your plan depends on it.

A hardening order for a small tenant

The sequence below is ordered by the amount of attacker capability each step removes per hour of your effort. It is not exhaustive and it is not a certification checklist.

Step	What you do	Attack it addresses
1	Protect administrator accounts: MFA, separate admin accounts, few of them	Takeover of the whole tenant
2	Require MFA for everyone	Password theft and reuse
3	Block legacy authentication	MFA bypass through old protocols
4	Block automatic external forwarding	Quiet mail exfiltration, persistence after reset
5	Publish SPF, enable DKIM, move DMARC to enforcement	Spoofing your own domain
6	Turn on anti-phishing and impersonation protection	Targeted impersonation of named people
7	Restrict app consent	Consent phishing
8	Check auditing and set alerts	Being blind during an incident

1. Administrator accounts

Every administrator role is a route to changing mail flow for everyone. Keep the number of administrators as small as you can while keeping at least two people able to recover the tenant. Give each administrator a separate account for administration, with no day-to-day mailbox use, and require MFA on it before anything else. Prefer the most specific role that does the job rather than the all-powerful Global Administrator role. Create emergency access accounts as described in conditional access, so that a policy mistake cannot lock everyone out.

2 and 3. MFA, and legacy authentication

MFA that exists but can be skipped is not MFA. Legacy protocols such as basic-authentication IMAP, POP and older SMTP submission cannot present a second factor, so an attacker with a stolen password can use them to avoid the prompt entirely. Microsoft has turned off basic authentication for most Exchange Online protocols over the years, but your tenant may still have exceptions, and SMTP submission in particular has had a longer timeline; check current Microsoft announcements and your own sign-in logs instead of assuming.

To see whether legacy sign-in is still happening, look at the Entra sign-in logs filtered by client app. If a scanner or an old line-of-business application appears there, you have found something to migrate before you block it, which is why discovery comes before enforcement.

4. Automatic external forwarding

Attackers create forwarding rules so they keep receiving mail after you reset the password. The outbound spam policy has a setting for automatic forwarding. Check its current state without changing anything:

Connect-ExchangeOnline
Get-HostedOutboundSpamFilterPolicy | Select-Object Name,AutoForwardingMode

The values are Automatic, On and Off. Automatic is system-controlled and, in current tenants, generally behaves as off for external recipients, but confirm that for yours. Then look for forwarding that was already set on individual mailboxes:

Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object DisplayName,ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Every line this prints is a question to ask: who set it, and is it still needed? Legitimate forwarding exists. Unexplained forwarding is an incident until proven otherwise.

5. Your domain’s records

Mail platforms hand you most of what you need to publish, but you still have to publish it in DNS and then verify. For Microsoft’s servers an SPF record includes the Microsoft SPF host. DKIM signing for a custom domain is switched on per domain and uses two selectors published as CNAME records, which lets Microsoft rotate the keys. To read the state of DKIM for a domain:

Get-DkimSigningConfig -Identity example.com | Format-List Domain,Enabled,Selector1CNAME,Selector2CNAME

Enabling signing changes how outgoing mail is signed, so do it after the CNAME records are published and visible. DMARC is the part that is entirely yours: it is a DNS record, and it takes a staged rollout. The details, the arithmetic and the safe order are in SPF, DKIM and DMARC. Remember that your tenant’s onmicrosoft.com domain is also a sending domain, and attackers notice domains with no policy.

6. Anti-phishing and impersonation protection

If your plan includes Defender for Office 365, look at the preset security policies, usually offered as a Standard and a Strict level, and at the anti-phishing policy’s impersonation settings. The useful concepts are:

• User impersonation protection: name the handful of people whose identities attackers will forge, typically owners, executives and finance leads, so messages that imitate them are treated with suspicion.
• Domain impersonation protection: protect your own domains and any look-alike domains you know about.
• Mailbox intelligence: use the history of who a user normally corresponds with to judge whether a sender is unusual.

Apply a preset first, then adjust. Test with a harmless message from an outside account to yourself and confirm what happens.

7. Application consent

A malicious application that a user approves gains lasting access to mail and files, with no password and no MFA prompt afterwards. Look in the Entra settings for user consent to applications and for the admin consent workflow. A common safe configuration is to stop users consenting to anything beyond low-risk permissions and to route requests to an administrator. Then review what already holds mail permissions in your tenant; the list is often longer than anyone expects.

8. Auditing and alerts

Mailbox auditing is on by default for Exchange Online mailboxes, and the unified audit log records administrator and user activity. What differs between tenants is how long entries are kept, which depends on licensing, and whether anyone has ever searched them. Do one practice search now. Create alerts for the high-signal events: a new forwarding rule, a new inbox rule that deletes mail, a new administrator role assignment, and a sign-in from an administrator account at an unusual time.

Secure Score: a to-do list, not a verdict

Microsoft’s Secure Score gives your tenant a number and a ranked list of suggested improvements. It is useful as a backlog, because the suggestions are specific and tied to your licences. It is not proof that you are secure, and chasing the number can lead you to turn on settings that do not matter while skipping process controls it cannot measure, such as verifying payment changes by phone. Use the list; ignore the number as a goal.

Settings that bite when you change them

Change	The trap	How to de-risk it
Block legacy authentication	A scanner, multifunction printer or old application stops sending	Find users of legacy sign-in in the logs first
Require MFA for all	Service accounts and shared mailboxes with passwords stop working	Convert to modern authentication or use a managed identity before enforcing
Block external forwarding	A real business process that forwards to a partner breaks	List current forwarding first; create a documented exception route
DMARC reject	A forgotten sender’s mail is refused	Run p=none with reports for long enough
Restrict consent	Staff cannot connect an approved tool	Set up an admin approval route and tell people it exists

How this fails

• Security defaults forever. They are a good baseline but cannot express exceptions. Many organisations outgrow them without noticing.
• A policy lockout. Strict access policy with no emergency account. When the policy is wrong, nobody can fix it.
• Shared mailboxes with passwords. They are mailboxes that can be signed into with an ordinary account. Block interactive sign-in for shared mailboxes and give people delegated access instead.
• Trusting defaults without reading them. A setting that is “automatic” or “system-controlled” is a decision someone else made, possibly under a different threat model from yours.
• Fixing the tenant and ignoring the DNS. A hardened tenant whose domain has no DMARC policy can still be impersonated.
• Alert fatigue. Dozens of alerts nobody reads. Start with a few that always mean “look now”.

What to do next

Spend an hour on a read-only survey: licences, administrator list, legacy sign-in in the logs, forwarding, DKIM state. Then use the email security readiness assessment to turn the survey into an order of work. When you are ready to enforce sign-in rules, read conditional access, and when you want to know where attackers hide once they are inside, read mailbox security.