
<p>
In this episode, I discuss my ongoing project aimed at mapping the dependencies municipalities have on major third-party digital services, particularly focusing on <strong>
Microsoft</strong>
 and <strong>
Google</strong>
, given their dominance in the market.</p>
<p>
The aim of this research isn't about debating the quality of these products—it's assumed that with thousands of employees, these services meet most quality expectations. Instead, the focus is on the critical implications of widespread dependency and potential risks related to service interruptions or supply chain attacks.</p>
<p>
<br>
</p>
<h2>
Why is this important?</h2>
<ul>
<li>
<strong>
Supply Chain Attacks</strong>
: High dependency means higher vulnerability to targeted disruptions.</li>
<li>
<strong>
Business Continuity</strong>
: Significant risks were illustrated by incidents such as the <strong>
CrowdStrike outage in July 2024</strong>
, which forced Brussels Airport back to pencil-and-paper operations temporarily.</li>
</ul>
<h2>
My Research Approach:</h2>
<p>
Primarily, I analyze the <strong>
DNS MX records</strong>
 of municipalities:</p>
<p>
<br>
</p>
<ul>
<li>
MX records typically reveal if mail services are hosted on Microsoft (Office 365/Exchange Online) or Google (Workspace).</li>
<li>
A high probability that using these providers for email also means municipalities likely depend on the respective cloud office suite (e.g., Word/Excel/SharePoint or Docs/Sheets/Drive).</li>
</ul>
<h2>
Preliminary Observations:</h2>
<ul>
<li>
<strong>
Belgium, Finland, Netherlands</strong>
: Over <strong>
70% of municipalities</strong>
 rely heavily on Microsoft mail services, a significant warning sign of dependency.</li>
<li>
<strong>
Germany, Hungary</strong>
: Fewer than <strong>
5% of municipalities</strong>
 use Microsoft or Google explicitly via MX records, though caution is necessary. Here’s why:</li>
</ul>
<h3>
Challenges Identified:</h3>
<ul>
<li>
<strong>
Local MS Exchange Servers</strong>
: Municipally hosted local installations aren't externally identifiable via MX records.</li>
<li>
<strong>
Mail Proxies</strong>
: Some municipalities use mail proxy services (spam/phishing filters) obscuring the actual mail service used behind proxy domains.</li>
</ul>
<h3>
Techniques Tested:</h3>
<ul>
<li>
<strong>
SPF Records</strong>
: Often reveal the underlying email service, though they may contain outdated information, lowering reliability.</li>
<li>
<strong>
Telnet EHLO Commands</strong>
: Municipalities commonly obscure their SMTP headers, limiting usefulness.</li>
<li>
<strong>
Cloud Provider IP-Ranges</strong>
: Investigating if mail servers run on Google, Amazon, or Azure infrastructure. Even if identified, this alone doesn't clarify if proprietary or replaceable services are used.</li>
<li>
<strong>
TXT Records</strong>
: Occasionally contain subscription keys or mail-related settings (e.g., MS subscriptions, Mailjet), but again, could be historical remnants.</li>
</ul>
<p>
Unfortunately, none of these get to show me all of the third party services.</p>
<h2>
Community Call:</h2>
<p>
I'm reaching out to listeners and the broader community for ideas or techniques on reliably fingerprinting the actual digital service providers behind mail servers. Specifically:</p>
<p>
<br>
</p>
<ul>
<li>
How to accurately determine if servers run <strong>
Microsoft or Google services</strong>
?</li>
<li>
Any ideas to detect deployments of <strong>
Nextcloud</strong>
 or similar open-source alternatives?</li>
</ul>
<h2>
Resources:</h2>
<ul>
<li>
<strong>
Project Webpage</strong>
: <a href="https://jurgen.gaeremyn.be/map.html" rel="noopener noreferrer" target="_blank">
jurgen.gaeremyn.be/map.html</a>
</li>
<li>
<strong>
Source Code</strong>
: <a href="https://gitlab.com/jurgeng/mxcheck" rel="noopener noreferrer" target="_blank">
gitlab.com/jurgeng/mxcheck</a>
</li>
</ul>
<p>
<br>
</p>
<p>
I'm looking forward to all your suggestions in the comments!</p>


