How to add an SPF record in GoDaddy (step-by-step)

GoDaddy is one of the largest domain registrars in the world. Millions of small businesses host their DNS there. Most of them have no SPF record, or worse, they have one that’s broken.

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are allowed to send email for your domain. Without it, anyone can send email pretending to be you. Gmail, Microsoft, and Yahoo all check SPF when deciding whether to deliver or spam your messages.

Adding an SPF record in GoDaddy takes about 10 minutes. The interface can be confusing, and GoDaddy has some quirks around TXT record formatting that trip people up.

This guide walks through the exact steps, from building your SPF record to verifying it works.

Before you start

You’ll need access to your GoDaddy account with permission to edit DNS records. You’ll also need to know which email services send mail as your domain.

Think about it: do you use Google Workspace? Microsoft 365? A marketing platform like Mailchimp or HubSpot? A transactional email service like SendGrid? Each service needs to be included in your SPF record.

If you’re not sure what services send email as your domain, that’s exactly what DMARC monitoring solves. We’ll cover that at the end.

Step 1: build your SPF record

Before touching GoDaddy, you need to know what to put in the record.

Go to our SPF record generator. Select the email services you use, and the tool builds a valid SPF record for you. It also counts DNS lookups in real-time, which matters because SPF has a hard limit of 10 lookups before it breaks.

For a basic setup with Google Workspace, the generator outputs something like:

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

If you use Microsoft 365 instead:

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

If you use both (which is unusual, but happens during migrations):

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

Copy your generated record. You’ll paste it into GoDaddy in Step 4.

Step 2: log into GoDaddy

Go to godaddy.com and sign in.

Once logged in, navigate to your domain’s DNS settings. GoDaddy redesigns their interface occasionally, but the current path is: click your profile icon in the top right, select My Products, find your domain under Domains, and click DNS next to the domain name.

Alternatively, go to Domain Portfolio from the main menu, click on your domain name, then select DNS from the domain settings.

Both paths land you at the same DNS management screen.

Step 3: check for existing SPF records

This step is important. You can only have one SPF record per domain. If you already have an SPF record and add another, both become invalid. Receiving servers see the conflict and return an error.

In your DNS records list, look for any TXT record that starts with v=spf1. It might look like this:

Type: TXT
Name: @
Value: v=spf1 include:some-service.com -all

If you find one, you have two options.

You can edit the existing record, adding your new services instead of creating a second one. For example, if you have v=spf1 include:_spf.google.com -all and need to add SendGrid, edit it to v=spf1 include:_spf.google.com include:sendgrid.net -all.

Or you can delete and recreate. Remove the existing record and create a new one with all your services. This is cleaner but means a brief window where you have no SPF record.

If you don’t have an existing SPF record, proceed to Step 4.

Step 4: add the SPF TXT record

Click Add (or Add New Record), then fill in these fields:

Field	Value
Type	TXT
Name / Host	@
Value / TXT Value	Your SPF record (from Step 1)
TTL	Leave as default (usually 1 hour or 3600)

The Name field should be @ (the at symbol). In GoDaddy’s DNS, @ means the root of your domain. Your SPF record will apply to yourdomain.com.

For the Value field, paste your entire SPF record exactly as generated. Do not add quotes around it. GoDaddy handles quoting internally.

Example of what you’re entering:

Type:  TXT
Name:  @
Value: v=spf1 include:_spf.google.com include:sendgrid.net -all

Step 5: save the record

Click Save or Add Record.

GoDaddy confirms the record was added. You should see it in your DNS records list as a TXT record with the name @ and your SPF value.

Step 6: verify it works

DNS changes take time to propagate. GoDaddy is generally fast, around 15-30 minutes for most changes, but it can take up to 48 hours in rare cases.

To verify your SPF record is live, go to DMARCTrust’s domain checker, enter your domain name, and look at the SPF section.

You should see your record displayed. The checker also shows you how many DNS lookups your record requires. If you’re at 10 or above, you have a problem that needs fixing.

GoDaddy-specific pitfalls

GoDaddy’s DNS interface has a few quirks that trip people up.

TXT record length limits. GoDaddy splits long TXT records into 255-character chunks. This is normal per the DNS spec, but the interface doesn’t show it clearly. If your SPF record is longer than 255 characters (common when you have many includes), you might see multiple lines or weird formatting. The record usually still works. Just be careful when editing that you don’t accidentally break it.

