Mutiny Support & Educationa resource for the people we build for
Support & Education For whoever owns the admin console Paths verified 16 August 2026

You bought the
platform. You did not
buy the settings.

Both Microsoft 365 and Google Workspace ship with most of the protections people assume they are paying for either switched off, or sitting behind a tier they did not buy. Neither vendor is hiding this. It is written down, in public, in pages nobody opens.

This is the gap between “we have Microsoft” and “we are protected.” It closes with a settings list and a tier check, both of which are below, ranked by how much risk each one removes per minute you spend on it.

Go to the checklist ↓
Paths verified 16 August 2026 ↳ admin consoles move things. If a path has drifted, search the setting name rather than the menu.
Every path here was read on a live vendor page, not remembered.
Where a vendor documents that a default exists but never names it, we say so instead of guessing. Where we could not verify something at all, it is not on this page.

Ten settings,
in order.

↳ ranked by risk reduced per minute spent

This is the list we work through with a client on either platform. It is ordered, not grouped: if you only get through the first four, you have removed most of what would have caused a real incident. Every path is dated to the stamp above, and where only one vendor has the problem, only one column appears.

Show ↳ 0 of 10 ticked off
1

Turn on an MFA baseline.

Not a per-user rollout, not a pilot: an org-wide floor that a new hire lands inside on day one. Both vendors are moving toward making this mandatory anyway, so the only question is whether it happens on your schedule or theirs.

Microsoft 365

Turn on security defaults, which is free on every tier: Entra admin center > Entra ID > Overview > Properties > Manage security defaults

It enforces six things, including MFA registration for all users, MFA for administrators across 16 roles, blocking legacy authentication and blocking device code flow. Tenants created on or after 22 October 2019 have it on already, with a 24-hour grace period, and the 14-day MFA-registration grace period was removed on 29 July 2024. From 1 July 2026, new tenants also block device code flow.

On Business Premium you can go further with Conditional Access, but read the sequencing: Microsoft’s documentation states that organizations choosing Conditional Access policies to replace security defaults “must disable security defaults.” Start any Conditional Access policy in Report-only.

Also worth knowing, and new enough that most material misses it: Baseline Security Mode is configurable on all Microsoft 365 subscriptions and plans, at Settings > Org Settings > Security and Privacy tab > Baseline Security Mode It carries org-wide switches to block basic authentication, block legacy auth flows, restrict end-user consent, and disable organization-wide access to Exchange Web Services. Unlike Microsoft-managed policies, the Conditional Access policies it creates are “created by the administrator, not Microsoft.”

Google Workspace

Google ships no security-defaults equivalent. Its model is opt-in configuration, and 2-Step Verification enforcement defaults to Off. You turn it on at Menu > Security > Authentication > 2-step verification

Set Enforcement to On, and set Methods to “Any except verification codes via text, phone call.” That second choice is the one that matters: Google’s own documentation says “Text messages are discouraged—They rely on external carrier networks and might be intercepted,” and that “Security keys are the most secure form of 2SV and protect against phishing threats.”

Give yourself a landing strip with New user enrollment period, which runs from one day to six months, before enforcement bites.

2

Get admins onto phishing-resistant credentials, and fix break-glass.

Administrator accounts are the ones worth stealing, and the ones most likely to be locked out by your own policy at the worst possible moment. Both problems get solved in the same sitting.

Microsoft 365

Microsoft’s guidance has genuinely shifted, and most published advice on this is now wrong. The page is titled “Manage emergency access admin accounts,” and it asks for both things at once: use a passkey (FIDO2), which is the recommended method, or certificate-based authentication, because “These methods satisfy the mandatory multifactor authentication requirements”; and still keep the account “excluded from any Conditional Access policy that blocks or restricts sign-in.”

The load-bearing correction: mandatory MFA is enforced server-side and applies “regardless if they are a student account, break-glass account,” and “If you configured exceptions or exclusions in the policy, they no longer apply.” A Conditional Access exclusion no longer buys an MFA exemption. It is now purely availability insurance against your own blocking policies.

The rest of the shape: two or more emergency accounts, never three; cloud-only on the .onmicrosoft.com domain; PIM assignment permanent active, not eligible; credentials split across “separate, secure, fireproof locations”; validated at least every 90 days; and an alert on every single sign-in.

Report-only policies need no exclusion. Note also that PIM itself requires Entra ID P2 or Entra ID Governance, not P1, which is a frequent and expensive misreading of the pricing page.

