Cloudflare is the easiest DNS panel to add a TXT record to and the easiest one to add a *wrong* TXT record to, because the Name field is relative to the zone and nothing stops you saving a record at a name you did not intend. This guide covers the field semantics, the proxy question, TTL, and how to prove the record actually published before you click "Verify" in whatever service asked you for it.
Where do TXT records live in the Cloudflare dashboard?
Log in, select the zone (the domain) from your account home, then open the DNS section and the Records list inside it. That page is the whole zone: A, AAAA, CNAME, MX, TXT, everything. Use Add record, set Type to TXT, and you get three fields — Name, Content, and TTL. Cloudflare occasionally reshuffles this navigation, so if the labels differ slightly, look for the DNS records table; the fields themselves have been stable.
*.ns.cloudflare.com names Cloudflare assigned your account.What goes in the Name field?
The Name field is a label *relative to the zone*. Cloudflare appends your domain to whatever you type. The single most common mistake is pasting a fully-qualified name from a provider's setup page and ending up with a record one level deeper than you wanted.
| You want the record at | Type this in Name | Typical use |
|---|---|---|
example.com (the apex) | @ | SPF, Google/Microsoft domain verification |
_dmarc.example.com | _dmarc | DMARC policy record |
selector1._domainkey.example.com | selector1._domainkey | DKIM public key |
_acme-challenge.example.com | _acme-challenge | Let's Encrypt DNS-01 validation |
mail.example.com | mail | Per-subdomain SPF or verification |
Cloudflare does normalise a name that already ends in the zone name — type _dmarc.example.com in the example.com zone and it stores _dmarc.example.com, not _dmarc.example.com.example.com. That safety net is real but it is not universal across providers, and it does not save you if you type the wrong label. After saving, read the record row: Cloudflare displays the full name it stored. If it says _dmarc.example.com.example.com, delete and re-add.
Does the value need quotes?
No. Paste the value exactly as the service gave it to you, without wrapping quotation marks. Quotes are DNS *presentation format* — they appear in zone files and in dig output because a TXT record is technically a list of character-strings. The dashboard adds them for you. If you type "v=spf1 include:_spf.google.com ~all" with the quotes, you can end up with a record whose literal content includes quote characters, and every SPF parser will then fail to recognise it.
Semicolons are fine and do not need escaping — a DMARC record is full of them. Long values are also fine: a single TXT character-string maxes out at 255 bytes, so a 2048-bit DKIM key is stored as several concatenated strings, and Cloudflare does that split for you. Never insert your own quotes or line breaks into a DKIM key to "help".
# Correct — paste exactly this into Content, no surrounding quotes
v=spf1 include:_spf.google.com ~all
# Correct DMARC value for the _dmarc name
v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
# Wrong — the quotes become part of the value
"v=spf1 include:_spf.google.com ~all"Why is there no orange cloud on a TXT record?
Proxying only applies to records that resolve to an address a browser will connect to — A, AAAA, and CNAME. There is no proxy toggle on TXT, MX, NS, CAA, or SRV records, and there should not be one. Proxying is Cloudflare answering with its own anycast IPs and terminating the connection; a TXT record has no connection to terminate. If someone tells you to "turn off the proxy for your SPF record", they are describing a problem that does not exist.
The proxy *does* matter for email in a different way. When A or CNAME records are proxied, the origin IP is hidden — which is good — but it means the hostname in your MX record must be an unproxied record, otherwise mail is delivered to Cloudflare's HTTP edge and nowhere useful. Check what your MX names resolve to with the MX Lookup if mail stops after you enable the proxy on a wildcard or apex record.
What TTL should you set?
Leave it on Auto. Cloudflare serves a short TTL for Auto records — on the order of a few minutes — which is exactly what you want for a verification token or a record you are about to iterate on. There is one caveat worth knowing: for records that are proxied, the TTL Cloudflare advertises is fixed regardless of what you choose, but for unproxied records like TXT your choice (or Auto) is what resolvers cache.
A short TTL only helps for a record that does not exist yet or that you are about to change. It does nothing about the *negative* cache: if a resolver already asked for _dmarc.example.com and got NXDOMAIN, it caches that absence for the interval in the zone's SOA minimum field, which on Cloudflare is typically well under an hour. That is why a token sometimes takes a few minutes longer to verify than the TTL suggests. See how long DNS propagation takes for the full picture.
How do you verify the record published?
Do not trust the dashboard row. Query DNS. The fastest check is a plain lookup against a public resolver, followed by a direct query to Cloudflare's own nameservers — if the authoritative answer is right but a public resolver disagrees, you are looking at cache, not a configuration error.
# What the world sees right now
dig +short TXT example.com
dig +short TXT _dmarc.example.com
# Ask Cloudflare's nameservers directly — bypasses every cache
dig +short NS example.com
dig @maria.ns.cloudflare.com +short TXT _dmarc.example.com
# Same thing with host(1), if dig is not installed
host -t TXT _dmarc.example.comSubstitute one of your own assigned nameservers for maria.ns.cloudflare.com — the dig +short NS line above prints them. A quoted string in the output means the record exists; empty output means it does not, at least not at the name you queried.
If the record is an SPF, DMARC, or DKIM record, validate the *content* as well as its existence — a published record with a syntax error verifies as "present" and still fails authentication. Run it through the SPF Checker, the DMARC Checker, or the DKIM Checker depending on which one you just added.
Cloudflare-specific problems worth knowing about
- Partial (CNAME) setup zones. On a partial zone Cloudflare is not authoritative for the domain — your real DNS provider is. Records you add in the Cloudflare dashboard on such a zone are not served to the internet. Verify with NS Record Lookup: if the nameservers are not Cloudflare's, add the TXT record at whoever they belong to instead.
- Two SPF records at the apex. Cloudflare will happily let you save a second TXT starting with
v=spf1. Receivers will not: two SPF records is a permanent error and authentication fails outright. Merge theinclude:mechanisms into one record — the SPF Record Generator will build the combined value. - Email Routing adds records for you. If you enable Cloudflare Email Routing it writes its own MX and SPF entries into the zone. If you already had an SPF record, reconcile them rather than leaving both.
- DNSSEC and stale delegation. If DNSSEC is enabled at the registrar with a DS record that no longer matches the zone, resolvers return SERVFAIL for everything, including your new TXT record. Confirm with the DNSSEC Checker and read SERVFAIL vs NXDOMAIN.
- Editing rather than adding. Most verification workflows want a *new* TXT alongside the existing ones. Multiple TXT records at the same name are legal and normal. The exception is SPF and DMARC, where exactly one record of that kind must exist at that name.
Adding the same record elsewhere? The equivalent steps are in Add a TXT Record on Namecheap and Add a TXT Record on GoDaddy. For background on what TXT records are for and their size limits, see the TXT record reference.