Remediation — adding DKIM CNAMEs in GoDaddy

This is the workflow that closes the DKIM module. The previous lessons taught the theory, the syntax of the signature header, the selectors Cathedra probes, and how rotation works. This lesson is the operational reality: how you actually publish DKIM records for a Microsoft 365 tenant in GoDaddy.

The same pattern with minor variations works for Google Workspace (lesson 4.5 covers that workflow). The M365 path is documented here because it is the most common and because the CNAME mechanics trip up techs new to the workflow.

Pre-flight — confirm the access model

Open the client’s record in IT Glue. Check the GoDaddy access notes:

• Isidore-managed. Domain registered under the Isidore master GoDaddy account.
• Delegated. Client has their own GoDaddy account; Isidore has delegated access.

This determines which login path to use and which client context to switch to. If the notes are missing or stale, ask the on-call before logging in. Editing DNS in the wrong GoDaddy context is one of the most common ways to cause an outage.

Step 1 — Pull the CNAME targets from Defender

Sign into the M365 tenant for the client. Navigate:

security.microsoft.com → Policies & rules → Threat policies → Email authentication settings → DKIM

Click the client’s domain. The side panel shows two CNAMEs Microsoft wants you to publish. Copy both pairs of (Host, Points to) values.

The expected pattern:

Host	Points to
selector1._domainkey	selector1-{tenant}._domainkey.{tenant}.onmicrosoft.com
selector2._domainkey	selector2-{tenant}._domainkey.{tenant}.onmicrosoft.com

{tenant} is the client’s M365 tenant name — the part before .onmicrosoft.com. For Isidore’s own tenant, the values would be:

Host	Points to
selector1._domainkey	selector1-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com
selector2._domainkey	selector2-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com

Note the transformation: the dot in the customer’s domain becomes a hyphen when Microsoft constructs the subdomain (isidoregroup.com → isidoregroup-com). Always copy the value Defender shows; do not construct it by hand.

Keep the Defender panel open in a tab. You will come back to it once DNS is live.

Step 2 — Open DNS Management in GoDaddy

Log into GoDaddy in the correct context. From the domain list, click the kebab menu on the row for the client’s domain and choose “Manage DNS.”

Scroll to the CNAME records section, or click “Add New Record” if the section is empty.

Before adding anything, scan the existing records:

• Look for any existing selector1._domainkey or selector2._domainkey entries. If they exist and point to a different tenant, they are stale from a previous attempt. Delete them before publishing fresh records — leaving them in place causes Defender validation in step 5 to fail.
• Check for an existing _domainkey record at the apex (unusual). If present, ask the on-call before touching anything.

Step 3 — Add the first CNAME

Click “Add” → choose CNAME from the type dropdown.

Fill the fields:

• Type: CNAME
• Name (also labeled “Host”): selector1._domainkey
• Value (also labeled “Points to”): paste the exact target from Defender. For Isidore: selector1-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com
• TTL: 1 hour (3600 seconds). Default is correct.

A common mistake: typing the Host as selector1._domainkey.isidoregroup.com. GoDaddy appends the domain automatically. If you include the suffix, GoDaddy publishes the record at selector1._domainkey.isidoregroup.com.isidoregroup.com and the lookup fails. Always enter just the host portion.

Click Save.

Step 4 — Add the second CNAME

Same dialog, same flow, with the selector2 values:

• Name: selector2._domainkey
• Value: the second target from Defender. For Isidore: selector2-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com
• TTL: 1 hour

Save.

Step 5 — Verify both CNAMEs resolve

Open a terminal. Wait a minute or two for GoDaddy to publish, then:

dig selector1._domainkey.isidoregroup.com CNAME +short
selector1-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com.

dig selector2._domainkey.isidoregroup.com CNAME +short
selector2-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com.

Both queries should return the exact targets you entered. The trailing dot is expected — it marks the value as fully-qualified.

If either query returns nothing, the record didn’t publish. Go back to DNS Management and confirm the Host field was entered without the domain suffix. Re-save if needed.

If you want to verify the chain end-to-end, query the underlying TXT record:

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

This follows the CNAME to Microsoft’s side and returns the actual public key. If you see the full key string, the chain is working.

Step 6 — Enable the DKIM toggle in Defender

Return to the Defender DKIM panel for the domain. The previously-greyed-out toggle is now active because Microsoft has confirmed both CNAMEs resolve.

Set:

Sign messages for this domain with DKIM signatures: Enabled

Microsoft validates the CNAMEs at this moment. If validation fails, the toggle bounces back to disabled with an error message — usually one of the CNAMEs has a typo or points to the wrong tenant. Read the error, fix in GoDaddy, retry.

If validation passes, the status updates to Enabled. M365 begins DKIM-signing outbound mail with the client’s domain within a few minutes.

Step 7 — Confirm in Cathedra

Open Cathedra Workbench → Examen → Mail Diagnostics. Enter the domain. Run.

Expected DKIM finding:

DKIM Records — status: pass
2 DKIM selector(s) found: selector1, selector2

The raw_value array shows both selectors as CNAME → selector1-{tenant}._domainkey.{tenant}.onmicrosoft.com style entries — Cathedra is following the CNAME indirection and confirming Microsoft published valid keys at the other end.

If the finding still reads “No DKIM records found for common selectors…” after enabling Defender:

1. Confirm both CNAMEs resolve with dig. Most often the issue is at step 5.
2. Confirm Defender shows the toggle as enabled. If it bounced back, the validation failed.
3. Wait five minutes for any DNS caches to settle. Re-run Cathedra.

Step 8 — Document in IT Glue and close the ticket

Update the client’s IT Glue record:

• Note the DKIM enabled date.
• Record the two CNAME values (Host and Points to) so a future tech can compare against current DNS without re-running this workflow.
• Note that M365 handles rotation automatically — no recurring tasks needed unless the tenant ever moves off M365.

Close the ticket in the Isidore voice:

DKIM enabled for isidoregroup.com on Microsoft 365. CNAMEs published at selector1._domainkey and selector2._domainkey, pointing to the tenant’s onmicrosoft.com namespace. Cathedra DKIM check now reports 2 selectors found, status pass. Microsoft handles key rotation automatically; no further action required.

Quick reference

Item	Value
Host 1 (in GoDaddy)	selector1._domainkey
Points to 1	selector1-{tenant}._domainkey.{tenant}.onmicrosoft.com
Host 2 (in GoDaddy)	selector2._domainkey
Points to 2	selector2-{tenant}._domainkey.{tenant}.onmicrosoft.com
TTL	1 hour
Verify command 1	dig selector1._domainkey.{domain} CNAME +short
Verify command 2	dig selector2._domainkey.{domain} CNAME +short
Expected Cathedra finding	2 DKIM selector(s) found: selector1, selector2

What you should remember

• Confirm Isidore-managed vs. delegated in IT Glue first.
• Copy the CNAME targets straight from Defender. Do not construct the tenant part by hand.
• Host in GoDaddy is selector1._domainkey (no domain suffix). GoDaddy appends the suffix automatically.
• Verify both CNAMEs with dig before flipping the Defender toggle.
• After enabling, Cathedra should report two selectors found. If it still warns, dig the records and re-validate Defender.
• Document the change in IT Glue and the ticket.

That closes Module 4. The end-of-module quiz tests both the theory and this workflow.

---

Cathedra alignment: DkimRecordCheck.php — converts the “no DKIM records found” warning to pass