Google Workspace

Google’s rule is “Your organization should have more than one super administrator account, each managed by a separate individual”, plus “Don’t use a super admin account for daily activities” and “Don’t stay signed in to a super admin account.” Google’s own worked example is two accounts for one person: an admin-maria@ and a maria@.

The recovery default has changed, and this is the item most likely to be stale in whatever you read last. Google states: “For most current and all new customers, super admin account recovery is off by default. If you’re an existing customer with fewer than 3 super admins or 500 users, the setting is on by default, to match previous behavior.” The toggle is at Security > Authentication > Account recovery > Super admin account recovery, as the checkbox “Allow super admins to recover their account.” Google’s recommendation is “Turn off account self-recovery” where you have multiple admins who can help each other back in.

One thing to keep straight, because it looks like a contradiction and is not: Google’s small-business checklist also says “Admins should add recovery information to their account.” That is personal recovery contact information, a different object from the super-admin self-recovery toggle above. Both statements are correct at the same time.

On enforcement: Google is now requiring 2SV on administrator accounts, “rolled out gradually over the coming years,” currently implemented for Education, Nonprofits, Cloud Identity, Android Enterprise, and Enterprise editions using third-party SSO. Super admins get roughly 90 days’ notice, other admins roughly 60, with a lockout ladder at 7, 15 and 30 days, and “If an admin cannot enable 2SV, the only solution is to remove their admin rights.” Business Starter, Standard and Plus are not named in the current wave and Google states no date for them. Read that as coming with the timing unstated, not as not applying to you.

Note also that the Advanced Protection Program, at Menu > Security > Authentication > Advanced Protection Program, cannot be forced onto anyone. It is self-enrollment behind an admin on/off gate. Do not plan around mandating it.

3

Microsoft only: turn on the Standard preset security policy.

This is the largest single gap between what a Business Premium customer thinks they bought and what is actually running in their tenant. It is a two-minute job. The full detail is below ↓

Microsoft 365

In a stock Business Premium tenant, user and domain impersonation protection is off, along with mailbox intelligence protection and the first contact safety tip. Impersonation protection is the control that catches chief-executive fraud, and it is not running until somebody turns on a preset.

Email & collaboration > Policies & rules > Threat policies > Preset Security Policies in the Templated policies section. Turn on Standard protection and scope it to all recipients.

4

Close the OAuth consent hole.

This is the modern version of a stolen password, and it survives a password reset. A third-party application holding a token can read mail and files long after the person who approved it has left. The consequence case is below ↓

Microsoft 365

The good news first: the default has changed. Microsoft states that “The setting labeled ‘Let Microsoft manage your consent settings,’ the Microsoft managed policy, will update with Microsoft’s latest recommended default consent settings. This is also the default for a new tenant.” Under that policy, users may consent to most delegated permissions except a long blocklist covering the Mail.*, Files.*, Sites.*, Calendars.* and Chat.* scopes and the Exchange *.AccessAsUser.All scopes.

Confirm you are actually on it at Enterprise apps > Consent and permissions > User consent settings, and turn on the request path at Enterprise apps > Consent and permissions > Admin consent settings, which reads “Users can request admin consent to apps they are unable to consent to.”

Be aware that one Microsoft how-to page still carries the old legacy default, stating “By default, all users are allowed to consent to applications for permissions that don’t require administrator consent.” The more recently reviewed policy page is the one to trust. Risk-based step-up consent is on by default, surfacing as error AADSTS90094, and is configurable only through the Graph beta endpoint rather than any portal toggle.

Google Workspace

This is Google’s single most consequential permissive default. At Menu > Security > Access and data control > API controls > Manage App Access, the “Unconfigured third-party apps” setting defaults to “Allow users to access any third-party apps.” Google does not block unconfigured apps by default, and as of 16 August 2026 we found no page announcing a change to that.

Apps can be set to Trusted, Limited, Specific Google data or Blocked. Move the unconfigured default off “allow everything,” then allowlist what your business actually runs. Google’s own checklist says the same thing: “Create an allowlist that specifies which third-party apps can access core Google Workspace services.”

An approval workflow shipped on 14 August 2025, on by default at the organizational-unit level, but read it precisely: it layers a request path on top of the existing behaviour. It is not a change to the block default.

5

Fix email authentication, and check DKIM specifically.

