Microsoft 365 vs Google Workspace in the GTA: What 479 Business Domains Actually Run

There is no published figure for what Greater Toronto Area businesses actually use for email. Vendors publish global market share. Analysts publish enterprise share. Nobody publishes the number for the small and mid-sized companies that make up the GTA business base, and every managed IT provider in this market — including us — makes assumptions about it.

So we measured it. On 5 August 2026 we re-scanned the same random sample of 500 GTA business domains we used for our email authentication study on 1 August, this time reading the MX records to identify which mail platform each domain actually runs, and checking whether each one publishes MTA-STS and TLS-RPT. Because it is the same sample, the platform data cross-tabulates directly against the SPF and DMARC data from four days earlier.

That cross-tab produced the finding that matters, and it is not the market share. Domains on Google Workspace are roughly two and a half times less likely to enforce DMARC than domains on Microsoft 365, and one in four publishes no SPF record at all. Every figure below is our own measurement, published with its method and its limits. Nothing is modelled, estimated, or borrowed from a vendor report.

The Five Numbers

46.8% of mail-enabled GTA business domains run Microsoft 365 — 224 of 479. This is a floor, not a ceiling, for reasons explained in the method section.

25.1% run Google Workspace — 120 of 479. The two platforms together account for 71.8% of the sample.

8.6% still run their own mail server on their own domain — 41 of 479.

27.2% versus 10.8% — the share of Microsoft 365 domains that enforce DMARC, against the share of Google Workspace domains that do.

1.3% publish an MTA-STS policy — 6 domains out of 479. Modern SMTP transport security is effectively absent from this market.

What GTA Businesses Actually Run

The third-party security gateway row covers domains whose MX points at a dedicated email security service rather than at a mailbox platform: Proofpoint (19), Barracuda (6), Sophos (2), Fortinet (2), Trend Micro (2) and Mimecast (1). Those businesses are running a mailbox platform behind the gateway — we simply cannot see which one from DNS, which is the main reason the Microsoft 365 figure is a floor.

Two things in that table are worth pausing on. The first is that 6.7% of GTA businesses pay for a dedicated email security layer in front of their mail. The second is that 8.6% — roughly one business in twelve — are still running their own mail server in 2026, with all the patching, reputation management and deliverability work that implies. Neither number is a criticism. Both are useful if you are trying to understand what your competitors and suppliers are actually operating.

The Finding: Security Posture Splits Sharply by Platform

This is where the cross-tab earns its keep. Same sample, same week, two independent measurements laid over each other.

"DMARC enforcing" means a published DMARC record set to p=quarantine or p=reject — a policy that actually tells receiving mail servers to do something about mail that fails authentication. A record set to p=none publishes a preference and takes no action. It is the difference between a lock and a sign about a lock.

Three findings stand out.

Google Workspace domains are the least protected group in the sample. One in four (30 of 120) publishes no SPF record at all, against 4 of 224 on Microsoft 365. Twenty-seven of them — 22.5% — have neither SPF nor DMARC, meaning nothing in public DNS constrains who can send mail using their domain name. And of the Google Workspace domains that do publish DMARC, 74.0% sit at p=none, against 50.4% on Microsoft 365. At every stage of the funnel, the same gap.

Publishing a record is not the same as enforcing one, and the web-host group proves it. Domains running mail through their web host or cPanel had the highest DMARC publication rate in the entire sample at 80.0% — and the lowest enforcement rate at 6.7%, with not a single domain at p=reject. That is the signature of a control panel that generates a record by default and a business that has never revisited it. If you are judging a provider by whether a DMARC record exists, this row is the reason that test is worthless.

The businesses that bought a security gateway did the rest of the work too. The 32 domains behind Proofpoint, Barracuda, Mimecast and similar services enforce DMARC at 28.1% and sit at p=reject at 18.8% — the strongest posture of any group, and more than double the sample average on p=reject. Buying the gateway did not create that; it is the same organisational habit showing up twice.

Why the Platform Gap Probably Exists

We measured the gap. We did not measure its cause, and we are not going to pretend otherwise. But two explanations are worth putting on the table, clearly labelled as our reading rather than as findings.

The first is that this is not a product-quality difference. Google Workspace supports SPF, DKIM and DMARC properly, and Google has published enforcement requirements for bulk senders since 2024. Nothing about the platform prevents a domain from reaching p=reject. Both platforms ship without DMARC configured; the work is the same on either.

The second is about who administers what. In our own experience across GTA client environments, Microsoft 365 tenants are more often handed to an IT provider to run, while Google Workspace is more often stood up by the business itself — it is genuinely easier to start, which is a real advantage until the point where somebody has to publish a DNS record nobody has heard of. If that pattern holds beyond our client base, the gap in this data is a gap in administration, not in software. That is a hypothesis consistent with the numbers, not something this study establishes.

The practical takeaway does not depend on which explanation is right. If you run Google Workspace and nobody has explicitly done your email authentication, the odds from this sample say it is not done.

