M365 Security Baselines: What Your Tenant Is Missing

Policy 1: Require MFA for all users

Not just admins. Everyone. Microsoft's own data shows that MFA blocks 99.9% of automated attacks. The most common objection is "our users will complain." They will complain more when their mailbox is compromised and the CEO's wire transfer instructions turn out to be from an attacker in Lagos.

Use Security Defaults as a minimum if you do not have P1 licensing, but conditional access policies give you far more control. Exclude a break-glass account (and monitor it heavily).

Policy 2: Block legacy authentication protocols

Legacy auth protocols — IMAP, POP3, SMTP AUTH, Exchange ActiveSync with basic auth, and Exchange Web Services with basic auth — do not support MFA. An attacker with a valid username and password can authenticate via IMAP even if the user has MFA enabled on their account. This is not a bug; it is how the protocols work.

Create a conditional access policy that targets all users, all cloud apps, and blocks the "Other clients" condition. This catches all legacy auth protocols. Test with report-only mode first — you may have a multifunction printer or an old app still using basic SMTP auth.

Policy 3: Require compliant or hybrid-joined devices

If you have Intune or hybrid Azure AD join deployed, add a policy that requires devices accessing Office 365 apps to be compliant or domain-joined. This prevents access from unmanaged personal devices, kiosk machines, and attacker-controlled endpoints. For BYOD scenarios, use app protection policies as an alternative grant.

Audit your current state with PowerShell

Before creating new policies, audit what exists. Many tenants have stale or conflicting conditional access policies from previous admins.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.Read.All"