Half security control, half commercial necessity: the bulk-sender rules at both Gmail and Outlook.com now decide whether your invoices arrive at all. The DKIM default that catches people is below ↓

Microsoft 365

DKIM has moved out of the Exchange admin center entirely. It now lives at Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM and no Exchange admin center path remains.

For SPF, Microsoft publishes v=spf1 include:spf.protection.outlook.com -all and states “For Microsoft 365 domains, we recommend -all (hard fail).” Inbound, the setting “Honor DMARC record policy when the message is detected as spoof” is on by default, sending p=quarantine to Quarantine and p=reject to Reject. If your MX record points at a third party in front of Microsoft 365, that only applies with Enhanced Filtering for Connectors enabled. Microsoft does not send DMARC forensic reports.

On sending volume: from 5 May 2025, senders of more than 5,000 emails a day to consumer hotmail.com, live.com and outlook.com addresses must pass SPF, pass DKIM, and publish DMARC at minimum p=none aligned with one of them, and “Safe Sender list won’t be honored.” Microsoft’s own page is internally inconsistent about what happens to non-compliant mail today: the body describes junk-foldering with rejection coming, while an April 2025 banner describes rejection with 550; 5.7.515 from 5 May. Treat junk-foldering as the documented floor and rejection as announced, rather than assuming your mail is being rejected right now.

Google Workspace

DKIM is at Apps > Google Workspace > Gmail > Authenticate email, offering 2048 or 1024 bit keys with a default selector of google. As of 16 August 2026, no Google page states which key length is the default, and none states that Google applies automatic DKIM signing before you configure it.

For SPF, Google publishes v=spf1 include:_spf.google.com ~all and states “Google recommends you use ~all in your SPF record.”

That is a genuine, teachable divergence: Microsoft recommends a hard fail, Google recommends a soft fail. If you send from both, pick one policy deliberately and know which vendor’s advice you are declining.

For DMARC, Google’s sequence is to get SPF and/or DKIM working first, wait 48 hours, start at p=none, and move to quarantine and then reject over time. On volume: from 1 February 2024, senders of more than 5,000 messages a day to Gmail need SPF and DKIM, a DMARC record (enforcement may be p=none), From: alignment with SPF or DKIM, one-click unsubscribe per RFC 8058, and a spam rate below 0.30% with a recommendation to stay below 0.10%. Every sender, at any volume, needs SPF or DKIM, valid forward and reverse DNS, and TLS.

One correction while you are here: Yahoo’s requirements still stand and carry no 5,000-a-day threshold on their page. If you see that number attributed to Yahoo, it did not come from them.

6

Set external sharing defaults deliberately.

This is the clearest philosophical split between the two platforms, and the one place where Google’s out-of-box behaviour is meaningfully safer than Microsoft’s.

Microsoft 365

The org dial is at SharePoint admin center > Policies > Sharing > More external sharing settings, with four levels: Anyone, New and existing guests, Existing guests, and Only people in your organization. Microsoft notes that “The OneDrive setting can be more restrictive than the SharePoint setting, but not more permissive.”

Live documentation says “External sharing is turned on by default for your entire SharePoint and OneDrive environment” without naming the level. An archived Microsoft page gives the level as Anyone for both SharePoint and OneDrive, and archived is what that is: we are marking it rather than presenting it as current.

The nuance that stops people making an error in the other direction: the org dial is not the per-site default. Microsoft’s live table has classic, communication and modern no-group sites defaulting to Only people in your organization; OneDrive and the root communication site defaulting to Anyone; and group-connected or Teams sites defaulting to New and existing guests. As the docs put it, “Even if your organization-level setting allows external sharing, not all new sites allow it by default.”

A naming trap worth knowing before you go looking: the org-level section is called “File and folder links.” “Default sharing link type” and “Default link permission” are site-level labels and do not appear on the org page. Microsoft’s recommendation, from an archived best-practices page, is “Under File and folder links, select Only people in your organization,” with file permissions set to View.

On the identity side: “By default, B2B collaboration with other Microsoft Entra organizations is enabled, and B2B direct connect is blocked,” and guest access is marked “Guest users have limited access to properties and memberships of directory objects: (Default).”

Google Workspace

The org control is at Menu > Apps > Google Workspace > Drive and Docs > Sharing settings > Sharing options, with On, Off and Allowlisted Domains. Google’s current term is “Allowlisted”; anything still saying “whitelisted” is out of date. As of 16 August 2026, no Google page states the on/off default for a new tenant, so we are not publishing one.

