DKIM is not free with hosted mail
It’s easy to assume a hosted mail service takes care of DKIM (DomainKeys Identified Mail). For your own domain, Google Workspace and Microsoft 365 both leave the key to the customer to set up. In the September 2026 census, 36,263,291 graded domains have one of the two as their mail host, and the census looked each one up at the DKIM selector its provider tells customers to publish. 23,989,381 of them, 66.2%, had no key there: 59.1% of the 21,565,738 Google Workspace domains and 76.5% of the 14,697,553 Microsoft 365 domains. Under gTLDs the two shares are 56.3% and 78.9%, and under ccTLDs 69.3% and 72.0%.
Both providers document it as a step for the customer. Microsoft’s guide to DKIM for custom domains says: “Currently, no DKIM signing occurs for outbound mail from custom domains.” The admin has to publish two CNAME (Canonical Name) records and turn signing on. Google’s setup page has the admin generate a key, publish it as a TXT (Text) record at google._domainkey, and then click Start authentication.
Figure 1. Domains with a DKIM key at their provider’s selector, as a share of the domains the census probed there.
Why a missing key matters
A receiving server applies DMARC (Domain-based Message Authentication, Reporting and Conformance) when the address in the From line belongs to a domain that publishes a DMARC record. The message passes when SPF (Sender Policy Framework) or DKIM passes for that same domain. Without a DKIM key for its own domain, and with no other service signing for it, a Google Workspace or Microsoft 365 domain can pass DMARC only through SPF. SPF checks the server that handed the message over, so a message forwarded through another server usually loses that pass. Microsoft makes the same point in its advice to senders.
The large mailbox providers now ask bulk senders for DKIM outright. Since 1 February 2024, Gmail has required SPF and DKIM from anyone sending more than 5,000 messages a day to personal Gmail accounts, and since 5 May 2025 Outlook.com has required a passing DKIM signature from domains sending it that many.
How the count was taken
The census reads a domain’s MX (Mail Exchange) records and, for domains with mail, looks for a DKIM key. It can’t list every key a domain has, because a key sits under a name the domain owner chooses, the selector, and DNS (Domain Name System) has no way to list them. Wang and colleagues name this as the central problem of measuring DKIM in their 2022 USENIX Security study. For the September edition the census engine asked for the selectors each recognised mail provider uses: google when the MX host is Google’s, selector1 and selector2 when it is Microsoft’s outlook.com. That gives “no key” a definite meaning for these two cohorts: the census looked where the provider puts the key.
A domain is in a cohort when the first MX record it publishes points at the provider, the same rule the data page uses. That gives 21,565,780 Google Workspace and 14,697,577 Microsoft 365 domains. The engine stored the selectors it asked for, and all but 66 of these domains were asked at their provider’s selector. The few left over have MX records written in a way that sent the engine to another provider’s selectors, so they’re left out, and every share on this page is of the rest.
A key counts when the record looks like DKIM and carries a public key at least 50 characters long, the engine’s own test. For Microsoft 365 a key at either selector counts. “No key” includes lookups that failed during the scan, so on 4 October 2026 we looked up a random sample again. Of 500 Google Workspace domains with no key in September, 14 had one on the re-check, and 7 of 500 Microsoft 365 domains. Some of those may have added a key in the month between, so in the sample the census missed at most that many. Of the domains that had a key in September, 483 of 500 Google Workspace and 489 of 500 Microsoft 365 domains still had it.
The two providers side by side
Shares of the domains the census probed at the provider’s selector:
| Google Workspace | Microsoft 365 | |
|---|---|---|
| Domains probed | 21,565,738 | 14,697,553 |
| Key at the provider’s selector | 40.9% | 23.5% |
| No key | 59.1% | 76.5% |
| No key, gTLD domains | 56.3% | 78.9% |
| No key, ccTLD domains | 69.3% | 72.0% |
Key size
Shares of the domains with a key at the provider’s selector:
| Key | Google Workspace | Microsoft 365 |
|---|---|---|
| RSA (Rivest-Shamir-Adleman) 2048-bit or longer | 93.5% | 76.2% |
| RSA 1024-bit | 5.9% | 20.5% |
| A key cut short | 0.6% | under 0.01% |
| Two keys of different sizes | 3.3% | |
| Any other length | 0.03% | under 0.01% |
| Domains with a key | 8,822,462 | 3,451,448 |
20.5% of the Microsoft 365 keys are 1024-bit, against 5.9% of the Google Workspace keys. RFC 8301 (Request for Comments) has signers use keys of at least 1024 bits and recommends 2048. Google’s setup page offers both and suggests 1024 only when the DNS host can’t take a 2048-bit record. Microsoft creates two keys per domain, one active and one waiting for the next rotation. Its PowerShell command for creating them defaults to 1024 bits, and a change to 2048 reaches the waiting key at the first rotation and the other at the second. That rotation order is one way a Microsoft 365 domain ends up with two keys of different sizes.
50,867 Google Workspace domains publish a key that stops before the length its own header declares, 48,377 of them 2048-bit keys. 60.2% of those records are exactly 255 characters long, the most one DNS text string can hold. A key cut short can’t verify a signature. The census engine still accepts it as a key, so these domains count as having one in the shares above.
Microsoft asks for two records, selector1 and selector2, and signs with one key at a time. 1,659,314 Microsoft 365 domains, 48.1% of those with a key, publish one at selector1 and nothing at selector2, nearly as many as the 1,709,123 with both. Microsoft lists a missing selector2 record among the common DKIM mistakes, and its signing moves to the other selector at the next key rotation.
Each key’s size here is the length its own header declares, checked against the key data actually published. A key whose data ends before that length counts as cut short. RFC 6376 allows spaces anywhere inside a key, so a key with spaces is measured whole.
Figure 2. DKIM key size at the provider’s selector.
Wang and colleagues found 84% of 3,627,871 domains in passive DNS data on keys of 1024 bits or less. Their domains, their method and their years differ from these two cohorts, so the two figures say nothing about a trend.
DMARC beside the missing key
Shares of the domains without, and with, a key at the provider’s selector:
| DMARC record | No key | Key |
|---|---|---|
| None published | 73.3% | 45.2% |
| p=none | 16.1% | 24.2% |
| p=quarantine | 7.6% | 15.4% |
| p=reject | 3.1% | 15.2% |
| Other or missing policy | 0.03% | 0.05% |
| Domains | 23,989,381 | 12,273,910 |
Most domains without the key publish no DMARC record either. Domains with the key publish one more often, 54.8% against 26.7%. 2,547,537 domains publish a quarantine or reject policy without the provider’s key. Unless they sign through another service under a selector of their own, their DMARC result depends on SPF alone.
Figure 3. DMARC policy of Google Workspace and Microsoft 365 domains, without and with a key at the provider’s selector.
By TLD
The 20 TLDs (Top-Level Domains) with the most domains in the two cohorts, which hold 87.3% of them, ranked by the share with a key. Each share is of that TLD’s probed domains, or of its keys in the last two columns.
| Rank | TLD | Domains probed | Key, both providers | Key, Google Workspace | Key, Microsoft 365 | Google keys 2048+ | Microsoft keys 2048+ |
|---|---|---|---|---|---|---|---|
| 1 | .info | 488,975 | 79.3% | 83.3% | 69.9% | 96.1% | 98.4% |
| 2 | .co | 588,201 | 52.1% | 56.2% | 41.9% | 95.8% | 95.7% |
| 3 | .fr | 269,975 | 40.5% | 42.9% | 38.5% | 86.9% | 77.8% |
| 4 | .io | 204,467 | 39.9% | 43.9% | 26.8% | 91.1% | 90.7% |
| 5 | .net | 1,106,713 | 37.7% | 48.3% | 18.8% | 94.4% | 69.0% |
| 6 | .ai | 208,635 | 36.9% | 43.0% | 21.7% | 93.2% | 97.9% |
| 7 | .org | 1,590,878 | 36.4% | 42.7% | 23.2% | 93.6% | 65.5% |
| 8 | .com | 21,633,273 | 33.9% | 42.5% | 19.2% | 94.5% | 75.9% |
| 9 | .de | 695,407 | 31.3% | 39.7% | 28.8% | 93.3% | 83.2% |
| 10 | .nl | 507,596 | 30.7% | 29.9% | 31.0% | 89.2% | 69.3% |
| 11 | .nz | 169,299 | 30.2% | 28.3% | 31.8% | 87.8% | 65.0% |
| 12 | .be | 188,742 | 30.2% | 24.6% | 32.3% | 82.7% | 65.8% |
| 13 | .ch | 194,361 | 28.7% | 20.7% | 31.7% | 86.1% | 73.8% |
| 14 | .in | 271,178 | 27.0% | 28.8% | 20.0% | 86.9% | 88.7% |
| 15 | .se | 172,392 | 26.8% | 24.2% | 28.0% | 81.9% | 61.8% |
| 16 | .uk | 1,266,370 | 25.5% | 29.7% | 22.6% | 91.1% | 68.5% |
| 17 | .it | 230,896 | 23.7% | 18.1% | 31.4% | 76.3% | 73.1% |
| 18 | .br | 394,537 | 23.6% | 20.0% | 31.8% | 75.1% | 77.6% |
| 19 | .au | 903,276 | 21.8% | 19.3% | 23.3% | 85.1% | 71.0% |
| 20 | .ca | 584,880 | 21.5% | 23.5% | 19.9% | 87.5% | 72.2% |
The share with a key runs from 79.3% under .info to 21.5% under .ca, against 33.8% across all TLDs.
Figure 4. Share of Google Workspace and Microsoft 365 domains with a key at the provider’s selector, by TLD.
Counted from SPF instead
Some domains send through Google or Microsoft while their MX points somewhere else, such as a filtering service in front of the mailbox. Counting by the SPF record instead catches them: 13,096,054 graded domains include _spf.google.com in SPF and 11,043,146 include spf.protection.outlook.com. The engine chose its selectors from the MX host, so 97.9% of the Google group and 96.7% of the Microsoft group were asked at the provider’s selector. Of those, 39.1% of the Google group and 67.9% of the Microsoft group had no key there. A domain whose filtering service signs for it under another selector counts here without a key.
What the census can’t see
- A key in DNS doesn’t show that signing is switched on. Google has a separate Start authentication step, and Microsoft a signing switch, after the record is published.
- Google lets an admin change the selector from
googleto another prefix. A domain that did is counted here without a key. - A domain can send through other services that sign with their own selectors. The census asked only at the provider’s.
- Microsoft’s newer inbound host names end in
mx.microsoftand aren’t on the data page’s provider list, so those 18,423 domains are outside the Microsoft 365 cohort. - The census reads DNS records and sends no mail, so it can’t see which signature a message actually carries.
See your own
The free scan looks up a domain’s DKIM key at its provider’s selector, live. The setup guides for Google Workspace and Microsoft 365 give the exact records, and finding your DKIM selector covers mail sent through other services.
Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. The live re-check was made on 4 October 2026. Census numbers move every month; the current values are on the data page.