The Setup
I run Google Workspace as my primary mail and calendar system, connected into Outlook. On Windows, both the classic desktop client and the newer web-based rebuild, I can hit "Send to OneNote" from an email and it just works, Gmail account and all. On the Mac, the same button either doesn't appear for that account or throws an error. Same Microsoft 365 subscription. Same OneNote. Same person. Different result depending on which machine I'm sitting at.
And to be clear about the scope: this isn't confined to enterprise tenants with enterprise-only causes. It shows up just as readily on Microsoft 365 Personal and Family subscriptions, plans with no business tenant, no admin console, and none of the compliance tooling that IT departments wrestle with. That detail matters, because it rules out the easiest explanation before we even get to it.
My first assumption was that I was missing a setting. I wasn't. What I found digging into it was more interesting than a settings problem. It's a case study in what happens when a company runs the same feature on two different technical foundations and calls it one product.
What Microsoft Says the Rule Is
Microsoft's own support documentation is unambiguous: Send to OneNote on the Mac is built to work with Microsoft 365 and Outlook.com accounts specifically, not third-party mail like Gmail. That's the official line, and if you take it at face value, the behavior I'm seeing is working as designed.
Except plenty of Mac users, myself included, based on past experience, have had this work fine with non-Microsoft accounts before. So "working as designed" doesn't hold up as the whole story.
What Actually Seems to Be Happening
Digging through Microsoft's own support community turns up a pattern that looks less like a deliberate policy and more like a feature that keeps getting quietly re-broken by changes elsewhere in the stack:
- In late 2025, Microsoft added a mandatory Purview sensitivity-label check into the Send to OneNote pipeline. Even accounts with no sensitivity labels configured at all got routed through this check, and failed, because the system tried to fetch labels that didn't exist. Microsoft's own engineers confirmed this was an internal bug tied to a push toward "stricter compliance regulations," not a user configuration issue.
- That exact failure mode resurfaced again in May 2026, months after it was supposedly fixed. That tells you this isn't a one-time incident so much as a recurring side effect of how often this integration gets touched.
- On top of that, Google has independently been tightening its own side of the equation, periodically expiring third-party OAuth authorizations for apps like Outlook and requiring re-approval in the Workspace admin console.
- Crucially, the failures aren't confined to accounts that could plausibly hit a Purview compliance check. A Microsoft 365 Personal subscriber reported the same class of failure (a server error the instant OneNote tried to authenticate from the Send to OneNote flow) on a plan that has no business tenant and therefore no sensitivity labels to check in the first place. That's a meaningful data point. It means the breakage isn't just one compliance feature gone sideways for business users. Something more fundamental in the Mac client's authentication or API handling is unreliable across the entire subscription lineup, business and consumer alike.
None of this is a single "Microsoft killed cross-platform Send to OneNote" decision. It's the accumulation of a compliance feature added without adequate testing, a security posture change on Google's end, and, underneath both, a Mac client that was rebuilt on newer, web-based plumbing that doesn't inherit the same fallback paths the Windows desktop client still has.
The Real Story: Two Codebases Pretending to Be One Product
This is the part that actually matters if you run technology for a living. "Outlook for Mac" and "Outlook for Windows" are marketed as the same product with a shared feature set. They are not the same codebase, and they haven't been for years. Windows still carries forward decades of native COM add-in architecture for things like this. Mac's Outlook, new and legacy alike, increasingly routes through newer cloud-based integration layers that get touched more often, tested less thoroughly across account types, and broken more frequently as a side effect.
When a vendor tells you a capability is "cross-platform," what they usually mean is "cross-platform for the primary platform, and something adjacent to that everywhere else." That gap rarely shows up in a product brief. It shows up eighteen months later when a small, boring feature you relied on stops working with no announcement, no changelog entry, and a support thread full of people independently discovering the same bug.
Why This Is Worth Writing About
I'm not writing this to complain about a OneNote button. I'm writing it because the failure pattern here (a platform-parity claim that quietly doesn't hold, discovered only through the accumulated frustration of end users comparing notes in a support forum) is exactly the kind of thing organizations need to plan around when they build workflows on top of any vendor's ecosystem. If you're the person responsible for productivity tooling, ministry operations, or IT strategy at your organization, the lesson isn't "don't use Outlook." It's this: don't assume feature parity across platforms just because marketing says so. Test the actual workflow on every device your people use, and build in a fallback (Print to OneNote, drag-and-drop, direct copy-paste) before you find out the hard way that the fallback was needed.
Microsoft hasn't announced this change. As far as I can tell, no one at Microsoft would tell you definitively why it happened, because it isn't one decision. It's the compounding residue of several decisions, made by several teams, none of whom were likely thinking about a guy trying to send a Gmail message to OneNote from his Mac.
Where I Landed
I didn't write this as a hypothetical. Outlook wasn't a casual choice for me. It was the one client that let me manage Microsoft and Google accounts side by side in a single interface, which matters when your professional life spans both ecosystems and you don't have the luxury of picking just one. That's exactly why the Mac/Windows gap stings: the entire reason to use Outlook in the first place was cross-account, cross-platform reliability. Once that promise broke, the tool lost the one thing that justified using it over either vendor's native client.
After enough rounds of a core workflow breaking with no warning, no changelog, and no acknowledgment, I made the call to drop both Outlook and OneNote entirely. Not because either product lacks capability on paper. Both have plenty. But because a tool that can't reliably promise the same behavior across the devices I actually use isn't a tool I can build a workflow on. Feature parity isn't a nice-to-have for anyone doing serious cross-platform work. It's the baseline. Once I stopped being able to trust that baseline, the rest of the feature set stopped mattering.
That's really the point of writing this up. The lesson for anyone building a technology stack, whether for a ministry, a business, or your own personal system, isn't specific to Outlook or OneNote. It's that "cross-platform" claims deserve testing on every device your people actually use, not just the platform the vendor optimized for first. When that promise quietly breaks and stays broken, the rational response isn't to keep troubleshooting forever. It's to stop depending on it.