What Google does document is the best single sentence in this whole comparison, on the general access default: “By default, general access is set to Restricted… This is the recommended setting for most users, so they can share a file only when they’re ready and keep personal files private.”

Read that against Microsoft’s archived Anyone with the link default and you have the honest summary: a new Google file is private until somebody shares it; a new Microsoft link is documented, on an archived page, as reaching anyone who holds it.

Two more that cost nothing: set Access Checker to “Recipients only,” which is Google’s own recommendation, and note that for new shared drives, all five of the external and permissive options are unchecked by default.

7

Restrict external calendar sharing to free/busy.

Cheap, low-friction, and almost never done. A calendar with subjects and locations visible is a map of who your executives meet, when they travel, and which deal is closing this week, and it is the reconnaissance step for a convincing impersonation.

Microsoft 365

Microsoft documents the out-of-box behaviour plainly, even though it does not publish the shipped configuration value: “If you don’t change anything, then all users can invite anyone with an email address to view their calendar.”

Three levels exist: free/busy time only; free/busy plus subject and location; and all information. Pick the first for external audiences.

We are deliberately not quoting a literal default value here. The behaviour is documented; the shipped value of the default sharing policy is not on any vendor page, so anyone quoting one is guessing.

Google Workspace

The path is Menu > Apps > Google Workspace > Calendar > Sharing settings, and the most restrictive of the four external options is “Only free/busy information (hide event details).”

You will very often see it claimed that free/busy is already the external default. That is not vendor-documented. Google’s page marks defaults for internal sharing only. What is publishable is that Google recommends restricting external calendar sharing to free/busy, in its own small-business checklist. So set it rather than assuming it.

8

Prune administrators.

Free on every tier, on both platforms, and a recurring finding when we look at a tenant for the first time: administrator rights that were granted for one afternoon in 2021 and never removed.

Microsoft 365

Microsoft’s numbers are specific: fewer than five Global Administrators, and fewer than ten privileged role assignments overall.

While you are in there, know the session shape you are working inside. “The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days,” and the persistent-browser default is the “Stay signed in?” prompt. Refresh and session token lifetimes have not been configurable since 30 January 2021, and any policy you still have for them is ignored.

Google Workspace

More than one super admin, each managed by a separate individual, none of them used for daily work, and none of them left signed in. Google publishes no numeric ceiling, so if you have seen a specific recommended number attributed to Google, it was invented somewhere else.

Session length lives at Security > Access and data control > Google Session control, under the setting “Web session duration.” “By default, the web session length for Google services is 14 days.” That control excludes Business Starter and Business Standard.

And a detail almost nobody knows, which is reassuring when you find it: “The session length for admins using the Google Admin console is set to one hour and can’t be modified.”

9

Know your log horizon before you need it.

The hour you discover a compromise is the wrong hour to discover how far back you can see. Establish this now, in writing, and tell whoever signs off on the tier what it means.

Microsoft 365

A commonly misquoted figure here: Audit (Standard) retains 180 days, not 90. Microsoft states that “The default retention period for Audit (Standard) changed from 90 days to 180 days,” with logs from before 17 October 2023 keeping the old 90.

Audit (Standard) is included in Business Basic, Standard and Premium, and both audit tiers are enabled by default. Search at Microsoft Purview portal > Audit

Audit (Premium) gives one year for Entra ID, Exchange, OneDrive and SharePoint, 180 days for everything else, and ten years only with a per-user add-on that is not retroactive. It needs E5, or for smaller organizations the Purview Suite for Business Premium add-on, which is “capped at 300 seats total.”

Entra logs are a separate horizon from the unified audit log: Free retains audit and sign-in logs for 7 days, P1 and P2 for 30. Retention changes are not retroactive, so raising a tier does not recover last month.

Alert policies now live at Defender portal > Email & collaboration > Policies & rules > Alert policy. “The ability to configure alert policies based on a threshold or based on unusual activity requires an E5/G5 subscription”; lower tiers get every-time alerts only.

Google Workspace

Retention is simpler than people expect: at Reporting > Audit and investigation, nearly every log type is 6 months. The exceptions are Vault log events, which are indefinite; Email Log Search at 30 days; the Meet quality tool at 30 days; Chrome app and extension usage at 12 months; and usage reports at 15 months.

