Detect Google Workspace via `google._domainkey` TXT (DKIM) behind gateways — pending upstream validation

[fpietrosanti]

Follow-up to #14 (gateway look-through). While censusing unmapped gateways (scripts/find_gateway_candidates.py) we found a Microsoft/Google detection asymmetry in the inherited classification logic.

Finding

Our DKIM lookup (dns.lookup_dkim) follows CNAMEs only (selectors selector1, selector2, google):

# src/mail_sovereignty/dns.py
chain = await lookup_cname_chain(f"{selector}._domainkey.{domain}", max_hops=1)

• Microsoft: selector1._domainkey is a CNAME → *.onmicrosoft.com → detected. Plus the getuserrealm tenant check (lookup_tenant).
• Google: google._domainkey is a TXT key (v=DKIM1; k=rsa; p=…), not a CNAME → not read. There is no Google equivalent of the getuserrealm tenant check.

The same limitation exists upstream in davidhuser/mxmap (probes.probe_dkim is CNAME-only) — reported and pending validation there: davidhuser/mxmap#28.

Effect

Google-behind-gateway entities fall to independent/local-isp despite include:_spf.google.com and a google._domainkey TXT key. Example: the Sardinian regional health agencies (ASL) behind the sardegnasalute.it antispam relay — 11 entities → Google Workspace, currently classified independent (e.g. aslnuoro.it, aslgallura.it both have google._domainkey TXT). Also halleysardegna.it, ouverture.it.

Plan (ON HOLD pending upstream feedback)

1. Add a google._domainkey TXT check (query the selector as TXT; a v=DKIM1 key → Google), closing the asymmetry — mirrored to whatever the upstream agrees on.
2. Then add the Google gateway keywords: sardegnasalute.it, halleysardegna.it, ouverture.it.
3. Re-run the pipeline + verify the affected entities flip to Google; quantify the CLOUD-Act/ISD impact.

Do not implement until davidhuser/mxmap#28 is validated. We want to keep parity with upstream rather than diverge.

cc #14