DKIM probe: TXT fallback for Google Workspace (google._domainkey) — fixes the CNAME-only asymmetry - #34
Open
fpietrosanti wants to merge 1 commit into
Open
Conversation
probe_dkim was CNAME-only, but standard Google Workspace publishes its DKIM key as a TXT record (v=DKIM1) at google._domainkey — so the GOOGLE signature's dkim_selectors could never fire. When the CNAME query for a Google selector yields nothing, fall back to a TXT query and treat a v=DKIM1 answer as Google DKIM evidence. Fallback is gated to the Google signature: its selector names are Google-distinctive, unlike selector1/selector2. Field-validated on the Italian PA dataset (mxmap-it/mxmap.it fork): 1,057 of 6,405 confirmed-Google domains (16.5%) publish the TXT key and were invisible to the CNAME-only probe; false positives 4/600 (0.67%, dual-config tenants). Re-files davidhuser/mxmap-ch#28 per maintainer request. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Aug 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-filing davidhuser/mxmap#28 here at the maintainer's request (that repo is frozen in favour of this one). Issues are disabled on this repository, so I'm filing the report as a PR with the fix included — happy to adapt or split it however you prefer.
Problem
probe_dkimqueries CNAME only (resolve_robust(qname, "CNAME")+dkim_cname_patterns). But standard Google Workspace publishes its DKIM key as a TXT record atgoogle._domainkey.<domain>(v=DKIM1; k=rsa; p=...), not a CNAME. So the GOOGLE signature'sdkim_selectors=("google", "google2048")can never fire for ordinary Google tenants — effectively dead code — while the equivalent Microsoft signal (selector1/selector2 CNAME →*.onmicrosoft.com) works.This matters most behind gateways/relays: the MX points at the filter and SPF is often ambiguous, so DKIM is the decisive backend signal — and it's structurally unavailable for Google.
Quick check:
Fix
When the CNAME query for a selector yields nothing and the signature is GOOGLE, fall back to a TXT query on the same qname; a
v=DKIM1answer is emitted as GoogleEvidence(sameSignalKind.DKIMweight). The fallback is gated to the Google signature because its selector names are Google-distinctive — a stray TXT atselector1must not classify (covered by a test).CNAME behaviour is unchanged; 3 tests added mirroring the existing mock style.
tests/provider_classification/test_probes.py: 68/68 pass.Field validation (Italian PA dataset, ~23k entities)
We run a downstream fork for Italian public administrations (mxmap-it/mxmap.it, tracking issue #17) and validated exactly this fallback against all entities already classified as Google by other signals:
google._domainkeyTXT key — every one of them invisible to the CNAME-only probe.Public, verifiable examples (Italian):
carabinieri.it,izssicilia.it— TXT present, CNAME absent.🤖 Generated with Claude Code