Selectors and how Cathedra finds them

DKIM verification depends on the receiver knowing which selector to use. The message itself carries that in the s= field of the DKIM-Signature header (lesson 4.2). But Cathedra is auditing a domain without sending or receiving a message. There is no header to read. The only signal Cathedra has is what TXT records exist in DNS.

So Cathedra guesses. It probes a fixed list of common selectors and reports what it finds.

This lesson covers exactly which selectors it tries, how the CNAME fallback works, and what the “no DKIM records found” warning really means.

The 14 selectors Cathedra probes

DkimRecordCheck.php defines a constant:

private const SELECTORS = [
    'default', 'google', 'selector1', 'selector2',
    'k1', 'dkim', 'mail', 'proofpoint', 'mimecast',
    's1', 's2', 'pm', 'mandrill', 'mailjet',
];

These are the 14 selector names used by the major mail providers and transactional senders we see on engagements. For each one, Cathedra queries {selector}._domainkey.{domain} and checks what comes back.

Which provider uses which selector:

Selector	Used by
selector1, selector2	Microsoft 365 (both, for key rotation)
google	Google Workspace
k1	Mailchimp / Mandrill (older)
default	Generic — many self-hosted servers, some appliances
dkim	Generic fallback used by various senders
mail	Generic; some on-prem and legacy setups
proofpoint	Proofpoint Essentials
mimecast	Mimecast
s1, s2	SendGrid, some other providers
pm	Postmark
mandrill	Mandrill (newer)
mailjet	Mailjet

The list covers the vast majority of clients we onboard. If a client uses Microsoft 365 (selector1 and selector2), Google Workspace (google), Proofpoint, Mimecast, SendGrid, Postmark, Mandrill, Mailchimp, or Mailjet — Cathedra will find their DKIM.

How the probe works

For each selector in the list, Cathedra runs two passes against {selector}._domainkey.{domain}:

1. TXT lookup first. If the host returns a TXT record containing v=DKIM1, k=rsa, or p=, that selector counts as found.
2. CNAME fallback. If no TXT record returns, Cathedra checks for a CNAME at the same host. If one exists, that also counts as found — the value stored in the result is CNAME → {target}.

The CNAME fallback matters because M365 specifically publishes DKIM as CNAMEs rather than direct TXT records. The CNAME at selector1._domainkey.isidoregroup.com points to a TXT record under isidoregroup.onmicrosoft.com. The receiver follows the CNAME automatically; Cathedra confirms only that the CNAME exists.

The relevant fragment of the check:

foreach ($records as $r) {
    $txt = $r['txt'] ?? '';
    if (str_contains($txt, 'v=DKIM1') || str_contains($txt, 'k=rsa') || str_contains($txt, 'p=')) {
        $found[] = ['selector' => $selector, 'value' => $txt];
    }
}

// Also try CNAME redirect
if (empty($records)) {
    $cnames = @dns_get_record($host, DNS_CNAME) ?: [];
    if (! empty($cnames)) {
        $found[] = ['selector' => $selector, 'value' => 'CNAME → ' . ($cnames[0]['target'] ?? '?')];
    }
}

The pass finding

If Cathedra finds at least one selector with a valid record or a CNAME, the check passes.

Cathedra status: pass

Finding text (verbatim, with substitutions):

N DKIM selector(s) found: {comma-separated list of selectors}

A clean M365 domain produces:

2 DKIM selector(s) found: selector1, selector2

A clean Google Workspace domain:

1 DKIM selector(s) found: google

A domain on Postmark with a fallback transactional sender on Mandrill:

2 DKIM selector(s) found: pm, mandrill

The selectors are listed in the order Cathedra probed them, which matches the order in the constant.

The warning finding

If no selector returns anything — no TXT, no CNAME, across all 14 names — Cathedra warns.

Cathedra status: warning
Severity: medium

Finding text (verbatim):

No DKIM records found for common selectors (default, google, selector1, selector2, k1, dkim, mail, proofpoint, mimecast, s1, s2, pm, mandrill, mailjet). This may not be an error if a non-standard selector is in use.

Recommendation (verbatim):

Confirm DKIM is configured with your mail provider and verify the selector name.

Read the recommendation carefully: it says “this may not be an error.” That hedge is intentional. The check is a probe against common names — it cannot distinguish between “DKIM not configured” and “DKIM configured under a selector we didn’t try.”

This matters operationally. The two scenarios look identical to Cathedra and require different responses.

When the warning is a real failure

The probable cases when “no DKIM found” actually means DKIM is missing:

• Domain on M365 where the tenant admin never enabled DKIM in Defender. The CNAMEs at selector1 and selector2 won’t exist because Microsoft only publishes those once you turn DKIM on. (Lesson 4.4.)
• Domain on Google Workspace where Authenticate Email was never completed. The google._domainkey TXT will not exist. (Lesson 4.5.)
• New domain that was migrated to a cloud provider but DKIM was left out of the cutover checklist.

In all three cases, Cathedra is correctly reporting the absence and the fix is to enable DKIM at the provider.

When the warning is a false negative

The cases where DKIM is configured but Cathedra still warns:

• Custom selector names. Some self-hosted senders generate selectors with timestamps or random strings — 20240115._domainkey or dkim-abc123._domainkey. Cathedra cannot guess these.
• Vendor selectors outside the list. ConvertKit uses cknepldlw, ActiveCampaign uses dk or campaign-specific names, some compliance vendors use entirely custom labels.
• Sub-domain DKIM only. If a client signs mail only from mailings.isidoregroup.com, the DKIM lives at {selector}._domainkey.mailings.isidoregroup.com and a scan of the apex isidoregroup.com finds nothing.

When you get the warning, the triage is straightforward:

1. Confirm the client’s primary mail provider from the MX record (Module 2). If they are on M365, Google Workspace, Proofpoint, or Mimecast — the warning is real. Move to remediation.
2. If they use a non-standard provider, ask the client which selector their provider uses. Most provider admin panels show the selector name in the DKIM settings.
3. Manually verify with dig:
   dig {their-selector}._domainkey.isidoregroup.com TXT +short
   If a TXT or CNAME returns, DKIM is working — the warning is a false negative caused by the selector not being in Cathedra’s list.

Document the custom selector in IT Glue under the client’s mail configuration. The next tech to audit this domain needs to know that the warning is expected.

Following the CNAME by hand

When Cathedra reports CNAME → selector1-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com, you can follow the chain manually to see the actual key:

dig selector1-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com TXT +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

This is rarely necessary for an audit — Cathedra’s confirmation that the CNAME exists is sufficient. But if a receiver is rejecting mail with DKIM failures, following the chain is the first step to confirm Microsoft published a valid key at the other end.

What you should remember

• Cathedra probes 14 selectors. Microsoft uses selector1 and selector2. Google Workspace uses google.
• A selector counts as found if there’s a valid TXT or any CNAME at {selector}._domainkey.{domain}.
• “No DKIM records found” is a warning, not an error. It explicitly hedges: “This may not be an error if a non-standard selector is in use.”
• Triage the warning by confirming the client’s mail provider. Most warnings are real on M365 and Workspace tenants; false negatives are common on custom senders.
• Document custom selectors in IT Glue so future audits don’t re-raise the same warning.

Next: enabling DKIM in Microsoft 365 from scratch.

---

Cathedra alignment: DkimRecordCheck.php — the SELECTORS constant and the CNAME-fallback branch