Buy Ontario — So Why Isn’t Ontario Buying Canadian Technology?

Disclosure: I run Thexyz, a Canadian email hosting company. If Ontario moved public-sector email or hosting toward Canadian-owned providers, Thexyz would be a potential beneficiary of that policy. Read what follows with that interest in mind.

Ontario has spent much of the past year encouraging government agencies and the broader public sector to buy closer to home.

The province’s Buy Ontario Procurement Directive, effective April 13, 2026, requires public-sector organizations to prioritize Ontario and Canadian goods and services in procurement. The stated goals include supporting Ontario workers and businesses, strengthening local supply chains and reducing exposure to global economic and trade uncertainty.

But there is another supply chain that deserves the same attention: the technology used to run government itself.

Email, cloud hosting, office software, DNS, document storage, collaboration platforms, identity systems and web infrastructure are now critical public infrastructure. A review of publicly visible DNS records for several Ontario government and agency domains shows substantial reliance on foreign-owned technology companies including Microsoft, Amazon, Vercel and Namecheap — and, in a few cases, infrastructure endpoints outside Canada.

At the same time, governments elsewhere are moving in a different direction. France is shifting government workstations from Windows to Linux. Switzerland is building and testing an open-source workplace alongside Microsoft 365. Germany’s Schleswig-Holstein has migrated tens of thousands of mailboxes to Open-Xchange and is replacing Microsoft Office with LibreOffice. Denmark is testing LibreOffice-based alternatives. China continues to reduce its public sector’s dependence on Western desktop software.

Perhaps Ontario should be asking the same question.

What Ontario’s public DNS records show

DNS records do not reveal every detail of an organization’s infrastructure, and they cannot prove where every copy of data is ultimately stored. They can, however, show which networks, mail systems and DNS providers a public service depends on.

The following is a snapshot of publicly visible DNS information checked in September 2026. Where this table names a company, that is the registered owner of the IP address block in the ARIN or RIPE database, not a geolocation guess. CDN and anycast IP geolocation should be treated cautiously: an IP address can identify a provider or network without proving that every user’s traffic or every piece of stored data physically resides in the location shown by a geolocation database.

Anyone can look up DNS on a tool like Whats My DNS, View MY IP or our own DNS Lookup Tool.

Counts are from the 12 domains checked on September 8, 2026. The records behind each number are in the table below.

Methodology note: DNS records are a point-in-time snapshot and can change. A, MX and NS records identify public-facing infrastructure and service providers; they do not by themselves establish the location of every database, mailbox, backup or internal system. Data correct as of September 8th, 2026.

InfrastructureOntario.ca’s apex address, 217.114.94.2. The RIPE registry assigns this block to Episerver’s Stockholm hosting network, and the geolocation result agrees.

The most ironic example: Support Ontario Made

SupportOntarioMade.ca exists to help consumers and businesses identify and purchase products manufactured in Ontario. The Ontario Made program was created and is managed by Canadian Manufacturers & Exporters, and the Ontario government has funded and supported the initiative.

Its website is hosted on Linode, now part of Akamai, a U.S. company; the public A record 172.105.103.214 sits in Linode’s address space. Its DNS, by contrast, is hosted by Rebel.com, a Canadian registrar.

Its email tells a different story. The domain’s public MX records point to:

10 mx1.privateemail.com
20 mx2.privateemail.com

Those are the standard MX records for Namecheap Private Email. Namecheap states that it is a U.S.-based company headquartered in Phoenix, Arizona, and its own datacentre documentation lists Private Email servers in its Phoenix U.S. datacentre.

That makes for an awkward contrast: a provincially supported program built around buying Ontario-made products relies on an American company for email.

This is not an accusation that the program is doing anything improper. It is an example of how easily foreign technology becomes the default, even for organizations whose entire mission is built around strengthening local supply chains.

Ontario.ca itself shows the split

For ontario.ca, current public DNS records show:

ontario.ca
A   54.208.81.96

MX  ontario-ca.mail.protection.outlook.com

NS  edns2.gov.on.ca
    edns3.gov.on.ca
    edns4.gov.on.ca

The apex A record is an Amazon AWS EC2 host in the us-east-1 region, and it does only one thing: every request to ontario.ca receives a 301 redirect to www.ontario.ca. The MX record identifies Microsoft 365. At the same time, Ontario operates its own authoritative DNS infrastructure for the domain.

That distinction is important. Ontario is clearly capable of operating parts of its own digital infrastructure while outsourcing other layers to large foreign technology companies.

It is also worth noting that www.ontario.ca uses a different delivery path than the apex domain: it is a CNAME to Radware Cloud, a web application firewall and CDN service, and its responses carry Amazon CloudFront headers. So it would be inaccurate to claim that every Ontario.ca page or every visitor is simply “hosted in Virginia.” The defensible point is that the Ontario government depends on foreign-owned cloud infrastructure at several layers of its public digital presence.

Destination Ontario provides an unusually clear U.S.-region example

Destination Ontario’s public website sits in an AWS address block registered to Amazon Data Services Canada. Its incoming email, however, is directed to:

inbound-smtp.us-east-1.amazonaws.com

The us-east-1 label is AWS’s Northern Virginia region. This does not prove that the final mailbox or every stored copy of a message remains in Virginia, but it does show that inbound mail processing depends on a U.S. AWS region.

That is a useful illustration of what digital sovereignty actually means. The question is not only, “Where is the hard drive?” It is also:

• Who controls the infrastructure?
• Which jurisdiction governs the supplier?
• Could the organization realistically move elsewhere?
• Is there a viable domestic alternative?
• What happens if the service becomes unavailable, unaffordable or politically problematic?

Microsoft 365 is widespread across Ontario public organizations

Microsoft’s role is especially visible in public MX records. For example:

ontario.ca
→ ontario-ca.mail.protection.outlook.com

ontariocreates.ca
→ ontariocreates-ca.mail.protection.outlook.com

lcbo.com
→ lcbo-com.mail.protection.outlook.com

An MX hostname ending in mail.protection.outlook.com is strong evidence that Microsoft’s Exchange Online Protection / Microsoft 365 infrastructure is involved in receiving email for the domain.

What it does not prove is that those organizations’ mailbox data is physically stored in the United States. Microsoft operates Canadian cloud regions and offers Canadian data residency options.

So the stronger question is not simply, “Is Ontario government email stored in America?”

Why is so much critical Ontario government technology dependent on foreign-owned platforms when Ontario is actively encouraging domestic procurement?

Why “Microsoft has a Toronto region” is an incomplete answer

The usual reply to the question above is that Microsoft, Amazon and Google all operate Canadian cloud regions, so Ontario’s data can stay in Canada. That is true as far as it goes. It answers the question of where the data sits. It does not answer the question of whose law governs it.

The United States Clarifying Lawful Overseas Use of Data (CLOUD) Act, passed in 2018, allows U.S. legal process to compel a provider subject to U.S. jurisdiction to produce data in its possession, custody or control regardless of whether that data is stored inside or outside the United States. A U.S.-headquartered company running a datacentre in Toronto or Quebec City is still a U.S. company.

Microsoft has said as much in public. On June 18, 2025, Anton Carniaux, director of public and legal affairs at Microsoft France, was asked by a French Senate committee whether he could guarantee under oath that French citizens’ data would never be handed to U.S. authorities without the French government’s agreement. His answer was: “No, I cannot guarantee that, but, again, it has never happened before.” He added that Microsoft has contractually committed to resist requests it considers unfounded.

That is an honest answer, and it is the same answer a Canadian public body would get. Canadian data residency controls where data is stored. It does not control which government can compel access to it. Customer-managed encryption keys and similar controls can narrow the exposure, but they do not change the jurisdiction the vendor answers to.

