What the measurements have shown, one finding at a time. Each finding says how it was checked and links to the raw data. Every number is computed by fynd_siffror.py and checked against the page by a test. Errors in our own method are under Corrections and review.
We asked 43 municipalities and regions: the MX rule held, two others failed
33 of 43 replied
To test the email classification, we asked 43 municipalities and regions which email service they use, without telling them what Molnkartan shows about them. The ground truth was taken from the technical headers of their replies, with rules and requirements written before the question was sent. 33 replied within 14 days.
Microsoft via MX: passed. 5 of 5 replied from Microsoft (requirement 90 %).
Microsoft via SPF, DKIM or autodiscover: failed. 5 of 7 replied from Microsoft (requirement 80 %). One of the others wrote that they run their own email: configuration for Microsoft in DNS does not mean the mailbox is there.
Google: failed. 5 of 7 replied from Google (requirement 80 %). The other two replied from Microsoft, which matches the finding about municipalities that receive email at Google but have DKIM at Microsoft.
No cloud signals: 3 of 6 replied from Microsoft. DNS showing no cloud does not mean there is none.
What we changed: the pages now say that organisations have Microsoft in their email DNS, not that their email goes there, and that the Google municipalities receive email at Google.
How it was checked
The headers show which system the replying mailbox is in, not which server receives email first. Replies from case-management systems and auto-replies often show neither Microsoft nor Google and then count as other; 5 such replies said in the text that they run their own email or Microsoft 365, but the text is only used where the headers are ambiguous. One reply came from a municipal association the question had been forwarded to and is not counted. With 7 replies per class, a single reply moves the result by more than 10 percentage points. 10 did not reply and are reported as non-responses.
Almost all municipalities have their domain registered in Microsoft's email service
305 of 310
In DNS, email points to Microsoft at 245 municipalities and regions: at 189, Microsoft receives the email according to the MX record, and at 56 a spam filter or their own server comes first but SPF and DKIM or autodiscover are configured for Microsoft. The latter show configuration, not where the email actually ends up, and the test against ground truth showed that the difference matters. Sollentuna, Norrköping and Halmstad are configured for both Microsoft and Google.
Microsoft's own email configuration service also responds that the domain is registered in an Exchange Online organisation for 305 of 310, including all 32 where DNS was not enough, 19 of 20 without cloud signals in DNS and 7 of 10 that receive email at Google. Among agency domains, this applies to 142 of 202, the Swedish Tax Agency included. The registration does not show that email is received or stored there; that 7 of 10 Google municipalities answer yes shows the limit.
How it was checked
The checks test different parts of the measurement chain and share some of it: the email class was queried via three other DNS resolvers (512 of 512 identical; same records and same rules, so this tests the resolvers, not the rules), Microsoft accounts via a second Microsoft endpoint (512 of 512), the networks behind third-party hosts via RIPEstat (338 of 338 same ASN; this tests the registry, not which address the browser used). The Exchange Online check first failed its requirement because of a bug in our code and throttling; after the correction, 331 of 333 among those classified as Microsoft. A later run from GitHub Actions did not meet the requirement and is not published. Only yes or no is stored.
At half of the municipalities, no service names were found on US networks
150 of 289 municipalities
Certificate logs show names under an organisation's domain that have been issued a certificate: e-services, booking, login pages, websites and the like. At 150 of 289 municipalities, no such name was found with an address on a US network; the median per municipality is 0 %. This does not mean the municipality has no US services: names without their own certificate, services on the provider's domain and names covered only by wildcard certificates are not visible.
Counting all names, 15.7 % of the municipalities' 5,342 names are on US networks, including CDNs such as Cloudflare, but the total is driven by a few: a single municipality accounts for 25 % of the municipalities' names on US networks. Regions are higher: 19 of 20 have at least one name on a US network and the median is 13 %. Among agency domains the median is 3 %. Of all names, most are on networks owned by European companies, 14 on networks in other countries and 16 on networks that could not be identified; the measurement does not say where the servers are located.
How it was checked
The names come from crt.sh, with Certspotter as a fallback. A name counts if it has a public IPv4 address at the time of measurement; that does not show a service actually runs there. Names pointing to internal addresses (1,268 in total) are not counted, and the number is stored only as a total. No hostnames are stored or published. The first run failed the requirement for the share of names with a known network and was never published.
For comparison, 20 randomly selected organisations were also measured with the second source: the share differed by at most 15 percentage points for 18 of 20 (requirement 16). This compares shares, not whether the list of names is complete, and both sources read the same certificate logs. The tolerance is not enough to test the zero category: for Grums the main source found no names on US networks but the second source did. The direction of the error from wildcard certificates and domain selection has not been investigated.
30 of 193 measurable agency domains made requests to Google Tag Manager or Google Analytics before the visitor had given consent. 11 of them called Google Analytics servers, where visitor statistics are received; the other 19 only called Tag Manager. The Swedish Armed Forces are one of those that load Tag Manager.
How it was checked
The measurement records request attempts in the browser's network log; whether the request succeeded is not stored. The Swedish Armed Forces were checked in a regular Chrome without a consent cookie: googletagmanager.com/gtm.js was in the browser's resource list, so it was loaded, but there were no requests to Google Analytics. A successful request to Tag Manager gives Google the visitor's IP address and browser information; it does not mean visitor statistics are collected.
Sixteen municipalities call Google Analytics or Tag Manager before consent
16 of 306
Eleven municipalities' pages made requests to Google Analytics servers, where visitor statistics are received, while the cookie banner was still unanswered: Valdemarsvik, Emmaboda, Borgholm, Hässleholm, Dals-Ed, Färgelanda, Mellerud, Åmål, Norsjö, Storuman and Pajala.
Five only called Google Tag Manager, without any request to Google Analytics: Jönköping, Oskarshamn, Sölvesborg, Vänersborg and Sunne. A successful Tag Manager request gives Google the IP address and browser information but does not by itself collect visitor statistics.
Hässleholm's request contains a parameter suggesting Google's Consent Mode, where cookieless requests are sent before consent. Whether that complies with the rules is not decided here.
How it was checked
Headless Chrome with a network log, no button clicked. The log shows request attempts; whether the request succeeded is not stored. In a regular Chrome, Hässleholm's request reached Google Analytics, which responded (HTTP 503), and Tag Manager loaded for Jönköping and Sunne. Before each run we check that a blank page gives zero hits and that a page with Google Analytics gives a hit. All sixteen were measured again on 9 October with the same result.
The cookie banner itself is often loaded from a US network
31 municipalities and regions
At 31 municipalities and regions, the page calls the consent tool, the box where the visitor chooses whether data may be sent, on a server in a US company's network. Cookiebot is reached via Akamai (9), Cookie-Script via DigitalOcean (8), Cookie Information via Microsoft (5), and Cookie Tractor, CookieYes, Klaro and OneTrust via Cloudflare. A consent tool has to load before the visitor can answer; the finding concerns where it is loaded from.
For eleven of them, the cookie banner is the only contact with a US network before the visitor has chosen anything.
How it was checked
Each third-party host was looked up to its network (ASN) at the time of measurement. Which domains count as consent tools is defined in fynd_siffror.py. That a tool is fetched from a US network does not say where the tool's own servers and databases are.
The read-aloud service is the second most common on US networks
45 municipalities and regions
After Google (76), Texthelp's read-aloud service BrowseAloud, which reads the page aloud for those who need it, is the service most often called on a US network before consent. It is reached via Amazon CloudFront. It is an accessibility tool, not ad tracking.
How it was checked
The addresses were compared with Amazon's published list of IP addresses: they belong to CloudFront, a CDN with servers all over the world. The visitor is probably served by a server in Europe. Where Texthelp's own servers are located is not visible from the outside.
· Websites before consent
Twenty made no third-party requests before consent
20 municipalities and regions
Upplands Väsby, Huddinge, Eskilstuna, Trosa, Malmö, Landskrona, Eslöv, Trelleborg, Simrishamn, Partille, Orust, Gullspång, Filipstad, Gävle, Sundsvall, Ragunda, Vindeln, Övertorneå, Älvsbyn and Region Stockholm load everything from their own website before the visitor has answered. Two of them, Partille and Region Stockholm, have the website itself behind Cloudflare, a US CDN.
How it was checked
Huddinge was checked in a regular Chrome with an unanswered cookie banner: all 31 resources were fetched from www.huddinge.se.
Ödeshög, Ydre, Boxholm, Åtvidaberg and Vimmerby receive email at Google but have published DKIM keys at Microsoft. This suggests email is sent via Microsoft, but whether it is actually signed there was not checked; the keys may also be left over. Four of them are in Östergötland, where five of fourteen receive email at Google.
How it was checked
dig +short MX atvidaberg.se points to Google; dig +short CNAME selector1._domainkey.atvidaberg.se points to Microsoft. All five were checked again on 9 October.
· Security basics
One in three municipalities has DMARC in monitoring mode
97 of 310
DMARC is a DNS record where the domain owner tells receivers what to do with email that claims to come from the domain but fails the check. 97 municipalities and regions have p=none: they ask for reports but not for such email to be stopped; receivers then only apply their own filters. 132 have p=reject. 34 have published MTA-STS, which can prevent email to them from being sent unencrypted; whether the policy is actually enforced was not checked. DNSSEC is in place at 257.
How it was checked
The lookups were made via 1.1.1.1. The DNS signals were repeated via 9.9.9.9: 510–512 of 512 identical per signal. DNS errors count as errors, not as missing records, and a run with more than 2 % errors is not published. The result is reported only per county, and counties with fewer than five organisations are merged, never per organisation.
All municipalities and regions except Gällivare have a Microsoft Entra tenant on the measured domain. Gällivare has one on its other domain, gallivare.se. An account does not say how much it is used.
How it was checked
Microsoft's public OpenID address responds 200 for a domain with a tenant and 400 without. Checked against benbo.se and a made-up domain, both of which gave 400.
· Government agencies
The Swedish Tax Agency barely shows up in the measurement, and that is a finding
According to Ekot (Swedish Radio), the Swedish Tax Agency (Skatteverket) has adopted US cloud services on a large scale. In DNS, the agency has email on its own servers without cloud signals, and in the measurement the website made no third-party requests. What is visible is a Microsoft account and that the domain is registered in Exchange Online.
It shows how little can be seen from the outside. The measurements concern configuration and requests visible from the internet, not how dependent an organisation is on US clouds. Services used internally leave few traces.
We measured ourselves: US cloud, but no third parties
Molnkartan runs on GitHub Pages, which is owned by Microsoft and delivered via Fastly. The DNS measurements run every month in GitHub Actions on Microsoft's Azure; the web measurement is made from Sweden. With the same tools as for the municipalities: the site makes no third-party requests and sets no cookies, but the hosting is on a US network.
The difference from a municipality is that the site does not handle personal data or exercise public authority. But we do not want to claim anything about others that we do not say about ourselves.
Errors that we and our reviewers have found in the method, with dates. Nothing is rewritten afterwards; see also How it was made.
· Error in our method
A reviewer from another AI model found that we claimed too much
After our own reviews, we had Codex, a model from another company, review the whole project. It found errors our reviewers missed, because they were based on the same model as us. The most important:
The web measurement records request attempts in the browser's network log, not that contact succeeded. The findings said "contacts".
The Microsoft classification of email rests on different kinds of evidence: MX for most, but only published configuration (SPF, DKIM) for some. This is now reported separately.
The checks were called independent although several share a source or classification with the main measurement. Each check now describes what it can detect.
"Half of the municipalities have no services on US networks" was a claim of absence the measurement cannot support, and the check passed a case where the second source found US names.
That all numbers are "lower bounds" was not established for every measure, and the project's question about "dependence" is not measured directly.
In some failures (DNS timeout, Chrome crash, incomplete pagination) the code could silently give a negative answer instead of "could not be measured". No published numbers have been shown to be affected, and it is fixed: such failures now become "could not be measured".
An independent review found errors in our findings
Before sharing the site, we had a separate reviewer, who had not built the project and only had read access, try to disprove each finding against the raw data. Among other things, it found:
that the Google Analytics headline was wrong for five municipalities that only load Tag Manager,
that the Exchange Online finding claimed more than the measurement shows,
that the number with a consent tool on a US network was 31, not 28,
that two automatic runs that failed their requirements had been published anyway,
that DMARC p=none was described incorrectly, and
that Gotland County, with a single organisation, revealed individual values although the security basics are only to be reported in groups.
Everything is corrected on this page. Runs that fail their requirements are no longer published, and every number here is checked automatically against the raw data.
· Error in our method
Two tests failed before the website measurement held
The website rules were tested on counties they were not built on. A hand-written list of providers missed 51 % of the hosts in Skåne and 28 % in Västra Götaland, against the requirement of 10 %. No classifications from those runs were published. Version 3 classifies by the network behind each host and met the coverage requirement on Norrland, with a known network for 99 % of hosts. That measures that the classification can be made, not that it is right. Hässleholm's Google Analytics requests were discovered in the Skåne run and then confirmed separately.
The animation on the home page replays the measurement with real responses. For Åtvidaberg it showed a DKIM response that clearly pointed to Microsoft, while the signal said "none". The rule only recognised Microsoft's older format. After the correction, Gotland, Sjöbo and Bromölla changed from "could not be determined" to Microsoft. The correction is dated in the method, and the old numbers remain.