The edition wall is the thing to plan around. The security investigation tool, and the Drive, Gmail and Admin log events themselves, all require Frontline Standard or Plus, Enterprise Standard or Plus, Education Standard or Plus, Enterprise Essentials Plus, or Cloud Identity Premium. Business Starter, Standard and Plus are excluded.

Do not confuse Gmail log events with Email Log Search. Email Log Search is available on Business tiers, at Reporting > Email Log Search, but it holds 30 days, and past that you need the full recipient address and the message ID to find anything. If your client is on Google Business, those 30 days may be the entire forensic story. Say so before an incident, not during one.

One vocabulary note: “reporting rules” were renamed “activity rules” throughout September 2025. Any runbook still using the old term needs a pass.

10

Establish the backup gap honestly.

Neither vendor backs up your tenant in the way most clients assume, and the way this is usually explained overstates it in the other direction. The precise version, with the quotes that actually exist, is below ↓

Both platforms

Decide between a first-party backup, a third party, or an accepted and documented risk. What you cannot do is leave it undecided, because the default answer is the third option without the documentation.

The wall you hit
is a price list.

↳ some of this is not a setting, it is a purchase order

Several controls on the list above are not switches you forgot to flip. They are capabilities your edition does not include, and no amount of configuration will conjure them. This is where the two platforms diverge hardest for an organization between five and two hundred seats.

CapabilityMicrosoftGoogle
Conditional access equivalentConditional Access → Entra ID P1, included in Business PremiumContext-Aware Access → Enterprise tiers or Cloud Identity Premium. No Business tier, including Business Plus
Advanced audit and investigationAudit (Premium) → E5, or the Business Premium add-on capped at 300 seatsSecurity investigation tool → Enterprise tiers. No Business tier
Device managementIntune Plan 1 → Business Premium. Business Basic and Standard include no Intune at allAdvanced endpoint management → Business Plus
Anti-phishingDefender for Office 365 Plan 1 → Business Premium, and in Office 365 E3 and Microsoft 365 E3 effective 1 July 2026Security sandbox → Business Standard and Business Plus. Business Starter excluded
Privileged accessPIM → Entra ID P2 or Entra ID Governance, not P1Multi-party approval → Enterprise tiers
eDiscovery and retentionPurview retentionVault → Business Plus and above
Data loss preventionPurview DLP, at the E5 classEnterprise tiers. No Business tier
Security posture dashboardMicrosoft Secure Score, at security.microsoft.com/securescoresecurity center, containing the Security dashboard, Investigation tool and Security health page. Not available in any Business tier
the honest summary for a five-to-two-hundred seat buyer:

Business Premium is a security tier. Business Plus is not.

On Microsoft, Business Premium is the tier where a real security posture becomes possible: it carries Entra ID P1 and therefore Conditional Access, Intune Plan 1, and Defender for Office 365 Plan 1. Below it, several of the ten items above are simply unavailable.

On Google, Business Plus gets you Vault and advanced endpoint management, but Context-Aware Access, the security investigation tool, DLP and the security center all require Enterprise. Google’s security ceiling for its Business tiers is materially lower than Microsoft’s at Business Premium, and that is the comparison that should be in front of whoever signs the renewal.

If budget is the constraint and you are on Google Business, one genuine consolation: Chrome Enterprise Core is free, and gives browser policy management to an organization that cannot buy Context-Aware Access.

↳ on the prices, because this is where people get burned:

List prices read on 16 August 2026, and they move. Microsoft’s own pages disagree with each other on Business Premium: the product page sells Microsoft 365 Business Premium at $22.00 per user per month paid yearly, while the compare-all page lists only the “with Copilot” variants at $32.00. If you are quoting a number, name the page you took it from. Business Basic is $7.00; E3 is $39; E5 is $60; and there is now an E7 at $99, described as including Microsoft 365 E5, Copilot, Agent 365 and the Microsoft Entra Suite. Entra sells separately as ID Free, P1 at $7, P2 at $10 and the Entra Suite at $12.

Google Workspace: Business Starter $7, Standard $14, Plus $22, with Enterprise quoted as “Custom.” Gemini is now bundled across tiers. We could not verify Enterprise pricing, so there is no Enterprise number on this page.

Both vendors cap their Business plans at 300 users. If you are approaching that, the tier conversation is happening whether you schedule it or not.

Three specifics
worth the whole page.

↳ if you read nothing else, read these