Almost Nobody Has Modern Transport Security

SPF, DKIM and DMARC decide whether a message is allowed to claim your domain. MTA-STS and TLS-RPT are a separate layer: they tell other mail servers to refuse to deliver to you over an unencrypted or improperly authenticated connection, and to report back when delivery fails. They defend against interception and downgrade attacks rather than spoofing.

Six domains out of 479 publish an MTA-STS policy. Seven publish TLS-RPT. That is 1.3% and 1.5% respectively — four of the six MTA-STS adopters are on Microsoft 365, one on Google Workspace, one behind Proofpoint.

We are not going to argue that this is the most urgent gap in the GTA, because it plainly is not — 79.3% of these businesses have not finished DMARC, and that comes first. But it is a clean measure of how far the market is from a current email security baseline, and it costs a small business essentially nothing to fix once the authentication work is done.

What to Do About It

If you are on Google Workspace, check whether you have an SPF record at all before anything else. On this sample that is a one-in-four chance of finding nothing. Then publish DKIM from the Workspace admin console (it is not on by default), add a DMARC record at p=none with a reporting address, read the reports for a few weeks until you know every legitimate sender, and move to p=quarantine and then p=reject. The reporting stage is the part people skip, and it is the part that stops you blocking your own invoices.

If you are on Microsoft 365, you are more likely to have SPF and a DMARC record already — and roughly half as likely to have finished the job, since 50.4% of Microsoft 365 domains with DMARC are parked at p=none. Moving off p=none is the single highest-value email change most GTA businesses can make this quarter. Our guide to Microsoft 365 security best practices covers the tenant-side settings that belong alongside it.

If you run your own mail server, your SPF discipline is good — every self-hosted domain in the sample publishes SPF — but only 41.5% publish DMARC. You are also the group carrying the most operational risk per person, because reputation, patching and deliverability are all yours.

If your mail runs through your web host, treat any existing DMARC record as unverified until you have read it. Four in five of these domains have a record; one in fifteen has one that does anything.

You can check your own domain in about ten seconds with our free email spoof check tool — it reads the same public DNS records this study used, runs entirely in your browser, and sends nothing to us. For the wider picture, our IT risk calculator scores fourteen controls including this one.

Method, and What This Study Cannot Tell You

Sample. A random sample of 500 business domains drawn on 1 August 2026 with a fixed seed from a pool of 3,160 Greater Toronto Area business domains. On 5 August 2026, 479 were still mail-enabled — two fewer than on 1 August. The sample skews toward York Region and Vaughan, and toward businesses with a web presence; it is not a probability sample of all GTA businesses and should not be read as one.

Platform classification. Each domain's MX records were read and classified by mail exchanger hostname. This identifies the front door, not necessarily the mailbox. A domain behind Proofpoint or Mimecast is almost certainly running Microsoft 365 or Google Workspace behind it, and we counted it as the gateway because that is all DNS shows. This is why we describe 46.8% as a floor for Microsoft 365 rather than a point estimate. The 9.0% "other or unclassified" group is a genuine residual — mail exchangers we could not confidently attribute — and we have left it visible rather than distributing it across the named platforms.

Authentication data. SPF and DMARC values are carried forward from the 1 August scan of the same domains, so the cross-tab compares measurements four days apart rather than simultaneously. At the sample level the two scans agree closely: SPF 91.7% then, 92.1% now; DMARC 52.4% then, 52.6% now; enforcement 20.6% then, 20.7% now.

DKIM is not in this study. DKIM cannot be enumerated from DNS without guessing selector names, and our earlier study's common-selector probe undercounts real deployment. We have left it out rather than publish a number we would have to caveat into meaninglessness.

Small groups. Any row in the tables above with fewer than roughly fifteen domains should be read as directional only. We have published the counts alongside every percentage so you can judge that yourself. Zoho (4 domains) is in the share table for completeness and deliberately absent from the posture analysis.

No domain is named. All results are aggregate. We are not publishing which businesses are exposed, and we will not provide the list.

This is the second measurement in a series. The first, our GTA small-business cybersecurity report, established the authentication baseline; an earlier scan of 118 domains established the method. We intend to re-run the platform scan on the same sample so that the market share and the enforcement rates become a time series rather than a snapshot. Journalists, researchers and other providers are welcome to cite these figures with attribution to IT Rapid Support.

Where IT Rapid Support Fits

We run this measurement because it is our market. IT Rapid Support is a managed IT and cybersecurity provider working from 7810 Keele Street in Vaughan, and email authentication is one of the first things we fix in a new client environment — usually because it has never been done. We manage Microsoft 365 tenants, configure SPF, DKIM and DMARC to enforcement, and run managed cybersecurity with multi-factor authentication, endpoint protection, monitored backups and around-the-clock detection and response.

If you want to know where your own domain sits against these numbers, run the spoof check yourself, or call (289) 582-9930 and we will read your records with you. If it turns out your email authentication is already finished, we will tell you that and you will have spent ten minutes finding out.