# List all Conditional Access policies with their state
Get-MgIdentityConditionalAccessPolicy | Select-Object `
  DisplayName, State, CreatedDateTime, ModifiedDateTime |
  Format-Table -AutoSize

# Check for policies in report-only mode (common leftover)
Get-MgIdentityConditionalAccessPolicy |
  Where-Object { $_.State -eq "enabledForReportingButNotEnforced" } |
  Select-Object DisplayName

Check MFA registration status across users

Before enforcing MFA, identify who has not registered yet. Rolling out MFA enforcement without a registration campaign leads to locked-out users and a flooded helpdesk.

# Get MFA registration details for all users
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","User.Read.All"

# Pull authentication method registration status
$Users = Get-MgUser -All -Property DisplayName, UserPrincipalName, Id
$Report = foreach ($User in $Users) {
  $Methods = Get-MgUserAuthenticationMethod -UserId $User.Id
  [PSCustomObject]@{
    DisplayName       = $User.DisplayName
    UPN               = $User.UserPrincipalName
    MethodCount       = $Methods.Count
    HasMFA            = ($Methods.Count -gt 1)  # Password = 1, MFA = 2+
  }
}

# Show users without MFA registered
$Report | Where-Object { -not $_.HasMFA } |
  Sort-Object DisplayName |
  Format-Table -AutoSize

SPF, DKIM, and DMARC records

These three DNS records work together to prevent domain spoofing. SPF declares which servers can send email for your domain. DKIM cryptographically signs outbound messages. DMARC tells receiving servers what to do when SPF or DKIM fails. Without all three, anyone can send email that looks like it came from your domain.

# SPF record — add as TXT record on your domain
v=spf1 include:spf.protection.outlook.com -all

# DKIM — enable via Exchange Admin Center or PowerShell
# Two CNAME records are required per domain:
selector1._domainkey.contoso.com → selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com → selector2-contoso-com._domainkey.contoso.onmicrosoft.com

# DMARC record — start with monitoring, then enforce
# Phase 1 (monitor):
v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com; pct=100

# Phase 2 (quarantine after reviewing reports):
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@contoso.com; pct=100

# Phase 3 (reject — full enforcement):
v=DMARC1; p=reject; rua=mailto:dmarc-reports@contoso.com; pct=100

Anti-phishing policies in Defender for Office 365

If you have Microsoft Defender for Office 365 (Plan 1 or 2), configure these anti-phishing settings. The defaults are intentionally conservative — Microsoft errs on the side of not blocking legitimate mail, which means phishing gets through.

Safe Links and Safe Attachments

Safe Links rewrites URLs in email messages and checks them at click time — not just at delivery time. An attacker can send a clean URL and weaponize it after delivery. Safe Attachments detonates attachments in a sandbox before delivering them. Enable both for all users, and enable Safe Attachments for SharePoint, OneDrive, and Teams as well.

Mailbox forwarding rules: The #1 BEC persistence mechanism

After compromising an account, the first thing an attacker does is create a forwarding rule. This lets them silently receive copies of all incoming email even after you reset the password and enable MFA. Check for these regularly.

# Connect to Exchange Online
Connect-ExchangeOnline

# Find mailboxes with external forwarding (SMTP forwarding)
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -ne $null } |
  Select-Object DisplayName, UserPrincipalName, ForwardingSmtpAddress,
    DeliverToMailboxAndForward |
  Format-Table -AutoSize

# Find inbox rules that forward or redirect externally
$Mailboxes = Get-Mailbox -ResultSize Unlimited
foreach ($mbx in $Mailboxes) {
  $Rules = Get-InboxRule -Mailbox $mbx.UserPrincipalName -ErrorAction SilentlyContinue |
    Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo }
  if ($Rules) {
    foreach ($rule in $Rules) {
      [PSCustomObject]@{
        Mailbox     = $mbx.UserPrincipalName
        RuleName    = $rule.Name
        ForwardTo   = $rule.ForwardTo -join ";"
        RedirectTo  = $rule.RedirectTo -join ";"
        Enabled     = $rule.Enabled
      }
    }
  }
} | Format-Table -AutoSize

Enable mailbox audit logging for all mailboxes

Since January 2019, Microsoft enables mailbox auditing by default for new mailboxes. But mailboxes created before that date, or mailboxes where auditing was manually disabled, may not have it. Verify and enforce across the tenant.

# Check which mailboxes do NOT have audit logging enabled
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.AuditEnabled -eq $false } |
  Select-Object DisplayName, UserPrincipalName, AuditEnabled |
  Format-Table -AutoSize

# Enable auditing on all mailboxes that have it disabled
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.AuditEnabled -eq $false } |
  ForEach-Object {
    Set-Mailbox -Identity $_.UserPrincipalName -AuditEnabled $true
    Write-Host "Enabled audit logging for $($_.UserPrincipalName)"
  }

# Verify the default audit actions are comprehensive
Get-Mailbox -Identity "admin@contoso.com" |
  Select-Object AuditAdmin, AuditDelegate, AuditOwner

Configure alert policies for critical events

M365 ships with some default alert policies, but they are limited. Create custom alerts for the events that matter most in a breach scenario.

Extend audit log retention

The default 90-day retention is not enough for compliance or incident response. Most security frameworks (NIST, CIS, SOC 2) require at least one year. If you have E5 or E5 Compliance add-on licensing, you can configure up to 10 years of retention.

# Connect to Security & Compliance PowerShell
Connect-IPPSSession

# Create a 1-year retention policy for all audit records
New-UnifiedAuditLogRetentionPolicy `
  -Name "1-Year Audit Retention" `
  -Description "Retain all audit logs for 365 days" `
  -RetentionDuration TwelveMonths `
  -Priority 100

# Verify the policy was created
Get-UnifiedAuditLogRetentionPolicy | Format-Table Name, RetentionDuration, Priority

Tighten sharing settings

At minimum, disable anonymous sharing links and restrict external sharing to authenticated users from specific domains. Here is how to check and configure the settings via PowerShell.

# Connect to SharePoint Online
Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

# Check current tenant-level sharing settings
Get-SPOTenant | Select-Object `
  SharingCapability,
  DefaultSharingLinkType,
  FileAnonymousLinkType,
  FolderAnonymousLinkType,
  RequireAcceptingAccountMatchInvitedAccount

# Restrict to authenticated external users only (no anonymous links)
Set-SPOTenant -SharingCapability ExternalUserSharingOnly

# Set default link type to "Specific people" instead of "Anyone"
Set-SPOTenant -DefaultSharingLinkType Direct

# Require external users to accept sharing invitation with same account
Set-SPOTenant -RequireAcceptingAccountMatchInvitedAccount $true

# Optional: Restrict sharing to specific domains
Set-SPOTenant -SharingDomainRestrictionMode AllowList `
  -SharingAllowedDomainList "partnercorp.com vendorco.com"

Enable DLP policies for sensitive files

Data Loss Prevention policies can detect and block sharing of files containing sensitive information like credit card numbers, Social Security numbers, or health records. Start with the built-in sensitive information types and add custom patterns for your industry.

Guest access policies

By default, anyone in your organization can invite external guests to Teams. Those guests then get access to the team's channels, files, and chat history. Tighten this down.

Meeting policies

Default meeting settings allow anonymous users to join meetings, bypass the lobby, and present content. For internal meetings this might be acceptable, but for an organization handling sensitive information, lock it down.

Third-party app restrictions

Teams supports third-party apps that can access messages, files, and user data. By default, users can install any app from the Teams store. This is the consent phishing vector applied to Teams instead of email.