GoDaddy's DNS editor is simple, which is its problem: there is nothing in the interface that tells you whether the zone you are editing is the zone the internet is querying, and the Name field silently accepts fully-qualified names it will then treat as relative. Both are avoidable with a thirty-second check before you start.
Where is DNS management in GoDaddy?
Sign in and open My Products. Find the domain in the Domains list and use its DNS action (older accounts show Manage DNS). You land on the DNS Records table for that zone, with an Add New Record control above or below it. Choose TXT as the type and you get Name, Value, and TTL.
*.domaincontrol.com nameservers. If it is Cloudflare, your host, or anyone else, add the record there instead.This is the single most common reason a GoDaddy TXT record "never propagates". It propagated fine; it is just in an unused zone. The same trap catches people who bought the domain at GoDaddy and later moved DNS to a hosting provider or to Cloudflare.
What goes in the Name field?
GoDaddy's Name field is relative to the zone. It appends your domain to whatever you type, so you supply the label only.
| You need the record at | Name field | Common source |
|---|---|---|
example.com | @ | SPF, Microsoft 365 MS= verification, Google google-site-verification |
_dmarc.example.com | _dmarc | DMARC policy record |
selector2._domainkey.example.com | selector2._domainkey | DKIM public key |
_acme-challenge.example.com | _acme-challenge | Certificate DNS-01 challenge |
_github-challenge.example.com | _github-challenge | Third-party domain verification |
Two conventions matter here. Do not type the domain name. Entering _dmarc.example.com produces a record at _dmarc.example.com.example.com, which resolves to nothing and reports as "DMARC record not found". Do not type a trailing dot. A trailing dot means "this name is already absolute" in zone-file syntax; GoDaddy's Name field is not zone-file syntax, and a stray dot either errors or ends up in the stored label.
The trailing dot does have a legitimate home elsewhere in GoDaddy: in the Value of a CNAME or MX record, hostnames are absolute targets, and GoDaddy generally appends the dot itself when it stores them. For a TXT record the Value is arbitrary text, so dots in it are just characters — never add one to "terminate" the value.
Does the Value need quotation marks?
No. Paste the raw string. Quotes are how DNS tooling *displays* a TXT record — a TXT record is a list of character-strings, and dig wraps each one in quotes on output. The dashboard adds them when it writes the zone. Typing them yourself puts literal " characters inside the record, and then SPF, DKIM, and DMARC parsers all reject it.
# Name: @ Value:
v=spf1 include:secureserver.net include:_spf.google.com -all
# Name: _dmarc Value:
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
# Name: @ Value: (Microsoft 365 domain verification)
MS=ms12345678
# Wrong on all counts — quoted, fully qualified, trailing dot
Name: _dmarc.example.com. Value: "v=DMARC1; p=none"A note on that first example: include:secureserver.net is the mechanism used when GoDaddy's own email or Microsoft 365 through GoDaddy sends your mail. If you no longer send through GoDaddy, drop it rather than carrying it forever — every include: costs one of SPF's ten DNS lookups, and blowing that budget is a permanent error. The SPF Checker counts the lookups live, and SPF PermError: Too Many DNS Lookups explains the fix.
What TTL should you choose?
GoDaddy offers preset intervals plus a Custom option, and enforces a minimum on custom values — you cannot set a 60-second TTL. Pick the shortest preset the dropdown allows while you are actively verifying or changing a record, and raise it once things are stable. A long TTL on a record you are about to edit is what turns a two-minute change into an hour of waiting.
Lowering the TTL is only useful *before* the change. Resolvers that already cached the record honour the TTL they were given at fetch time, so a record cached with a one-hour TTL stays cached for an hour no matter what you set afterwards. The planning sequence is in Lower Your TTL Before a DNS Migration.
How do you verify the record?
Query DNS rather than trusting the table. Check the authoritative servers first — that tells you whether GoDaddy has published the change — then check a public resolver to see what the rest of the world currently has cached.
# Confirm GoDaddy is authoritative
dig +short NS example.com
# expect e.g. ns01.domaincontrol.com. / ns02.domaincontrol.com.
# Ask GoDaddy's nameserver directly — bypasses all caches
dig @ns01.domaincontrol.com +short TXT _dmarc.example.com
# What public resolvers return right now
dig +short TXT example.com
nslookup -type=TXT _dmarc.example.com 8.8.8.8Replace ns01.domaincontrol.com with whichever nameserver the first command printed for your domain. Quoted output means the record exists; empty output means it does not exist at the name you asked for — which usually means the Name field was wrong, not that GoDaddy failed.
Existence is not correctness. A published SPF or DMARC record with a typo verifies as "present" and still fails authentication at the receiver. Run it through the DMARC Checker or the DKIM Checker, or check the whole email posture at once with the Email Deliverability Test.
GoDaddy gotchas worth knowing
- Editing the wrong zone. GoDaddy's DNS editor works even when the delegation points elsewhere. Always confirm the nameservers first.
- A doubled name.
_dmarc.example.comin the Name field becomes_dmarc.example.com.example.com. Read the saved row before you leave the page. - Two SPF records. GoDaddy will let you save a second TXT starting
v=spf1at@. Receivers treat that as a permanent error and SPF fails outright — merge the mechanisms into one record with the SPF Record Generator. - Website Builder or Microsoft 365 auto-records. Turning on a GoDaddy product can write MX, CNAME, and TXT entries into the zone. If your carefully built SPF record suddenly regrew an
include:secureserver.net, that is why. - Domain forwarding. GoDaddy forwarding installs its own A/CNAME records at
@. It does not conflict with TXT records, but it does explain unrelated weirdness on the apex. - Copy-paste whitespace. Verification tokens copied out of a provider console often carry a trailing space or newline. If a token keeps failing while
digshows it present, compare the strings character by character.
Doing this on a different provider? See Add a TXT Record on Cloudflare and Add a TXT Record on Namecheap. For what TXT records are and their length rules, read the TXT record reference; to watch a change roll out across resolvers worldwide, use the DNS Propagation Checker.