DKIM probe is CNAME-only → Google Workspace (TXT google._domainkey) not detected; asymmetric vs Microsoft #28

Hi David — thanks for mxmap and the ESORICS work. We run a downstream fork focused on the Italian public administration (mxmap.it). While auditing inbound email-security gateways we hit what looks like an asymmetry in DKIM-based provider detection, and we'd like to validate it with you before sending a PR.

Observation

probes.probe_dkim queries each DKIM selector as a CNAME:

# src/mail_sovereignty/probes.py
async def probe_dkim(domain: str) -> list[Evidence]:
    """Query DKIM selector CNAMEs and match targets."""
    for sig in SIGNATURES:
        for selector in sig.dkim_selectors:
            qname = f"{selector}._domainkey.{domain}"
            answer = await resolve_robust(qname, "CNAME")   # CNAME only
            ...
            if match_patterns(target, sig.dkim_cname_patterns):
                ...  # Evidence(kind=DKIM, ...)

This works for Microsoft 365, whose selector1._domainkey is a CNAME → *.onmicrosoft.com.

But the Google signature also expects a CNAME:

# src/mail_sovereignty/signatures.py — Provider.GOOGLE
dkim_selectors=("google", "google2048"),
dkim_cname_patterns=("domainkey.google.com",),

Google Workspace publishes google._domainkey.<domain> as a TXT DKIM key (v=DKIM1; k=rsa; p=…), not a CNAME to domainkey.google.com. So the CNAME query returns nothing and dkim_cname_patterns=("domainkey.google.com",) (almost) never matches a real Workspace domain → no DKIM evidence for Google.

Impact

DKIM carries the highest single weight (WEIGHTS[DKIM] = 0.15). When the MX is an inbound security gateway/relay that hides the real provider (Libraesva, Proofpoint, Barracuda, regional relays…), Microsoft still wins via its DKIM CNAME, but Google loses its strongest signal and falls back to weaker/optional ones (_spf.google.com, google-site-verification=) — or to "independent/unknown". Net effect: Google Workspace is under-detected behind gateways, asymmetrically vs Microsoft.

Real-world evidence

Italian regional healthcare: sardegnasalute.it is an inbound antispam relay in front of ~11 regional health agencies (ASL). Their domains publish a Google Workspace DKIM TXT at google._domainkey.<domain> and include:_spf.google.com, yet emit no DKIM evidence under the CNAME-only probe. Verifiable today:

• aslnuoro.it → google._domainkey.aslnuoro.it IN TXT v=DKIM1; k=rsa; p=…
• aslgallura.it → same; MX = mx0X.sardegnasalute.it (relay, non-Google IP)

Question / validation request

1. Is the CNAME-only DKIM probe intentional, rather than also reading the selector as TXT and recognizing a v=DKIM1 key?
2. Would you accept a PR that, when a selector does not resolve as CNAME, falls back to a TXT lookup and emits DKIM evidence on a v=DKIM1 key (e.g. Google for google/google2048)?

We have a concrete dataset (Italian PA) where this materially changes provider attribution, and we're happy to contribute the fix + tests once you confirm the direction. Downstream tracking issue to follow.

Thanks!