Each of these is a default that is documented, public, and almost universally unknown by the people paying for the platform. Two are Microsoft’s, one is Google’s. None of them is a vulnerability, an exploit or a vendor failure. They are shipped settings, which is what makes them your problem.

Microsoft 365

Impersonation protection is off in a stock Business Premium tenant.

Microsoft ships three preset security policies: Standard protection, Strict protection and Built-in protection. Built-in protection is on by default, and this is the part people miss: it provides Safe Links and Safe Attachments only. Standard and Strict are assigned to nobody until an administrator turns them on.

Which means that in a tenant nobody has touched, this is what is actually running:

SettingStock defaultStandard preset
ZAP for malware, phish and spamOnOn
Spoof intelligenceOnOn
First contact safety tipOffOn
User and domain impersonation protectionOffOn
Mailbox intelligence protectionOffOn

Impersonation protection is the control that catches chief-executive fraud, the message that appears to come from a name your finance team recognizes. In a stock tenant it is off, and it stays off until somebody turns on a preset.

The two-minute fix

Email & collaboration > Policies & rules > Threat policies > Preset Security Policies in the Templated policies section. Turn on Standard protection and scope it to all recipients. Strict is available if you can tolerate more false positives; Standard is the one that pays for itself immediately.

Licensing note in your favor: Business Premium already includes Defender for Office 365 Plan 1, and effective 1 July 2026 Plan 1 is also in Office 365 E3 and Microsoft 365 E3. The old line that E3 means basic protection only no longer holds. Safe Documents remains in neither Plan 1 nor Plan 2.

Google Workspace

Unconfigured third-party apps default to allow everything.

At Menu > Security > Access and data control > API controls > Manage App Access, the setting named “Unconfigured third-party apps” defaults to “Allow users to access any third-party apps.” Any application a user authorizes, that you have not explicitly configured, is permitted by default. As of 16 August 2026 we found no Google page announcing a change to that default.

This matters more than a password policy, because an OAuth token is not a password. It survives a password reset. It does not prompt for two-step verification. And it keeps working after the person who granted it has left the company.

The consequence, documented

Google’s own Threat Intelligence Group published the case. An actor tracked as UNC6395 ran a campaign from 8 to 18 August 2025, using compromised Salesloft Drift OAuth tokens to reach connected Salesforce instances and systematically export Cases, Accounts, Users and Opportunities, hunting for credentials inside them: AWS keys, passwords, Snowflake tokens.

The Workspace part, in GTIG’s words: “On August 28, 2025, our investigation confirmed that the actor also compromised OAuth tokens for the ‘Drift Email’ integration. On August 9, 2025, a threat actor used these tokens to access email from a very small number of Google Workspace accounts. The only accounts that were potentially accessed were those that had been specifically configured to integrate with Salesloft Drift.”

The caveat belongs with the case, so here it is in the same breath: GTIG states plainly, “To be clear, there has been no compromise of Google Workspace or Alphabet itself.” This is not a Google breach. It is a third-party integration breach, which is exactly why it is a governance story rather than a vendor story.

The line that makes it operational: GTIG advised customers to “treat any and all authentication tokens stored in or connected to the Drift platform as potentially compromised.” If you cannot list which applications hold tokens against your tenant, you cannot act on advice like that when it arrives.

The fix. Move “Unconfigured third-party apps” off allow-everything, then allowlist what the business actually runs, using the Trusted, Limited, Specific Google data and Blocked states. Google’s own checklist says the same: “Create an allowlist that specifies which third-party apps can access core Google Workspace services.”

Google Threat Intelligence Group · the primary source ↗

Microsoft 365

Your custom domain is not DKIM signing.

Microsoft handles its own onmicrosoft.com domain automatically: DKIM and SPF are applied for you. It is easy to assume that carries over to the domain your business actually sends from. It does not.

Microsoft states it directly: “Currently, no DKIM signing occurs for outbound mail from custom domains.” Custom-domain DKIM is off by default, and this is one of the most common live gaps we find in a tenant that has otherwise been reasonably looked after.

The asymmetry runs one step further: even on onmicrosoft.com, where DKIM and SPF are automatic, DMARC is not. Nothing is publishing a policy for you.

Where it lives now, and what to expect

Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM

If you are looking in the Exchange admin center, stop: DKIM moved to the Defender portal and no Exchange admin center path remains. A new record format was introduced in May 2025 for new custom domains, while existing domains keep the old format. Key size is 1024 by default, or 2048. Rotation takes 96 hours to begin signing, so schedule it rather than doing it on a Friday, and note there is no automatic rotation for the onmicrosoft.com domain.

