How to Add a TXT Record in GoDaddy

What Is a TXT Record and Why GoDaddy Needs One

A TXT (text) record is a DNS record type that stores arbitrary text data at a hostname, defined in RFC 1035 §3.3.14. Each character-string inside a TXT record is capped at 255 bytes, but a single record can hold multiple concatenated strings — which is why long SPF or DKIM values sometimes appear as several quoted segments back to back. GoDaddy stores whatever value you enter and serves it back over standard DNS queries; it doesn't interpret or validate what the string means.

GoDaddy uses TXT records for the same purposes any registrar-run DNS service does: proving domain ownership (Google Search Console, Microsoft 365, Zoho), publishing email authentication policy (SPF, DKIM, DMARC), and satisfying ACME challenges for SSL certificates that require DNS-based validation. Because TXT is a general-purpose container, one domain can carry dozens of TXT records at different hosts — @, _dmarc, google._domainkey, and so on — without conflict, as long as none of them duplicate the same host with a colliding prefix, which is exactly what causes the classic "two SPF records" failure covered below.

GoDaddy's DNS Management screen doesn't separate "verification TXT" from "SPF TXT" — every TXT record shows in the same table, distinguished only by its Host and Value. That matters because it's easy to add a second v=spf1 record instead of editing the existing one when a new mail provider needs to be added. If you're building an SPF value from scratch, use the SPF Record Generator guide to get the syntax right before pasting it into GoDaddy.

Step-by-Step: Adding a TXT Record in GoDaddy

1. Sign in to your GoDaddy account and go to My Products. Find the domain in your product list and click the DNS button next to it (or Manage DNS from the domain's settings menu).

2. Open the DNS Management page. This is the same screen where A, CNAME, and MX records live. Scroll to the records table and click Add New Record (older account UIs show a plain Add button).

3. Set Type to TXT. GoDaddy's Add Record form changes its fields based on the type you pick — for TXT, you'll see Host, TXT Value, and TTL.

4. Enter the Host exactly as given. This is the single biggest source of failed verifications. For a root-domain record, GoDaddy uses @. For a subdomain-style host like _dmarc.example.com, enter just _dmarc — GoDaddy appends your zone's root domain automatically. Adding the full domain again (_dmarc.example.com.example.com) is the most common copy-paste mistake.

5. Paste the TXT Value exactly, including quotes if given. Copy-paste rather than retype — TXT values are case-sensitive, and a single dropped character invalidates SPF, DKIM, and most verification tokens.

6. Leave TTL on the default (1 Hour) unless you're actively troubleshooting, in which case drop it to the shortest option (typically 600 seconds / 10 minutes) temporarily, save, confirm the change took effect, then raise it back once verification succeeds.

7. Click Save, or Save All Records if you queued more than one change. GoDaddy applies edits to its authoritative nameservers immediately after saving — there's no separate "publish" step.

8. Confirm propagation before re-checking with the third party — see the CLI and tool checks below. GoDaddy's own help documentation states DNS changes usually take effect within an hour, but full global propagation can take up to 48 hours as caching resolvers downstream expire their old answers.

Host Field Reference Table

The Host field is the most common point of failure for GoDaddy TXT records — a mismatched selector or a duplicated domain suffix produces a record that saves successfully but never matches what the verifying service queries for.

Verifying the Record with dig and nslookup

Run these from a terminal after saving, substituting your actual domain for example.com:

# Query the TXT record directly to see the live authoritative answer
dig TXT _dmarc.example.com +short

# Query a specific resolver (e.g., Google Public DNS) to bypass local caching
dig TXT example.com @8.8.8.8 +short

# Windows/macOS equivalent
nslookup -type=TXT _dmarc.example.com

If a direct query to an external resolver like 8.8.8.8 returns the record but your own machine doesn't see it yet, the record itself is correct and you're waiting on local resolver cache TTL — not a GoDaddy misconfiguration. Cross-check global visibility with the DNS Propagation Checker, or confirm the exact record set with the DNS Lookup tool.

Common Issues & Troubleshooting

Problem: The verifying service says the TXT record isn't found, but GoDaddy shows it saved. Cause: usually a Host field mismatch — a trailing domain suffix, wrong DKIM selector, or the record was added to the wrong domain if your account manages several. Fix: re-open the record in GoDaddy's DNS Management page and compare the Host character-for-character against what the third party specified, then re-verify with dig.

Problem: SPF stopped working after adding a new TXT record. Cause: two v=spf1 records now exist at the same host. RFC 7208 §4.5 requires exactly one SPF record per domain — two or more produces a PermError, which most mail receivers treat as an outright SPF fail. Fix: merge both include: mechanisms into a single v=spf1 string instead of keeping a second record. See the SPF Record Generator guide for building one merged value.

Problem: Long DKIM key gets rejected or looks truncated in GoDaddy's editor. Cause: DKIM public keys frequently exceed the 255-byte limit for a single TXT string, and some providers hand you the value already pre-split into quoted segments, which GoDaddy expects verbatim. Fix: paste the full string exactly as your provider gave it, including any existing quote splits. Don't manually re-wrap or shorten it. See the DKIM Selector guide for selector-naming specifics.

Problem: Record shows correctly in GoDaddy but a global checker still reports NXDOMAIN. Cause: the domain's nameservers at the registrar level don't actually point to GoDaddy's DNS — this happens when a domain was registered at GoDaddy but DNS was migrated elsewhere (or vice versa). Fix: confirm delegation with the NS Lookup tool before troubleshooting the TXT record itself — a correct record in the wrong authoritative zone will never resolve publicly.

Problem: GoDaddy's domain forwarding or parking page interferes with verification. Cause: some verification flows (particularly for subdomains) expect an A or CNAME to exist alongside the TXT record, and a GoDaddy "Domain Forwarding" setup can mask the underlying DNS state. Fix: check DNS Management for conflicting forwarding rules, and confirm the actual published records with the DNS Lookup tool rather than relying on the forwarding preview.

Key Takeaways

• ✓ GoDaddy's Host field for a root-domain TXT record is @ — don't append the domain name again for subdomain-style hosts.
• ✓ Per RFC 1035, each string in a TXT record is capped at 255 bytes; long values (DKIM keys) get split into quoted segments that must be pasted verbatim.
• ✓ A domain must have exactly one v=spf1 TXT record (RFC 7208 §4.5) — a second one causes PermError, not stacking.
• ✓ GoDaddy's default TTL is 1 Hour; changes usually apply within an hour but can take up to 48 hours to fully propagate globally.
• ✓ Verify the Host field character-for-character — it's the single most common cause of "saved but not found" verification failures.

Frequently Asked Questions

Next Steps

Once the record is saved, confirm it resolves correctly with the DNS Lookup tool and check global propagation with the DNS Propagation Checker. If verification still fails after the record looks correct, confirm your domain's nameservers actually point to GoDaddy using the NS Lookup tool, or check for a stale reverse mapping with Reverse DNS Lookup. For deeper background on TXT record syntax and other record types, see DNS TXT Records Explained, and if you're migrating this domain's DNS entirely, read How to Change DNS Servers first. Managing DNS at a different registrar instead? See How to Add a TXT Record in Namecheap for the equivalent steps.