None of this means U.S. authorities are reading Ontario’s email. It means that the question “is our data in Canada?” and the question “is our data under Canadian law?” have different answers, and procurement policy should be asking the second one.

Other governments are already moving

Several European governments, and China, are treating operating systems, email and cloud infrastructure as matters of national capability rather than ordinary software purchasing. The approaches differ, but none of them starts by banning Microsoft. They start by building and testing an alternative so that Microsoft is not the only realistic option.

Switzerland’s version is the most transferable to Ontario: build the alternative, test it, use it for real workloads, identify the gaps and then decide how far migration should go. Schleswig-Holstein shows the model can be taken all the way to core email and office workloads. The state said the migration was already saving more than €15 million in licensing costs, while acknowledging that some workloads still depend on Microsoft software and need further work.

What Munich actually teaches

Anyone proposing this will be told about Munich. From 2004 the city migrated its desktops to a Linux distribution called LiMux and to open-source office software, and in 2017 the council voted to move back to Windows. The episode is routinely presented as proof that public-sector open source fails. The record is more complicated than that.

The review that preceded the reversal was commissioned by Mayor Dieter Reiter, who had described himself as a “Microsoft fan” before taking office and took credit for bringing Microsoft’s German headquarters to the city. The consultants, Accenture and arf, found that the problems troubling LiMux were primarily organisational: fragmented IT across departments, unclear structures and responsibilities, and outdated software, rather than anything inherent to Linux. Their report did not recommend a wholesale return to Windows; it recommended consolidating the city’s IT organisation and moving toward platform-independent applications. The decision to go further and replace Linux entirely was a political one taken by the SPD and CSU council majority.

Munich’s politics have since moved on. The 2020 coalition agreement between the SPD and the Greens adopted the principle of “Public Money, Public Code” and committed the city to open standards and open-source software where technically and financially possible. The city established an Open Source Program Office in 2024. And the coalition agreement for 2026 to 2032, between the Greens, the SPD and the FDP/Free Voters, makes open source the default for municipal software procurement and strengthens that office.

So the honest lesson from Munich is not “open source failed.” It is that a migration run without central IT governance is fragile, and that a decision taken for political reasons can be reversed for political reasons. Both of those lessons apply equally to any Microsoft deployment.

The case for the status quo

It would be dishonest to pretend the current arrangement is an accident or an oversight. There are real reasons the Ontario Public Service and its agencies run on Microsoft.

The province buys through centrally negotiated enterprise agreements, which give predictable pricing, volume discounts and a single vendor to hold accountable. Microsoft 365 holds the security certifications that public-sector procurement asks for, and Microsoft publishes its compliance position against Canadian government requirements, including Protected B workloads. Entra ID is not just a login system: it is the identity layer that device management, conditional access, Teams, SharePoint and a long tail of line-of-business applications all depend on. Unplugging email from that stack is a much larger job than swapping one mail server for another. Tens of thousands of public servants, and the IT staff who support them, are trained on Outlook, Teams and SharePoint, and retraining at that scale has a real cost that does not show up on a licence invoice.

There is also a fair question to put to any Canadian vendor, including my own company: can you run mailboxes at the scale of the Ontario Public Service, with the uptime, compliance reporting, legal hold, retention, accessibility and support obligations a government carries? I am not aware of any Canadian provider that has done that at OPS scale today. That is not a reason to stop asking; it is the reason a pilot is the right next step, because the only way to find out whether a domestic supply chain can carry this load is to give it a real workload and measure the result.

Ontario already has much of the policy framework

Ontario may already have much of the policy justification needed to explore a similar approach.

The Buy Ontario Procurement Directive says public procurement should prioritize Ontario and Canadian goods and services while supporting Ontario businesses, strengthening local supply chains and reducing exposure to international uncertainty.

Ontario’s Digital and Data Directive also requires ministry and agency digital services to use technology that is scalable, interoperable, secure, accessible and open.

