Remediation — Writing SPF in GoDaddy

Remediation — writing SPF in GoDaddy

This is the workflow you will run more than any other on the Service Desk. The previous lessons taught you to read an SPF record. This one teaches you to write one and publish it correctly.

The pattern: identify access model in IT Glue → log into GoDaddy in the right context → edit or add the TXT record → verify with dig and Cathedra. About ten minutes start to finish on a clean engagement.

Step 0 — Pull the access model from IT Glue

Before opening any browser tab, open the client’s record in IT Glue. Two access patterns exist for GoDaddy. The wrong context will either show you nothing or, worse, let you edit a different client’s domain.

Isidore-managed GoDaddy. The domain is registered in the Isidore master GoDaddy account. The client never had their own GoDaddy login. You log into the master account and the domain appears under “All My Domains.”

Delegated GoDaddy. The client has their own GoDaddy account and has delegated access to Isidore. You log into the Isidore GoDaddy account, switch context to the client’s delegated account, and their domains appear there.

The IT Glue access notes tell you which model applies. Read them before you log in. If the notes are missing or stale, ask the on-call before touching anything — you may be looking at a different client’s DNS than you think.

Step 1 — Open DNS Management for the domain

After login, find the domain in the list. Click the kebab menu (the three dots on the right) and choose “Manage DNS.” The DNS Management screen opens with a table of every record at the domain.

GoDaddy My Products view — locate the client domain and click Manage to open its DNS.
My Products view — locate the client domain and click Manage to open DNS Management.

Filter the table to TXT records, or scroll to the TXT section. Look for any record with a value starting with v=spf1. Two things matter:

  • How many SPF records exist. If two, you have the merge case from lesson 3.5. Plan to consolidate.
  • What the current record says. Read the mechanisms and the closing all. This is the baseline you will modify.
DNS Management table showing the existing TXT records, including the SPF record at host @.
DNS Management table — the SPF record sits at host @ in the TXT rows.

Step 2 — Compose the new record

Most engagements fall into one of three patterns. Memorize these canonical strings.

Pattern A — M365 only

For a tenant that sends mail only through M365 with no third-party senders:

v=spf1 include:spf.protection.outlook.com -all

One include, one closing -all. This is the cleanest possible record and the target state for most small clients.

Pattern B — M365 plus a third-party transactional sender

For a tenant that uses M365 for user mailboxes and a service like SendGrid, Mailgun, or Postmark for transactional mail from applications:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Two includes. Still well under the lookup limit. Replace sendgrid.net with the SPF include published by whichever sender the client actually uses. The vendor’s setup guide will list the exact include string.

Pattern C — Google Workspace

For a tenant on Google Workspace:

v=spf1 include:_spf.google.com -all

Same structure, different include target.

When the client genuinely needs more than two or three senders, work through the flattening guidance in lesson 3.4 before adding more includes blindly.

Step 3 — Add or edit the TXT record

In GoDaddy’s DNS Management screen, click “Add” if you are creating a new record, or click the pencil icon on the existing SPF row if you are editing.

DNS Management with the Add New Record button visible. Use this to create or replace the SPF TXT record.
DNS Management — Add New Record opens the create-record dialog where you choose Type=TXT.

The fields:

  • Type: TXT (already filled if you used the edit path)
  • Name (also labeled “Host” in some versions): @
  • Value (also labeled “TXT Value”): paste the SPF string from step 2
  • TTL: 1 hour (3600 seconds) is the GoDaddy default and is correct for steady-state. Lower it only if you are about to migrate.

The @ in the Name field tells GoDaddy “publish this at the bare domain” — the apex. SPF must live at the apex, never on a subdomain.

Click Save.

GoDaddy publishes the change within a few seconds. The TTL on the old record still governs how long resolvers around the world keep caching the previous value. If you lowered the TTL beforehand, expect propagation in minutes. Otherwise plan on up to an hour for global caches to refresh.

Step 4 — Verify with dig

Do not skip this. Cathedra reads what is published in DNS. If you misspelled an include, Cathedra will report the same warning the client called about. Save yourself the second ticket.

From your terminal:

dig isidoregroup.com TXT +short | grep spf

Expected output for Pattern A:

"v=spf1 include:spf.protection.outlook.com -all"

If the output shows the old record, your local resolver is still serving a cached copy. Query a public resolver directly:

dig @1.1.1.1 isidoregroup.com TXT +short | grep spf

If that still shows the old record, wait — the TTL hasn’t expired yet. If the new record shows from one resolver but not another, that’s normal during the TTL window.

If grep spf returns nothing, the record didn’t publish. Go back to the DNS Management screen and check that you saved.

Step 5 — Re-run Cathedra

Open the Examen tab in Cathedra Workbench. Enter the domain. Run Mail Diagnostics.

Expected findings after a successful Pattern A or B remediation:

SPF Enforcement — status: pass
SPF ends with -all (hard fail). Unauthorized senders are rejected.

No “Multiple SPF Records” finding. No “SPF Lookup Limit” finding.

If any SPF finding still appears, read the finding text against the lessons in this module and diagnose. The most common post-edit issues:

  • Pasted the record with smart quotes from a document. GoDaddy displays them as straight quotes but stores curly. The record fails parsing at the receiver. Re-edit; type the value directly into the field rather than pasting from Word or a chat message.
  • Forgot to delete the old record after adding the new one. Cathedra now reports “Multiple SPF Records.” Delete the stale one.
  • The include’s target itself has multiple SPFs. Rare, but visible by running dig {include-target} TXT +short.

Step 6 — Document in IT Glue and the ticket

Update the client’s IT Glue DNS record with the new SPF string. In the ticket, paste the Cathedra finding before and after, plus the exact record you published. Future techs working the same client need to be able to read the change history without re-running the audit.

Close the ticket with the Isidore-format summary:

SPF record updated for isidoregroup.com. Previous record was v=spf1 include:spf.protection.outlook.com ~all (soft-fail). New record is v=spf1 include:spf.protection.outlook.com -all (hard-fail). Cathedra now reports SPF Enforcement as pass. No legitimate senders affected.

Two sentences, no marketing. The next tech who picks up this client knows exactly what happened.

What you should remember

  • Confirm Isidore-managed vs. delegated in IT Glue before logging into GoDaddy.
  • For M365 only: v=spf1 include:spf.protection.outlook.com -all. For M365 + one third party: add the second include. For Google Workspace: _spf.google.com.
  • Apex hostname is @. SPF never lives on a subdomain.
  • Verify with dig before re-running Cathedra. Confirm the change is live in DNS first.
  • Document the before-and-after in the ticket. Update IT Glue.

That closes Module 3. The end-of-module quiz tests both the reading fluency from 3.1–3.5 and this workflow.

Cathedra alignment: SpfRecordCheck.php — the fix workflow that turns warnings and errors into pass

Previous Topic
Back to Lesson
Next Lesson