GoDaddy SPF Record: Step-by-Step Setup and Fixes

Your email won’t drive pipeline if it never reaches the inbox. If your sales reps complain about replies drying up or marketing campaigns underperforming, start with authentication. In GoDaddy, that begins with SPF. Below is the operator’s guide: what SPF does, exactly how to add it in GoDaddy, and how to keep it working as your stack evolves.

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which hosts are allowed to send email for your domain. When SPF fails, more of your messages land in spam or get rejected outright. That’s not a theoretical risk - it shows up as fewer booked demos and slower sales cycles.

If you’re running outbound, lifecycle, and transactional email from different tools, each of those tools must be identified in your SPF policy. Otherwise you’ll get sporadic failures that are hard to diagnose: Tuesday’s campaign hits, Wednesday’s bounces spike, Thursday’s quotes never arrive. That’s not a copy problem - it’s authentication.

SPF is also a reputation shield. By publishing an accurate policy, you reduce spoofing on your domain and make DMARC enforcement (p=quarantine or p=reject) viable. Put simply: SPF is one piece of the trust signal inbox providers use when deciding whether your message belongs in the inbox or the promotions tab - or nowhere at all.

SPF authenticates the path the email took - the sending server’s IP or host - against the domain listed in the envelope sender (the Return-Path). If that server is listed in your SPF policy, SPF passes. If not, it fails. It does not verify the visible From: header; that’s where alignment with DMARC comes in.

DKIM signs the message content with a private key and publishes the matching public key in DNS. When receivers validate the signature, they know the message wasn’t tampered with and that an authorized sender signed it. DKIM is per-sending-service and usually set up separately from SPF.

DMARC sits on top. It checks that either SPF or DKIM passes and that the domain used in that pass aligns with the visible From: domain. Then it applies your policy (none, quarantine, or reject) and optionally sends you forensic/aggregate reports. Practically: SPF alone isn’t enough; you want SPF and DKIM aligned so DMARC can be enforced without breaking mail.

Inventory every system that sends email on your behalf. Common buckets include your core mailbox provider (Google Workspace or Microsoft 365), marketing automation (HubSpot, Mailchimp, Klaviyo), transactional platforms (SendGrid, Mailgun, Amazon SES), product or app servers, and support/ticketing tools (Zendesk, Intercom). If a tool sends from you@yourdomain.com or uses your branded bounce domain, it belongs in the SPF conversation.

Decide which domain or subdomain each system will send from. Best practice: use a dedicated subdomain for bulk and transactional mail (e.g., newsletters@news.yourdomain.com, receipts@notify.yourdomain.com). That keeps reputation segmented, reduces the blast radius of an incident, and simplifies DMARC alignment. You’ll publish SPF for each domain or subdomain that appears in the envelope sender.

Collect the vendor-recommended SPF include or IP ranges. Do not guess. Most reputable platforms provide a canonical include you can reference, so they can update IPs without you editing DNS every month.

In GoDaddy, SPF is published as a TXT record. While “SPF” exists as a record type historically, TXT is the standard and what inbox providers expect. You’ll add one consolidated SPF TXT record per domain or subdomain.

Here’s the flow you’ll follow in GoDaddy’s DNS Manager. Even if the UI labels shift slightly, the fields remain the same: host/name, type, value, and TTL.

- Log in to GoDaddy and open Domains. Select your domain and navigate to DNS (DNS Management). - Click “Add Record,” choose Type = TXT. - Host (Name): use @ for the root domain (yourdomain.com) or the subdomain name (e.g., news for news.yourdomain.com). - TXT Value: start with v=spf1, add your mechanisms (include, ip4, ip6, a, mx), end with a policy (~all for softfail or -all for fail). - TTL: default is fine (typically 1 hour). Save.

For Google Workspace on your root domain, a typical value looks like: v=spf1 include:_spf.google.com ~all. For Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all. If you use both, you do not create two SPF records - you merge them into one: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all.

Example SPF values for common providers

Google Workspace: v=spf1 include:_spf.google.com ~all. This covers Google’s dynamic sending infrastructure. You don’t need to list IPs manually. If you use Google plus another service, keep Google’s include and add the other provider’s include before the policy.

Microsoft 365 (Exchange Online): v=spf1 include:spf.protection.outlook.com ~all. Microsoft historically used spf.protection.outlook.com. Check current docs, but this include remains the standard for most tenants.

Popular ESPs/transactional senders add their own includes: SendGrid (include:sendgrid.net), Mailgun (include:mailgun.org), Amazon SES (include:amazonses.com for verification or their region-specific records, often combined with DKIM). Your merged record might be: v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all.

Choosing -all vs ~all and policy tuning

~all (softfail) allows receivers to treat non-authorized senders with suspicion but not outright rejection. It’s a safer starting point while you validate all services are included. -all (fail) is stricter: non-authorized senders should be rejected. Move to -all only when you’re confident your inventory is complete and DMARC reports are clean.

Why not go straight to -all? Because gaps happen - a forgotten CRM add-on or a support system suddenly sending from your primary domain. A premature -all can break critical flows (password resets, invoices). Use DMARC aggregate reports for a few weeks to confirm you’ve covered everything, then harden.