Ontario’s Digital Service Standard goes even further. It says public digital services should use open standards, favour open tools with strong developer communities, maintain the ability to move between technologies and avoid restrictive long-term contracts.

Those are strong principles. The question is whether they should be applied more aggressively to government IT purchasing and vendor concentration.

This does not require throwing Microsoft out

There is a tendency to frame this debate as Microsoft versus open source. That misses the point.

Microsoft 365 is a mature platform with enormous capabilities. Replacing Exchange, Teams, SharePoint, Entra ID, Intune and Office simultaneously would be difficult, expensive and disruptive.

Switzerland offers a more practical model: start with workloads that can realistically move.

Email could be one. Office documents could be another. File sharing, video conferencing, web hosting, DNS, backup and public-facing services could each be evaluated independently.

A government does not have to eliminate every foreign product to become more digitally sovereign. It simply needs to retain meaningful choices and ensure that domestic suppliers have a realistic path into public procurement.

Ontario could start with a Canadian technology pilot

Instead of asking Ontario to replace Microsoft 365 across the entire public service, the province could begin with something much smaller.

Ontario could invite Canadian-owned providers and open-source vendors to participate in pilots involving:

• departmental or agency email;
• public-facing mailboxes;
• Canadian-hosted collaboration;
• DNS;
• website and application hosting;
• backup and disaster recovery;
• open-source office applications;
• workloads involving sensitive Canadian data.

The purpose would not be to declare that one Canadian vendor should replace Microsoft.

The purpose would be to establish whether Ontario has a viable domestic technology supply chain — and, where gaps exist, whether government procurement can help build one.

Buy Ontario should include technology

Ontario’s Buy Ontario policy makes intuitive sense when we are talking about steel, vehicles, food or construction materials.

Digital services are easier to overlook because they are invisible.

But email is infrastructure. Cloud computing is infrastructure. Identity systems are infrastructure. DNS is infrastructure. Government websites are infrastructure.

Collectively, they are as important to the operation of government as many of the physical products covered by domestic procurement policy.

France, Germany, Switzerland and Denmark are not moving toward open source because Microsoft suddenly stopped making good software.

They are doing it because dependence itself has become a strategic risk.

If Ontario is serious about buying Ontario and buying Canadian, why shouldn’t that include the technology that runs Ontario too?

Sources and further reading

• Government of Ontario — Buy Ontario Procurement Directive
• Government of Ontario — Digital and Data Directive
• Government of Ontario — Digital Service Standard
• Government of Ontario — launch and support of the Ontario Made program
• Ontario Made — About the program
• Namecheap — Private Email MX records
• Namecheap — datacentre locations
• U.S. Department of Justice — The CLOUD Act
• The Register — Microsoft France testimony to the French Senate on the CLOUD Act, July 2025
• Balsillie Papers — The U.S. CLOUD Act and Canadian data
• Swiss Federal Chancellery — BOSS open-source feasibility study
• Swiss Federal Chancellery — sovereign workplace program, September 2026
• Government of France — reducing extra-European digital dependencies
• Schleswig-Holstein — Open Innovation and Open Source Strategy
• Denmark — open-source office pilot
• Denmark — Digital Sovereignty Action Plan
• Reuters — Microsoft’s changing role in China
• China Government Procurement — 2026 office-software framework
• FSFE — What happened in Munich (2017 Accenture/arf review)
• FSFE — Munich commits to “Public Money? Public Code!” (2020 coalition agreement)
• heise online — Munich’s 2026–2032 coalition makes open source the default
• City of Munich — Open Source principles and Open Source Program Office
• Public DNS snapshot — Ontario.ca
• Public DNS snapshot — Gov.on.ca

DNS records referenced in this article were checked in September 2026. DNS, routing, cloud regions and service-provider configurations can change. Public DNS records should be understood as evidence of visible service dependencies, not as a complete map of an organization’s internal systems or a definitive statement about the residency of all stored data.