The @ symbol confusion. In GoDaddy, @ means your root domain. Don’t enter your full domain name in the Name field. If your domain is example.com, entering example.com creates a record for example.com.example.com. That’s wrong, and it’s a mistake we see constantly.

Propagation delays. GoDaddy claims changes take effect immediately. They don’t always. If you check your record right after saving and it’s not there, give it 30 minutes. You can verify propagation using our domain checker or command-line tools like dig or nslookup.

Editing corrupts the record. This one’s frustrating. Some users report that editing an existing TXT record in GoDaddy corrupts it, especially records with special characters or long values. If your SPF suddenly stops working after an edit, delete the record and recreate it from scratch.

Common SPF mistakes

Beyond GoDaddy-specific issues, here’s what we see go wrong most often.

Multiple SPF records. You can only have one SPF record per domain. Two v=spf1 TXT records invalidates both. Check your DNS for duplicates before adding anything new. For more on this, see our SPF documentation.

Exceeding 10 DNS lookups. Every include: in your SPF record triggers DNS lookups. Go over 10 and SPF fails for all your email with a PermError. Our SPF generator shows lookup counts as you build your record.

Forgetting services. Your company probably sends email from more places than you realize. Marketing tools, CRM systems, helpdesk software, billing platforms, your IT ticketing system. Each one that sends as your domain needs to be in your SPF record. Miss one, and those emails fail.

Using ~all instead of -all. The ending matters more than people think. -all (hard fail) tells receivers to reject unauthorized senders. ~all (soft fail) is weaker. Use -all unless you have a specific reason not to.

What about DMARC?

SPF alone isn’t enough. SPF tells receivers which servers are allowed to send your email, but it doesn’t tell them what to do when authentication fails. That’s what DMARC does.

DMARC adds a policy layer on top of SPF and DKIM. It tells receivers whether to deliver, quarantine, or reject messages that fail authentication. It also sends you reports about who’s sending email as your domain.

If you’re setting up SPF, you should set up DMARC at the same time. We have a complete guide to adding DMARC in GoDaddy that walks through the process.

The short version: create a TXT record with Name _dmarc and a value like:

v=DMARC1; p=none; rua=mailto:[email protected];

You get your unique reporting address when you sign up for DMARCTrust.

Alignment: why SPF isn’t always enough

Here’s something that trips people up. SPF can pass, but DMARC can still fail.

SPF checks the envelope sender (the Return-Path). DMARC checks whether that domain aligns with the From header. If they’re different (common with third-party senders), SPF passes but doesn’t help your DMARC result.

This is called SPF alignment. It’s why you need both SPF and DKIM properly configured. And it’s why monitoring matters.

Why monitoring matters

Adding an SPF record is step one. Knowing whether it actually works is step two.

Without monitoring, you’re flying blind. Which services are passing authentication? Which are failing? Did someone in marketing sign up for a new email tool that’s not in your SPF? When can you safely move from p=none to p=reject? You have no idea.

DMARC sends you reports about all of this, but the reports are XML files that look like this:

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>847</count>
    <policy_evaluated>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

You’re not going to read these manually. Nobody does.

DMARCTrust parses these reports automatically. You see which services pass SPF, which fail, and which aren’t in your record at all. When something breaks, you get an alert.

The path to enforcement

Once SPF and DMARC are configured and you’re monitoring, here’s what happens next.

First couple of weeks: Review your DMARC reports in DMARCTrust. Identify every service that sends email as your domain. Make sure they’re all in your SPF record. You’ll probably find a few surprises.

Next few weeks: Fix alignment issues. Some services need DKIM configured with your domain to pass DMARC. Our enforcement playbook walks through this systematically.

Around month two: Move your DMARC policy from p=none to p=quarantine with a low percentage (start with 10%). This tests enforcement on a subset of traffic without risking all your email.

Month three and beyond: Gradually increase enforcement until you reach p=reject. That’s the goal. Attackers can’t spoof your domain anymore, and you’ve got the monitoring to prove your legitimate email still flows.

Check your domain now

Enter your domain in our free checker. You’ll see whether your SPF record is configured correctly, how many DNS lookups it uses, and whether you have DMARC set up.

GoDaddy gives you the DNS. DMARCTrust gives you the visibility. SPF without monitoring is like a lock without knowing who has the keys.

Additional resources

For more details on GoDaddy’s DNS management, see their official documentation:

• Manage DNS records - GoDaddy’s guide to adding and editing DNS records
• Add a TXT record - Specific instructions for TXT records