Remediation — fixing MX in GoDaddy

When Cathedra returns an MX finding that needs action — an outright error (no MX records), a wrong target after a migration, or a missing secondary on a self-hosted setup — the remediation is the same shape every time: confirm the access model, log into the right context, edit the record, verify in Cathedra. This lesson walks the workflow end to end.

The workflow assumes GoDaddy as the registrar and DNS host. Most Isidore-managed domains run there. If the client is on a different DNS host (Cloudflare, Route53, Namecheap), the IT Glue notes will say so, and you’ll follow that host’s equivalent path — the concept is the same; only the UI changes.

Step 1 — Identify the access model in IT Glue

Open the client’s record in IT Glue. Look for the access notes — usually in the “DNS / Domain Management” section, or under the document called “Domain Access Pattern” if the client has one.

You’re looking for one of two patterns:

Isidore-managed. The domain is registered to and managed under the Isidore master GoDaddy account. You log in as Isidore, and the domain appears in “All My Domains” alongside our own. This is the common case for clients who delegate domain management to us as part of their MSP engagement.

Delegated. The domain is registered under the client’s own GoDaddy account, and the client has granted Isidore delegated access. You log in as Isidore, switch context to the client’s account, and their domains appear separately. This is the pattern for clients who keep their registrar in-house but want us to operate it.

If the IT Glue notes are ambiguous — or you can’t find the access pattern at all — stop. Don’t log in and guess. Open a Service Desk ticket against the account team to confirm. Editing a DNS record in the wrong account, on the wrong client’s domain, is the kind of mistake we don’t want to make.

Step 2 — Log into GoDaddy in the correct context

For an Isidore-managed domain:

1. Open GoDaddy in a clean browser session (incognito, or a dedicated browser profile — don’t reuse a personal GoDaddy login).
2. Authenticate with the shared Isidore credentials from 1Password (vault: Isidore — GoDaddy Master).
3. Navigate to “My Products” → “All My Domains.”
4. Locate the client’s domain in the list. The domain count is large; use the search box.

For a delegated domain:

1. Same login as above.
2. After authentication, click the account selector in the top-right.
3. Choose the client’s delegated account from the list. The UI re-renders into that account’s context.
4. The client’s domains now appear in “All My Domains” — and the Isidore-managed ones are no longer visible. That’s expected.

Confirm you’re in the right context before you make any changes. The breadcrumb at the top of the page should match the client name in IT Glue.

Step 3 — Open DNS Management for the target domain

In the domain list, click the client’s domain. The Domain Management screen opens.

From there: click “DNS” in the left sidebar, or “Manage DNS” in the main panel. GoDaddy moves this control around occasionally; both labels lead to the same DNS Management view.

The DNS Management view shows all DNS records for the zone, grouped by record type. MX records are in their own section, usually near the top alongside A and CNAME.

Step 4 — Edit (or add) the MX record

If an existing MX record needs to change:

1. Find the MX row in the list.
2. Click the pencil icon to edit.
3. Update the fields:
   – Host: @ (the apex — never a subdomain for the primary MX)
   – Points to: the new MX target (e.g., acme-com.mail.protection.outlook.com)
   – Priority: the priority number (lower = preferred)
   – TTL: 1 hour (3,600 seconds) for steady state; 5 minutes (300 seconds) if you’re in a pre-migration window
4. Save.

If you’re adding a new MX record where none existed:

1. Click “Add” at the bottom of the MX section.
2. Choose “MX” from the record type dropdown.
3. Fill the same four fields.
4. Save.

If you’re removing an old MX record (post-migration cleanup):

1. Find the obsolete MX row.
2. Click the trash icon.
3. Confirm.

Step 5 — Confirm the change in DNS before re-running Cathedra

Before opening Cathedra to verify, query the authoritative directly:

dig acme.com MX +short

If the new MX target is what comes back, the zone has been updated. If the old target is still showing, either:
– The change hasn’t published yet (GoDaddy sometimes lags by 30–60 seconds after save), or
– Your local recursive resolver still has the old answer cached.

To bypass caching and read straight from GoDaddy’s authoritative servers:

dig @ns11.domaincontrol.com acme.com MX +short

(Substitute the actual NS from dig acme.com NS +short if it’s different.) That gives you the truth from the source.

Step 6 — Verify in Cathedra

Open Cathedra Workbench → Examen tab → Mail Diagnostics. Enter the client’s domain. Run the scan.

Expected results after a clean MX change:

• MX Records check: pass — “{N} MX record(s) found: {new target}.”
• MX Redundancy check: depending on the number of records, may still warn (single MX is expected for cloud-hosted mail; see lesson 2.2).
• Provider Detection: the detected primary provider should reflect the new mail host — Microsoft 365, Google Workspace, etc.

If the MX target points at a brand-new tenant and SPF/DKIM/DMARC haven’t been updated yet, expect those checks to still report findings tied to the old provider. That’s normal mid-migration. Plan the SPF/DKIM/DMARC updates as the next phase.

Step 7 — Document in the engagement notes

Add an entry to the client’s IT Glue notes:
– Date and time of the change
– Old MX target → new MX target
– TTL value at the time of change
– Cathedra status before and after (one-line per check that changed)
– Your initials

This is the audit trail. Next time someone asks “when did the MX flip?” the answer is in IT Glue, not buried in a chat thread.

Common mistakes to avoid

• Editing in the wrong account context. Always confirm the breadcrumb matches the client. If you make a change in the wrong context, revert immediately and document.
• Setting Host to the apex domain name instead of @. GoDaddy accepts both, but @ is the conventional and portable form. Stick to it.
• Forgetting to lower TTL before a planned migration. Recover with patience — wait for the old TTL to expire. There’s no shortcut.
• Leaving the old MX record in place “just in case.” A residual MX with a higher priority will receive mail when the primary is unreachable. If the residual points at a dead host, you’ve created a delivery failure mode. Remove old MX records as part of the cutover.

What you should remember

• The workflow is always: IT Glue → confirm access model → log in → switch to correct context if delegated → edit MX → verify with dig → verify in Cathedra → document in IT Glue.
• Two access models: Isidore-managed (domain in our master GoDaddy account) and delegated (client’s account, accessed via delegation).
• Host = @ for MX at the apex. Points-to = MX target. Priority = lower number preferred. TTL = 3,600 steady-state, 300 pre-migration.
• After saving, dig @{authoritative-ns} {domain} MX +short reads straight from GoDaddy’s authoritative servers, bypassing your local cache.
• Cathedra verification is the closing step. Expect MX and Provider Detection to flip; SPF/DKIM/DMARC findings from the prior provider remain until those records are updated separately.

That closes Module 2. Module 3 starts on SPF — the first sender-authentication layer, and the most common source of misconfiguration findings on the audit report.

---

Cathedra alignment: MxRecordCheck — remediation workflow for MX findings