How to Add a TXT Record in Cloudflare

What Is a TXT Record and Why Cloudflare 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 string inside a TXT record is limited to 255 bytes, but a single record can concatenate multiple strings — which is why long SPF or DKIM values sometimes get auto-split across quoted segments. Cloudflare stores whatever content you paste and serves it back over standard DNS queries; it does not interpret or validate the string's meaning.

Cloudflare uses TXT records for the same purposes any DNS provider does: proving domain ownership (Google Search Console, Microsoft 365, Zoho, GitHub Pages), publishing email authentication policy (SPF, DKIM, DMARC), and satisfying ACME challenges for wildcard SSL certificates. Because TXT is a general-purpose container, one domain can have dozens of TXT records at different names — @, _dmarc, google._domainkey, and so on — without conflict, as long as none of them duplicate the same name + identical prefix (the classic SPF "two records" bug covered below).

Cloudflare's dashboard doesn't distinguish "verification TXT" from "SPF TXT" — they're all the same record type, just with different names and content. Understanding that upfront prevents a common mistake: creating a second v=spf1 record instead of editing the existing one when you add a new mail provider. If you're setting up mail auth specifically, see the SPF Record Generator guide for building the value correctly before you paste it here.

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

1. Log in to the Cloudflare dashboard and select the domain from your account's domain list. If you manage multiple domains, confirm you're on the right one before editing DNS — Cloudflare doesn't warn you twice.

2. Open DNS → Records. This is the same screen you'd use to check A or CNAME records. Click Add record in the top right.

3. Set Type to TXT. The form fields change slightly for TXT — there's no proxy toggle, because TXT records are always DNS-only and can't route through Cloudflare's edge network.

4. Enter the Name exactly as given. This is where most verification failures happen. If the third party says _dmarc.example.com, enter _dmarc (Cloudflare appends your zone apex automatically). For a root-domain record, use @. Don't include the domain twice — _dmarc.example.com.example.com is a common copy-paste error.

5. Paste the Content field 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 Auto unless you're actively troubleshooting propagation, in which case drop it to 60 seconds temporarily, save, wait for the change to take effect, then raise it back once verification succeeds.

7. Click Save. Cloudflare re-formats the quoting on save (wrapping the value in matched double quotes) — if the record displays oddly afterward, open it and re-save once; this fixes most cosmetic quote-mismatch warnings.

8. Confirm propagation before re-checking with the third party — see the CLI and tool checks below. Most Cloudflare TXT changes are visible globally within 5 minutes because Cloudflare's authoritative nameservers update near-instantly; any delay you see is almost always resolver caching downstream, not Cloudflare.

Name Field Reference Table

The Name field is the single most common source of TXT record failures in Cloudflare — a mismatched selector or an extra domain suffix produces a record that saves successfully but never matches what the verifying service looks up.

Verifying the Record with dig and nslookup

Run these from a terminal after saving, using your zone's actual name in place of example.com:

# Query the TXT record directly from Cloudflare's authoritative nameservers
dig TXT _dmarc.example.com @<cloudflare-ns-for-your-zone>.ns.cloudflare.com +short

# Query from your local resolver to check what's actually propagated to you
dig TXT example.com +short

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

If the direct-to-Cloudflare query returns the record but your local resolver doesn't yet, the record itself is correct and you're waiting on resolver cache TTL — not a Cloudflare 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 Cloudflare shows it saved. Cause: usually a Name field mismatch — a trailing domain suffix, wrong selector, or the record was added to a different zone (e.g., a staging domain instead of production). Fix: re-open the record in Cloudflare and compare the Name 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 name. RFC 7208 §4.5 requires exactly one SPF record per domain — two or more causes a PermError, which most receivers treat as an outright SPF fail. Fix: merge both include: mechanisms into a single v=spf1 string rather than adding a second record. See the SPF Record Generator guide for building one merged value.

Problem: Long DKIM key gets rejected or truncated. Cause: DKIM public keys frequently exceed 255 bytes, and some third-party tools generate the value already pre-split into quoted segments ("part1" "part2"), which Cloudflare 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 in Cloudflare but a global checker reports NXDOMAIN. Cause: the zone's nameservers at the registrar don't point to Cloudflare yet, so none of Cloudflare's DNS is authoritative for the domain. Fix: confirm delegation with the NS Lookup tool before troubleshooting the TXT record itself — a record in the right zone with the wrong nameservers upstream will never resolve publicly.

Key Takeaways

• ✓ TXT records in Cloudflare are always DNS-only — there's no proxy toggle to configure.
• ✓ Per RFC 1035, each string in a TXT record is capped at 255 bytes; long values get auto-split into quoted segments.
• ✓ A domain must have exactly one v=spf1 TXT record (RFC 7208 §4.5) — a second one causes PermError, not stacking.
• ✓ Cloudflare propagation is typically under 5 minutes; longer delays are almost always downstream resolver caching, not Cloudflare.
• ✓ Verify the Name 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 in both, confirm your domain's nameservers actually point to Cloudflare 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 GoDaddy or How to Add a TXT Record in Namecheap for the equivalent steps.