Retention is not
a backup.

↳ and the usual way of saying that is also wrong

This topic attracts more overstatement than any other on the page, mostly from vendors selling the remedy. So here is the discipline we are applying: only quotes that exist. Two of the sentences most often attributed to Microsoft and Google are not on any of their pages, and we are correcting them rather than repeating them.

↳ two things you will read everywhere that are not true:

“Microsoft says it does not back up your data.” That sentence does not exist on any Microsoft page. It is a paraphrase of shared-responsibility language, and it is the most common overreach in this topic. You do not need it, because what Microsoft actually says is stronger and harder to argue with.

“Google says Vault is not a backup.” Also not the quote. What Google says is “Vault isn’t a data archive,” which is a different and more precise claim. Use theirs.

What Microsoft actually says

“For all cloud deployment types, you own your data and identities. You’re responsible for protecting the security of your data and identities.”

And the strongest line, from the Microsoft 365 Backup FAQ, which is the one to put in front of a client who believes legal hold is a safety net: “Legal holds retain data, but that feature is optimized for export (for example, via eDiscovery), not for mass restore.”

On the other thing people lean on, Microsoft is equally direct: inactive mailboxes “can’t be used as a backup solution.”

One scoping note so nobody quotes the wrong agreement at you: the line “We recommend that you regularly backup Your Content and Data” is in the consumer Microsoft Services Agreement. It governs consumer services, not commercial tenants.

What Google actually says

“Vault isn’t a data archive,” alongside “Vault doesn’t automatically retain any of your organization’s data,” and, once data is purged, “it can’t be recovered by users or admins.”

But the strongest citation in this entire area is not a help page at all. It is contract. Google’s Cloud Data Processing Addendum, at section 7.3.1, explicitly covers Workspace and reads: “Customer is responsible for… backing up or retaining copies of its Customer Data as appropriate.”

That is binding language in an agreement your organization has already signed, which beats anything either vendor publishes in a support article. If you need one sentence to settle an internal argument about whose job this is, that is the sentence.

There is also no first-party Google Workspace backup product. Backup and DR Service covers Google Cloud workloads, not Workspace, and Data Export is a one-way door.

↳ the first-party option on the Microsoft side, priced:

Microsoft 365 Backup is a real, paid, first-party product at $0.15 per GB per month, with restores free. It requires an Azure subscription, and covers OneDrive, SharePoint and Exchange Online only. Retention is stated as “1 year” or “52 weeks” and is not configurable. Restore points are ten minutes apart.

What it does not do: room and group mailboxes and hybrid deployments are unsupported. Teams, Entra ID and Planner are simply absent from the supported set rather than explicitly excluded, which is a distinction worth holding lightly. And as of 16 August 2026 no reachable Microsoft page states a general-availability date, so we are not publishing one.

The clocks that start
when something is deleted.

↳ three of these are widely misquoted, and they are flagged

Every one of these is a window in which a mistake is still recoverable without a backup. Past the window, it is not. Print this row of numbers and keep it where whoever answers the “I deleted something” call can see it.

What was deletedWindowThe detail that matters
Exchange Online mail
(Recoverable Items)		14 days default, 30 days maximumThe default is 14; you can raise it to 30, and no further.
Exchange “Deleted Items” folderNo default deletion tagThe widely repeated 30-day default tag does not exist. Microsoft states that “The Default MRM Policy doesn’t include a default tag to automatically delete content from the Deleted items folder.” Only Junk Email has one.
SharePoint items93 days, then 14 days backendThis is not a 30 plus 63 split. Items sit in the site Recycle Bin for 93 days, then the site collection bin “for the remainder of their retention period.” The 30-day first stage applies to SharePoint Server 2019 and 2016 only. After the additional 14 days of backend backup, “Microsoft no longer retains the data and it isn’t recoverable.”
OneDrive, after the user is deleted30 days defaultConfigurable from 30 to 3,650 days. One of the few dials here that is genuinely yours to set.
The whole subscription, at end of term90 days limited functionThen deletion no more than 180 days after the subscription ends.
Google Drive, user trash30 daysThe ordinary window a user can undo themselves.
Google Drive, purged items25 days for an adminAn administrator can restore items purged from trash for a further 25 days.
Google Drive, purged items → GmailNot documentedDo not apply the 25-day figure to Gmail. As of 16 August 2026, no Google page documents an administrator Gmail restore window at all. If you have been told there is one, ask where it is written.
A deleted Google user account20 daysRestore the account and its data within 20 days of deletion.

