Google Workspace vs Microsoft 365 for Cold Email: Which Should You Use?
For most B2B cold email programs the right answer is both: match the mailbox provider to the prospect's mail host, sending to Google-hosted domains from Google Workspace mailboxes and Microsoft-hosted domains from Microsoft 365 mailboxes. If you have to pick one, Microsoft 365 is the safer default for enterprise and mid-market lists, and Google Workspace is the safer default for SMB, tech and startup lists. The real difference between them is how each one's inbound filter treats unknown senders, not how much either one lets you send.
Below is what actually differs between the two platforms for cold outreach: sending limits, authentication, tool connectivity, suspension behaviour, cost, and the routing trick that matters more than the platform choice itself.
Which is better for cold email, Google Workspace or Microsoft 365?
Neither is universally better. They differ in four ways that matter:
- Filtering style of the receiving side. Microsoft's Exchange Online Protection and Defender lean heavily on IP/domain reputation, bulk-mail heuristics and tenant-level policy, and will quarantine silently. Gmail leans more on authentication plus recipient engagement signals. It is more forgiving of a brand-new domain that gets opens and replies, and much less forgiving once complaints appear.
- Operational friction. Microsoft 365 is harder to connect to sending tools (OAuth, SMTP AUTH toggles, Security Defaults). Google Workspace is easier to connect but quicker to suspend accounts it thinks are being automated.
- Blast radius when something goes wrong. Microsoft usually blocks the individual mailbox ("restricted entity") and lets you self-remediate. Google is more likely to suspend the user, and occasionally the whole Workspace account.
- Cost per mailbox, which at list price is similar but at cold-email scale depends entirely on how you provision.
Quick rule of thumb by ICP:
- Selling to enterprise, finance, manufacturing, healthcare, logistics, government-adjacent: those lists skew heavily Microsoft-hosted. Lead with Microsoft 365 mailboxes.
- Selling to startups, SaaS, agencies, ecommerce, small professional services: those lists skew Google-hosted. Lead with Google Workspace.
- Mixed list (most people): run both pools and route by MX record. See below.
What are the actual sending limits on Google Workspace vs Microsoft 365?
Both platforms allow vastly more volume than you should ever send per mailbox, so sending limits are almost never the deciding factor.
Google Workspace:
- 2,000 messages per user per day on paid editions (Business Standard and above).
- 500 messages per day on Business Starter.
- 500 external recipients per message.
- Undocumented short-burst throttling: send too fast and you get temporary 4xx deferrals.
Microsoft 365 (Exchange Online):
- 10,000 recipients per mailbox per day (the historical cap).
- 30 messages per minute per mailbox.
- An External Recipient Rate limit of 2,000 external recipients per mailbox per day, which Microsoft has rolled out across tenants. This is the one that matters for outbound prospecting, since every cold recipient is external.
Now the part that actually matters: sane cold email volume is roughly 20–50 sends per mailbox per day, ramped up over two to four weeks. That's a practitioner convention driven by reputation, not by platform limits. If a vendor is selling you on "higher sending limits," they're selling you a number you will never approach. At 30/day you are using 1.5% of a Workspace mailbox's headroom.
Should I match my mailbox provider to my prospect's email provider?
Yes. This is the highest-leverage decision in this whole comparison, and almost nobody does it. Split your list by the recipient domain's MX record, then send Google-hosted prospects from Google Workspace mailboxes and Microsoft-hosted prospects from Microsoft 365 mailboxes.
Why it works: each platform's outbound infrastructure is well-known and well-behaved to its own inbound filters, and same-platform mail is the most common, most trusted traffic those filters see. It's not magic and there's no published benchmark, but the practical effect, fewer Microsoft quarantines on Microsoft-hosted lists, is consistent enough that it's worth structuring around.
How to segment a list by mail host:
- Look up the MX record for each prospect domain:
dig MX example.com +short(ornslookup -type=mx example.com). - Google-hosted if you see
aspmx.l.google.com/*.googlemail.com. - Microsoft-hosted if you see
*.mail.protection.outlook.com. - Other (Proofpoint, Mimecast, Barracuda, Zoho, cPanel, etc.) are usually gateway products in front of one of the two. Proofpoint and Mimecast in particular sit in front of mostly Microsoft tenants and are far stricter; treat them as a separate, slower, more conservative segment.
Most email verification providers return the mail host or MX in their output, so you can usually get this field for free during list cleaning instead of running DNS lookups yourself. Then create two campaigns in your sending tool, each assigned to the matching mailbox pool.
How hard is each one to connect to Instantly, Smartlead or ReachInbox?
Google Workspace is easier; Microsoft 365 has more ways to fail, and nearly all of them are auth-related. This is where most people lose a weekend.
Google Workspace connection checklist
- Enable IMAP in Gmail settings (and confirm the admin console isn't blocking IMAP/POP for the OU).
- Prefer OAuth ("Connect with Google") in your sending tool. It's more stable than app passwords and survives password changes.
- If you use SMTP instead: 2-Step Verification must be on for the user before an app password can be generated. "Less secure app access" no longer exists.
- Host:
smtp.gmail.com:587(STARTTLS) andimap.gmail.com:993. - For large pools, domain-wide delegation via a service account lets you connect many mailboxes without touching each one. Some tools support it, not all.
Microsoft 365 connection checklist
- Use OAuth / Microsoft Graph, not basic-auth SMTP. Microsoft has been progressively shutting off basic authentication in Exchange Online, including for SMTP client submission. Any tool or guide still telling you to use a plain username and password is on borrowed time.
- Security Defaults block legacy authentication. If Security Defaults are on in Entra ID, SMTP AUTH connections fail. Either move to OAuth or replace Security Defaults with Conditional Access policies, and accept the security tradeoff deliberately.
- SMTP AUTH is off by default per mailbox. If you genuinely need it:
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false, plus the org-level setting in the Exchange admin center. - Host:
smtp.office365.com:587(STARTTLS),outlook.office365.com:993for IMAP. - Admin consent is usually required the first time you connect a tool's OAuth app to the tenant.
Practical implication: if you're buying mailboxes from a provider, ask specifically how Microsoft mailboxes are connected to sending tools and whether you get admin access to fix it yourself. With Inboxlogy you get 100% ownership and admin access to the tenants, plus an API for provisioning and management. That matters precisely because Microsoft connection issues are solved in the admin console, and you can't solve them if someone else holds the keys.
How do I set up SPF, DKIM and DMARC for each?
Both platforms require all three, and both will fail silently if you get them wrong. The records differ:
SPF
- Google:
v=spf1 include:_spf.google.com ~all - Microsoft:
v=spf1 include:spf.protection.outlook.com -all - If a domain sends from both, include both mechanisms in a single SPF record. A domain must have exactly one. Watch the 10-DNS-lookup limit (RFC 7208); exceeding it makes SPF return
permerrorand effectively fail.
DKIM
- Google: generate the key in Admin console → Apps → Google Workspace → Gmail → Authenticate email. Use the 2048-bit key, publish the TXT record, then click "Start authentication". People skip that last step constantly, and until you click it, Google is not signing your mail.
- Microsoft: publish two CNAMEs (
selector1._domainkeyandselector2._domainkey) pointing at your tenant's onmicrosoft.com targets, then enable DKIM signing for the domain in the Defender portal. Again: publishing the CNAMEs alone does nothing until you flip signing on.
DMARC
- Start with
v=DMARC1; p=none; rua=mailto:[email protected]to collect reports, then move top=quarantineonce you've confirmed alignment. - Google and Yahoo require DMARC from senders above 5,000 messages/day to their consumer domains, along with a spam rate under 0.3% and one-click unsubscribe (RFC 8058). Microsoft applies comparable authentication requirements to high-volume senders into Outlook.com, Hotmail and Live.
- Cold email per-domain volume is usually below those thresholds, but the direction of travel is clear: unauthenticated mail is being squeezed out. Set all three from day one.
Verify with a real message, not a checker tool alone: send to a Gmail address and a Microsoft-hosted address, open the original headers, and confirm spf=pass, dkim=pass and dmarc=pass with the DKIM d= domain matching your From domain. Inboxlogy automates SPF, DKIM and DMARC at provisioning time, which removes the most common single point of failure. Still check the headers yourself once per domain.
What gets your mailboxes or your whole tenant suspended?
Google is more likely to suspend the account; Microsoft is more likely to block the mailbox and let you unblock it.
Google Workspace: spikes in outbound volume, bounce rates, spam complaints, or automation patterns can trigger a user suspension. In bad cases Google suspends the whole Workspace account, which takes every mailbox and every domain in it offline at once. Appeals exist; they are slow and not guaranteed.
Microsoft 365: tripping the outbound spam policy lands the mailbox on the Restricted entities list in the Defender portal. You can review and unblock it yourself, usually within a few hours of the block. Repeat offences escalate to tenant-level restrictions, which are much harder to reverse.
Structural advice that applies to both:
- Don't put every domain in one tenant. Both platforms technically support hundreds of domains per account, which is exactly why concentration risk is so easy to create by accident. Spread domains across multiple tenants/workspaces so a single suspension can't take down your whole outbound operation.
- Keep your real company domain out of the cold email pool entirely. Use lookalike sending domains. A suspension on a sending domain is an inconvenience; a suspension on your corporate domain stops payroll emails.
- Aliases are not extra mailboxes. Sending from five aliases on one mailbox gives you one mailbox's reputation and one mailbox's limits, split five ways. It's a false economy on both platforms.
- Clean your list before you send. High bounce rate is the fastest way to a block on either platform, and it's entirely preventable.
What does each actually cost for cold email at scale?
At list price the two are close: roughly $6–$8 per user per month for entry tiers (Microsoft 365 Business Basic, Google Workspace Business Starter), more for higher tiers, with pricing revised periodically by both vendors. Check current pricing before you budget.
The problem is that cold email needs many mailboxes. At 30 sends/day per mailbox, a modest 15,000-sends-per-month program needs roughly 25 mailboxes, plus the domains, the DNS work, and the provisioning time. At list price that's $150–$200/month in licences before anyone writes a single email, and the setup labour is usually the bigger cost.
This is the gap infrastructure providers fill. Inboxlogy provisions authorized Google Workspace and Microsoft 365 mailboxes from $2.80/mailbox/month with $0 setup, billed monthly, with SPF/DKIM/DMARC configured automatically, dedicated US/EU IPs, and full API access for programmatic provisioning. The word that matters there is authorized: you own the tenants outright and hold admin access, so the mailboxes behave like any other legitimate Workspace or Microsoft 365 seat.
Contrast that with grey-market "SMTP panels" or shared reseller accounts where you don't hold admin. Those get deprovisioned, you can't fix auth problems yourself, you can't export your data, and you inherit whatever reputation the previous tenant left behind. If a provider won't give you admin access, you're renting a liability.
Do dedicated IPs matter for Google Workspace or Microsoft 365 cold email?
Be clear-eyed about this: when you send from a Google Workspace or Microsoft 365 mailbox, the message leaves Google's or Microsoft's shared outbound IP ranges. You do not control the egress IP, and no vendor can give you one for Gmail-sent or Exchange-sent mail. If someone tells you otherwise about mailbox sending, they're either confused or selling you an SMTP relay and calling it a Workspace mailbox.
Dedicated IPs are real and useful for the parts of a stack you do control: relays, transactional sending, and region placement (US vs EU) for data residency and routing. Inboxlogy offers dedicated US/EU IPs on that basis. But for mailbox-based cold outreach, your reputation lives in your domain, your authentication, and your recipient engagement, not in an IP you don't own. Spend your attention there.
Related, and worth knowing: Microsoft's SNDS and JMRP feedback programmes are for people who own their sending IPs, so they're unavailable to you when you send through Exchange Online. Google Postmaster Tools works on your domain, but only displays data once that domain sends meaningful daily volume, which a 30-sends-per-day cold email domain typically won't reach. Plan on seat-of-the-pants telemetry: reply rates, bounce rates, and your own seed-inbox placement tests.
How many mailboxes and domains do I need?
Work backwards from volume:
- Mailboxes = (monthly sends ÷ ~21 working days) ÷ 30 sends per mailbox per day. 10,000 sends/month ≈ 16 mailboxes. 30,000/month ≈ 48.
- 2–3 mailboxes per sending domain is a common, conservative ratio. More than that concentrates risk.
- Ramp over 2–4 weeks from a handful of sends per day to full volume. New mailboxes at full volume on day one is the single most reliable way to get blocked.
- Split the total across both platforms in roughly the same proportion as your list's MX distribution. Measure it, don't guess.
What about warmup?
Warmup runs in your sending tool, not in your mailbox infrastructure. Instantly, Smartlead and ReachInbox all include warmup networks; you connect your mailboxes and enable warmup there. Inboxlogy provides the mailboxes and the authenticated domains. It does not run warmup itself. Anyone selling you mailboxes should be clear about that division, because "warmed mailboxes" from a vendor usually means the vendor ran warmup in their own tool against their own network, which does nothing for your domains once you move them.
Practical sequence: provision mailboxes → verify SPF/DKIM/DMARC in real headers → connect to your sending tool → enable warmup for 2–3 weeks → begin campaigns at low volume → ramp. Keep warmup running alongside live campaigns; it's not a one-time phase.
What should I look for in a cold email mailbox provider?
- Authorized, real tenants on Google Workspace and Microsoft 365. Not resold panel access, not shared tenants.
- 100% ownership and full admin access. Non-negotiable. Microsoft connection problems are solved in the admin console; DKIM is enabled in the admin console; suspension appeals come from the admin console.
- Both platforms available from the same provider, so you can run the MX-matched split without managing two vendors.
- Automated SPF/DKIM/DMARC, with the actual records visible to you for verification.
- An API if you're provisioning at any real scale. Creating 50 mailboxes by hand is a day you don't get back.
- Monthly billing and no setup fee, because mailbox needs change as campaigns change.
- Honesty about what they don't do, including warmup and dedicated IPs for mailbox egress. A provider that over-claims on the easily-checkable things is over-claiming on the rest too.
Inboxlogy is built to that spec: authorized Google Workspace and Microsoft 365 mailboxes, dedicated US/EU IPs, automated SPF/DKIM/DMARC, 100% ownership with admin access, full API, from $2.80/mailbox/month with $0 setup and monthly billing.
Frequently asked questions
Can I use both Google Workspace and Microsoft 365 on the same domain?
You can, but for cold email you generally shouldn't. It complicates SPF (you need both includes in one record, against a 10-lookup budget), complicates DKIM, and gives you no benefit. The MX-matching strategy works at the mailbox pool level, so it's cleaner to run separate domains on separate platforms and route campaigns accordingly.
Does Microsoft 365 really have better cold email deliverability than Google Workspace?
Not inherently. What's true is that Microsoft's inbound filtering is stricter toward unknown senders, and a large share of enterprise B2B inboxes sit behind it. If your list is Microsoft-heavy, sending from Microsoft mailboxes removes one variable. On a Google-heavy list the reverse applies. Measure your own list's MX distribution before deciding.
Why do my Microsoft 365 mailboxes keep failing to connect to my sending tool?
Almost always authentication. In order of likelihood: Security Defaults are enabled in Entra ID and blocking legacy auth; SMTP AUTH is disabled on the mailbox or at the org level; you're using basic auth where OAuth is now required; or the tool's OAuth app hasn't received tenant admin consent. Connect via OAuth/Graph where your tool supports it, and check the Entra sign-in logs for the exact failure reason rather than guessing.
How long before a new mailbox is safe to send from?
Plan on 2–3 weeks of warmup in your sending tool before the first campaign, then ramp volume over another 2–4 weeks rather than jumping to full send rate. The domain's age matters as much as the mailbox's. If you're registering fresh sending domains, buy them a few weeks before you need them and get DNS authentication published immediately.