If you operate subdomains for bulk mail, you can run -all on those subdomains sooner without risking executive mail. Start strict where the blast radius is controlled, then expand as your visibility improves.

SPF has a strict limit of 10 DNS lookups (include, a, mx, exists, ptr, redirect count toward this). Exceed it and you get a PermError, which many receivers treat as a fail. It happens when teams stack includes from multiple vendors without pruning overlaps.

Consolidation means one TXT record per domain with all required mechanisms listed. If you see two or more records starting with v=spf1 for the same host, merge them. Duplicate SPF records guarantee inconsistent results. Keep your policy as short as possible and prefer vendor includes over raw IP ranges unless it’s an in-house server.

Some providers offer “flattened” include chains that compress lookups. Use these cautiously - IPs change. When you flatten, you own the maintenance. Reserve flattening for cases where vendor includes legitimately exceed the limit and you have monitoring in place.

Flattening SPF safely

Flattening replaces include mechanisms with explicit ip4/ip6 directives. The benefit: fewer lookups. The risk: vendor IPs rotate, and your flattened record goes stale, causing surprise failures. If you choose to flatten, set a calendar reminder and a runbook to refresh quarterly or when your ESP announces infra changes.

A compromise approach is “partial flattening”: keep canonical vendor includes where possible and flatten only the biggest or least-change-prone pieces. Always test after changes and watch DMARC aggregate reports for drift.

Remember that flattening is an operational burden. If your team doesn’t have the muscle to maintain it, stick with vendor-maintained includes and reduce optional tools that balloon the lookup count.

DNS propagation at GoDaddy is usually quick (minutes), but allow up to an hour depending on TTL and caching. To confirm, use CLI tools like dig or nslookup, or web tools such as MxToolbox and Gmail’s “Show original” on a sent message from the domain you configured.

Send a message to a Gmail inbox from the domain you just updated. Open the email, click the three dots, choose “Show original.” Look for SPF: PASS and check that the domain listed aligns with the visible From: domain. If it says PASS but not aligned, DMARC may still fail. Fix alignment by ensuring the envelope sender domain (Return-Path) belongs to your domain or a subdomain under DMARC policy.

If you run DMARC with rua reports, review the XML/visualized aggregates after you push SPF changes. You’ll see which IPs, hosts, and services are sending on your behalf and whether SPF and DKIM aligned on each source. That’s your safety net before tightening policies.

Two SPF records at the same host: This is the number one issue. Receivers can’t merge them reliably. Solution: combine all mechanisms into one v=spf1 record and delete the extras. The final record should start with v=spf1 and end with ~all or -all.

Quotation and length issues: TXT values can be split into multiple quoted strings in DNS UIs, but receivers will concatenate them. In GoDaddy, enter the value as provided; avoid accidental extra quotes or trailing spaces. If your record is near 255 characters, GoDaddy handles chunking automatically - you still only create one TXT record.

10-lookup limit reached: Count your lookups. Each include adds at least one lookup and often more. Remove unused vendors, replace a/mx mechanisms with specific ip4/ip6 if appropriate, and consider partial flattening. Tools like Gmail’s “Show original” or online SPF validators will highlight PermError when this happens.

Using the deprecated SPF record type: Some dashboards still allow “SPF” as a type. Stick to TXT. Publishing only an SPF-type record can lead to inconsistent validation across receivers.

Wrong host: If you intended to authenticate mail from news.yourdomain.com but put the SPF record on @ (root), it won’t apply to the subdomain’s envelope sender. Create the TXT record on the exact host that appears in the Return-Path domain.

SPF is the first mile. To keep inbox placement consistent, pair it with DKIM per sender and a DMARC policy backed by reporting. Standardize on subdomains for campaign mail, set up bounce/Return-Path domains correctly, and document who can add a new tool that sends email. This avoids the “we installed a chat tool and email broke” surprise.

If your revenue team runs outbound email at scale, validate that your cold infrastructure (domains, mailboxes, warm-up, tracking) uses distinct subdomains and has dedicated SPF/DKIM/DMARC. Outbound and marketing shouldn’t share the same sending identity; let them earn reputation separately so a mistake in one lane doesn’t tank the other.

For lifecycle and transactional flows, tie authentication to systems, not people. When you connect your CRM or ESP, configure domain authentication in the platform and confirm it maps to your DNS. If you need help wiring domain auth into sales processes or NPS workflows, that typically sits with your marketing automation owner rather than IT-only.

Operator note: Many teams don’t need a big agency to get this right. An AI-first marketing operator builds systems and content, not decks. At Anton Chisliuk · AI Marketing Ops, the operator model means one senior builder ties DNS, CRM, and content together. Proof, not fluff: for Cleverence (B2B SaaS), we scaled from 0 to ~80K organic visits/month and ~2K inbound leads/month. If you want to see how we work and why we avoid the agency tax, read more about Anton Chisliuk · AI Marketing Ops.

