An SPF record at GoDaddy is a TXT record like any other: sign in, open DNS management, choose TXT as the record type, and use @ in the Name field since SPF publishes at the root domain, per GoDaddy's own TXT record instructions. The mechanics are identical to publishing a DKIM record there.
What actually breaks SPF is not the syntax. It is that only one SPF record may exist per domain, and every additional email service, an ESP, a helpdesk tool, a CRM, needs to be merged into that single record rather than published as a new one.
Adding a new sending service and pasting its documentation's suggested SPF snippet as a brand new TXT record is the single most common way SPF breaks after it was working. A receiving server that finds two SPF records for the same domain typically treats the record as invalid, which silently weakens or breaks authentication for every sender the domain has, not just the new one.
v=spf1 before checking anything about content or syntax. More than one is the actual defect, regardless of what either record says individually.
The fix is always to edit the one existing record, adding the new service's include: mechanism inside the same string, rather than creating a second TXT record. The DNS & auth checker confirms only one SPF record resolves for the domain, alongside DKIM and DMARC in the same pass.
As a TXT record at the root domain, using @ in the Name field per GoDaddy's own TXT record instructions, since SPF is published on the domain apex rather than a subdomain.
No. Only one SPF record may exist per domain; adding a second one instead of merging both services' includes into the existing record is one of the most common ways SPF breaks after adding a new sender.
Edit the single existing TXT record to add the new service's include mechanism inside the same v=spf1 string, rather than creating a second TXT record with a separate v=spf1 line.