Adding a TXT record in GoDaddy takes about thirty seconds. Adding one that resolves takes longer, because GoDaddy's Name field is relative to your zone and silently appends your domain to whatever you type. Paste_dmarc.example.com into it and you create a record at_dmarc.example.com.example.com — which looks perfectly correct in the dashboard and is invisible to every checker on the internet.
Before You Touch Anything: Is GoDaddy Even Your DNS Host?
Registering a domain at GoDaddy and using GoDaddy for DNS are two different things. If you ever pointed the domain at Cloudflare, a web host, or a managed DNS provider, the DNS screen inside GoDaddy still exists and still lets you add records — it is simply not the zone the world is reading. Records added there have no effect at all.
Check the delegation before you spend an afternoon on a record that was never going to work:
# What nameservers is the domain actually delegated to?
$ dig +short NS example.com
# GoDaddy-hosted DNS looks like this
ns37.domaincontrol.com.
ns38.domaincontrol.com.
# Anything else means you are editing the wrong zone
carl.ns.cloudflare.com.
dana.ns.cloudflare.com.Check your nameservers with the NS Lookup tool
If the answer is domaincontrol.com, GoDaddy is serving your DNS and the rest of this guide applies. If it is anything else, add your record in that provider instead.
Adding the Record
GoDaddy renames these screens every year or two, but the path is consistently: sign in, open your product or domain list, pick the domain, and open its DNS records.
- Sign in at godaddy.com and open My Products (recent accounts see Domain Portfolio).
- Select the domain, then open DNS or Manage DNS.
- Under DNS Records, choose Add New Record.
- Set Type to
TXT. - Fill in Name, Value, and TTL using the rules below, then save.
The Name Field: What to Actually Type
This is where nearly every failed GoDaddy TXT record goes wrong. The Name field holds only the label in front of your domain. GoDaddy supplies the rest.
| Record | Type this in Name | Hostname you get |
|---|---|---|
| SPF | @ | example.com |
| DMARC | _dmarc | _dmarc.example.com |
DKIM (selector s1) | s1._domainkey | s1._domainkey.example.com |
| MTA-STS | _mta-sts | _mta-sts.example.com |
| Domain verification | @ | example.com |
| Subdomain DMARC | _dmarc.mail | _dmarc.mail.example.com |
_dmarc.example.com becomes _dmarc.example.com.example.com. GoDaddy will not warn you, the record saves successfully, and the DNS screen displays it exactly as you typed it. Every DMARC checker will report that no record exists, because at the hostname receivers query there genuinely is none.
Note the last row: subdomains work the same way. To publish DMARC formail.example.com, the label is _dmarc.mail — the underscore prefix comes first, then the subdomain, and GoDaddy appends the rest.
Values That Need Special Handling
Do not add your own quotation marks
DNS requires TXT values to be quoted on the wire, and GoDaddy applies that quoting when it serves the record. If you paste a value with quotes already around it, they are stored as literal characters:
# What you typed into the Value field
"v=spf1 include:secureserver.net -all"
# What resolvers receive
"\"v=spf1 include:secureserver.net -all\""
# The record no longer begins with v=spf1, so it is not an SPF record at allLong DKIM keys
A single DNS string caps at 255 characters. A 2048-bit DKIM public key runs to roughly 400, so it has to be split into multiple strings inside one record. GoDaddy generally accepts the full key and handles the split for you. If the form rejects the value or truncates it, split it yourself into quoted chunks under 255 characters each — concatenation happens at the resolver, so the key reassembles correctly:
# One record, two strings — resolvers join them back together
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1first_chunk_up_to_255_chars"
"remainder_of_the_base64_key_here...IDAQAB"Verify the result with the DKIM Lookup rather than by eye — a key that lost a character during a copy-paste looks completely normal and fails every signature check.
Only one SPF record per hostname
If GoDaddy hosts your email through Microsoft 365 or the older Workspace product, an SPF record was likely published for you when mail was set up, typicallyv=spf1 include:secureserver.net -all. Adding a second one for a newsletter tool or CRM does not merge them — it produces two records starting with v=spf1, which is a permanent error under RFC 7208 and causes SPF to fail outright.
# Wrong — two separate TXT records at the apex
"v=spf1 include:secureserver.net -all"
"v=spf1 include:_spf.google.com -all"
# Right — one record, both sources merged
"v=spf1 include:secureserver.net include:_spf.google.com -all"Edit the existing record instead of adding another. The SPF Validator flags duplicates and counts your DNS lookups against the limit of ten.
Confirm It Actually Published
The GoDaddy interface confirms that it saved a record, which is not the same as confirming that resolvers can see it at the hostname you intended. Check the real thing:
# Query the record you meant to create
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:reports@example.com"
# Doubled hostname? This is what the mistake looks like
$ dig +short TXT _dmarc.example.com
(no output)
$ dig +short TXT _dmarc.example.com.example.com
"v=DMARC1; p=none; rua=mailto:reports@example.com" <-- the record is hereThat second lookup is the fastest way to confirm the Name-field mistake. If the record answers at the doubled hostname, delete it and re-add it with just the label.
Verify the record with the TXT Lookup tool
Common Failures and What They Mean
| Symptom | Cause | Fix |
|---|---|---|
| Checker reports no record | Full domain typed into Name, creating a doubled hostname | Re-add with the label only |
| Nothing you add ever resolves | Nameservers delegated away from GoDaddy | Add the record at the real DNS host |
| SPF permanent error | Two records starting with v=spf1 | Merge into one record |
| Record found but not parsed | Literal quotes stored in the value | Re-enter without quotes |
| DKIM signature fails | Key truncated at 255 characters | Split into quoted chunks, re-verify |
| Old value still returned | Previous TTL still cached | Wait out the old TTL, query the authoritative NS directly |
Set the TTL to 600 seconds using the Custom option while you are iterating. Changes then become visible in ten minutes instead of an hour, which turns a frustrating afternoon into a few quick attempts. Raise it once the record is confirmed correct.
Frequently Asked Questions
1. Why did GoDaddy turn _dmarc into _dmarc.example.com.example.com?
Because the Name field is relative to your zone — GoDaddy appends the domain for you. Entering the full hostname appends it a second time. Enter only the part in front of your domain (_dmarc), or @ for the domain itself.
2. I added the record but a lookup still finds nothing. What is wrong?
Check your nameservers first with the NS Lookup. If they point somewhere other than GoDaddy, the records you added in GoDaddy are not being served — you are editing an inactive zone. This is the single most common cause and no amount of waiting will fix it.
3. Should I wrap the TXT value in quotation marks?
No. GoDaddy adds the quoting that DNS requires when it serves the record. Typing your own quotes stores them as part of the value, so "v=spf1 -all" becomes a record whose text begins with a quote character and no longer parses as SPF.
4. What TTL should I use?
Use the shortest TTL GoDaddy allows (600 seconds, via Custom) while you are still making changes, then raise it to an hour or more once the record is correct. A long TTL on a wrong record means waiting out the cache before your fix is visible.
5. Does GoDaddy really need 48 hours?
No. The 48-hour figure in their interface is a worst-case disclaimer. New TXT records normally appear on GoDaddy nameservers within a minute or two. What actually delays visibility is a resolver that cached the previous answer, and that is bounded by the old record TTL, not by GoDaddy.
6. Can I have two TXT records on the same name?
Yes for most purposes — domain verification tokens from several vendors coexist happily at the apex. The exception is SPF: exactly one record starting with v=spf1 is permitted per hostname, and a second one causes a permanent error rather than a merge.