Assign clear ownership. Someone has to approve “new tool that sends email” requests, validate DNS changes, and review DMARC reports weekly. Add SPF/DKIM/DMARC checks to your marketing tech onboarding checklist. If no one owns it, it will break - usually during a product launch.

Create a short runbook. It should list your domains/subdomains, the current SPF string for each, DKIM selectors per tool, and DMARC policy/reporting addresses. Add a change log with dates and reasons. When deliverability dips, you’ll be glad you have this timeline.

Instrument for drift. Use DMARC aggregate reporting and occasional seed tests across Gmail, Outlook, and Yahoo. When you change vendors or add IPs, roll updates during low-risk windows and verify immediately in “Show original.” Good governance costs less than one missed quarter of pipeline.

Start with v=spf1. Add your core mailbox provider’s include first (Google or Microsoft). Then add your marketing and transactional providers via their published includes. Only add ip4/ip6 for self-hosted or static infrastructure you control. End with ~all while you test, then consider moving to -all.

Keep a single record per host. If you see two SPF records, copy the mechanisms from the second into the first (between v=spf1 and ~all/-all), separate mechanisms with spaces, and delete the duplicate. Save and retest. A clean, single record eliminates ambiguous behavior across receivers.

Avoid unnecessary mechanisms. a and mx mechanisms add lookups and often aren’t needed when you use vendor includes. ptr is deprecated - don’t use it. redirect is rarely required; prefer includes unless you’re delegating SPF policy to another domain you manage intentionally.

CRMs often relay through your mailbox provider or their own infrastructure. If your CRM sends from your domain but relays via your provider (e.g., Microsoft 365), your existing include usually covers it. If it relays via the CRM’s ESP, you must add that ESP’s include to your SPF.

For platforms that offer “connect your domain” wizards, complete the entire flow: SPF, DKIM, and any custom tracking or bounce domains. Then confirm in tool diagnostics that records are recognized. If you need help with this plumbing plus reporting and dashboards, your CRM and HubSpot implementation owner should close the loop between DNS, CRM, and outreach.

Don’t authenticate personal mailboxes for bulk campaigns. Use dedicated sending identities and domains for scale. This keeps your executive inboxes clean while your outbound engine ramps up volume safely.

If SPF and DKIM feel “done” but deliverability is still uneven, the gap is usually alignment or a forgotten sender. A lightweight audit of your DNS, tools, and sending patterns pays for itself the first time you avoid a silent block during a product push. Harden after you verify, not before.

Adding an SPF record in GoDaddy is straightforward; keeping it correct as your tooling changes is the real job. Inventory senders, publish one consolidated TXT record per domain, monitor DMARC reports, and only then tighten to -all. Pair SPF with DKIM and a sensible subdomain strategy, and you cut risk while protecting revenue email streams.

If you want this handled end-to-end - DNS, DMARC reporting, CRM hooks, and outbound infrastructure - book a free Growth Audit. We’ll map your current stack, find the gaps, and prioritize changes that move pipeline, not just pass checks.

Article by Anton Chisliuk - operator-led marketing systems for growth-stage teams.

- Do I use SPF or TXT in GoDaddy?

Use TXT. While an SPF record type exists historically, major receivers read SPF from TXT records. Publishing only an SPF-type record can cause validation gaps. Create a single TXT record per host that begins with v=spf1.

- Where do I put the SPF record - @ or a subdomain?

Place it on the exact host that appears in the envelope sender (Return-Path). For root-domain sending, host is @. For subdomain sending (e.g., news.yourdomain.com), host is the subdomain label (news). Publish one SPF TXT record per host.

- Can I have more than one SPF record?

No. You can only have one SPF TXT record per host. If you need to add another service, merge its include or IPs into your existing record between v=spf1 and ~all/-all, then delete the extra record.

- Should I use ~all or -all?

Start with ~all (softfail) while you verify that all legitimate senders are included and DMARC reports are clean. Move to -all (fail) once you’re confident you won’t block valid mail. Consider using -all sooner on dedicated subdomains for campaign mail.

- What’s the 10-DNS-lookup limit in SPF?

SPF allows up to 10 DNS-mechanism lookups (include, a, mx, exists, ptr, redirect). Exceeding this returns a PermError, which many receivers treat as a fail. Keep includes lean, avoid unnecessary mechanisms, and consider partial flattening if required.

- How do I test my SPF record?

Use dig or nslookup to query TXT records, online SPF validators, and send a test to Gmail then use “Show original” to confirm SPF: PASS and alignment. Also review DMARC aggregate reports to see pass/fail rates by source and alignments.

- Does SPF fix spoofing on the visible From address?

SPF authenticates the envelope sender (Return-Path), not the visible From by itself. DMARC checks that SPF or DKIM aligns with the visible From domain. To stop spoofing of your brand, implement SPF and DKIM, then enforce DMARC.

- My vendor says ‘add ip4:’ ranges instead of include. Which is better?

Prefer the vendor’s canonical include when available. It lets the vendor update infrastructure without your intervention. Use explicit ip4/ip6 primarily for infrastructure you control or when you must reduce lookups and accept the maintenance burden.