If you want somebody
else’s homework.

↳ four free baselines, none of which want your email address for the document itself

The ten items above are the version you can execute in an afternoon. If you want the exhaustive version, these exist, they are free, and two of them ship as tools that assess your live tenant and hand you a report.

US government baseline · Microsoft 365

CISA SCuBA

Final, and mandatory for federal civilian agencies under Binding Operational Directive 25-01, “Implementing Secure Practices for Cloud Services,” dated 17 December 2024. CISA says explicitly that “Organizations outside of the Federal Government may also find these baselines to be useful references.”

Eight baselines: Entra ID, Exchange Online, Teams, SharePoint and OneDrive, Defender, Power BI, Power Platform, and Security Suite. There is no document-level version number; versioning is per policy, in the form MS.AAD.1.1v1. Use the tool release as the de facto version: ScubaGear v1.8.0, released 7 May 2026.

github.com/cisagov/ScubaGear ↗

US government baseline · Google Workspace

CISA SCuBA for GWS

Eleven baselines, and the assessment tool is ScubaGoggles v1.0.1, released 28 July 2026. Worth stating clearly because it is easy to get wrong: v1.0.0 crossed on 24 July 2026, so ScubaGoggles is no longer alpha.

Google Workspace policies now appear in BOD 25-01 with a due date of 1 December 2026, which is still in the future. A representative policy, and a good summary of the whole page you are reading: GWS.COMMONCONTROLS.1.1v1, which reads “Phishing-Resistant MFA SHALL be required for all users.”

github.com/cisagov/ScubaGoggles ↗ · BOD 25-01 ↗

Industry consensus baseline

CIS Benchmarks

The current documents are the CIS Microsoft 365 Foundations Benchmark v7.0.0 and the CIS Google Workspace Foundations Benchmark v1.4.0. CIS states that “CIS Benchmarks are freely available in PDF format for non-commercial use.”

We could not read release dates off the page, and could not confirm whether the download asks for an email address, so we are not asserting either.

Related, and frequently cited a version behind: NIST SP 800-63B-4 is Final as of July 2025. If your policy document cites Rev. 3, it is out of date. NIST styles it -4, not “Rev. 4.”

NIST SP 800-63B-4 ↗

The vendors’ own homework

Checklists and scores

Google publishes two, and they are genuinely good: a “Security checklist for small businesses (1-100 users),” described as “a baseline set of best practices that you can set up yourself,” and a 100-plus version.

Microsoft’s equivalent is Secure Score, at security.microsoft.com/securescore. One caution: Intune “security baselines” are Windows device-level settings, not a tenant baseline, and presenting them as one is a common error. As of 16 August 2026 we located no tenant-level Microsoft baseline document distinct from Secure Score.

And a sourcing note, if you go looking yourself: Google has migrated its Workspace admin help to knowledge.workspace.google.com. Old support.google.com/a/answer/* links redirect rather than break, so a stale citation looks fine and is not. Some article IDs now land on the site root, which means the article was retired rather than moved.

Support & Education · companion page

Security is how you build.

The layer underneath this one: how organizations actually get compromised, what happened here in Puerto Rico, a breach check for your own address, and the infrastructure assessment that tells you whether the settings above are being maintained by anybody.

↳ settings are one afternoon; ownership is the practice

Read it →
Support & Education · companion page

AI at work.

The policy half of item four. Once you have decided which third-party applications may hold a token against your tenant, the next question is what your staff are pasting into the ones you did approve.

↳ a nine-element policy starter, mapped to NIST anchors

Read it →
Support & Education · printable

The workbook.

Page 7 is this page on paper: a two-column Microsoft and Google worksheet for all ten settings, with room to write who owns each one and when it was last checked. No login, no download form.

↳ fourteen Letter-size pages, print it double-sided

Open it →
↳ when nobody owns the admin console

Somebody has to
be responsible for this.

Every item above takes minutes. The reason they go undone is not difficulty, it is that no one person owns the tenant, so the settings drift, the tiers get renewed unexamined, and the log horizon turns out to be thirty days on the morning it matters. If that description is uncomfortably close, that is the conversation we would rather have.

Talk to us → The whole library