Zone editor notes · Beginner · 5 min per service
How to add txt records for verification — Where the Verifier Looks, and Why It Says No
You pasted the token, the panel says it saved, and the service still refuses to verify — so you need to know which of four things went wrong.
The short answer
The verifier queries your authoritative nameservers directly for a TXT record on a specific name. So the only question that matters is whether that exact name, in the zone that actually answers for your domain, returns that exact string. Check it with dig TXT before you press the verify button, not after.
Four things break this in practice: the record went into a zone that is no longer authoritative, the panel expanded the host field and put the token at the wrong name, a long value got split or quoted differently than intended, or a failed check is being cached negatively and the retry never reaches DNS at all.
By the HostingFast team · Reviewed 24 August 2026
Beginner
Skill floor
Quick
Hands-on time
4
Steps in total
24/7
Support on call
You need cPanel access, the token from whichever service is asking, and about five minutes per service. There is nothing destructive here — a wrong TXT record is inert rather than dangerous.
The verification tokens you add tend to accumulate, so keep a note of which service each one belongs to. An unlabelled TXT record is impossible to retire safely three years later.
The verifier reads DNS, not your website
This is worth internalising because it changes where you look when it fails. The service does not fetch a page or check your hosting. It resolves your domain to its authoritative nameservers and asks them for a TXT record. Your site can be entirely down and verification will still succeed.
It also means the record has to be in the zone that answers. If the domain is delegated elsewhere, adding the row in cPanel writes it to a zone nobody queries. Confirm who is authoritative first with dig NS yourdomain.com, then add the record there.
Host expansion, and the two names it puts your token on
cPanel appends the zone to anything in the Name field that is not fully qualified. Enter @ and you get the apex, which is what most verifications want. Enter yourdomain.com and you may well get yourdomain.com.yourdomain.com, which resolves for nobody and looks nearly correct in the panel.
Selector-style records have the same trap in reverse. Google Workspace and similar services often ask for a token at a prefixed name; enter only the prefix and let the panel add the domain. After saving, always read the row back and confirm the name is the one the service asked for.
Quoting, 255-character chunks and split strings
A single TXT string is limited to 255 characters at the protocol level. Longer values — a 2048-bit DKIM public key is the usual example — are stored as several strings inside one record, and resolvers concatenate them on read. Panels handle that differently, and some require you to insert the quotes yourself.
So compare what dig returns against what the service gave you, character for character. If dig prints two quoted chunks and the concatenation matches your token exactly, you are fine. If a space has crept in at the join, the record is wrong in a way that is invisible in the panel.
Negative caching, and why the retry keeps failing
When a resolver asks for a name that does not exist, the authoritative server returns NXDOMAIN, and that answer is cached too — for a period governed by the zone's SOA minimum TTL. So a verification attempted before the record existed can keep failing for a while after you fix it.
The cure is patience plus the right test. Query the authoritative nameserver directly with dig TXT name @ns1.yourprovider.example +norecurse; that answer bypasses every cache. Once authoritative is correct, further retries against the service are just waiting, and hammering the button changes nothing.
Why the follow-through is quick here
Guides written against imaginary hosting go stale fast. These are written against the real thing: the same panel, the same installer, the same defaults sitting in your account when you log in.
Every plan includes an SSL certificate that reissues itself before expiry, so the padlock is never something you have to diarise.
- Four named failure modes, not one vague one
- Authoritative queried directly, cache bypassed
- String splitting explained with the limit
- Engineers on support at any hour
Why HostingFast
Standard on every plan
Four failure modes, named
Wrong zone, host expansion, string splitting and negative caching cover almost every failed verification, and each one has its own test.
Diagnosed at the source
The page has you query the authoritative nameserver with +norecurse, which is the only answer no cache can distort.
The 255-character limit stated
Long DKIM values are split into several strings by design, and the page explains what dig should print when it is right.
4 steps, no padding
Four actions, each with something you can read back, and no instruction to simply wait and try again.
Tokens kept labelled
The page tells you to record which service owns each TXT row, so retiring one in three years is possible.
Engineers on call
If a token verifies from dig but not from the service, support answers at any hour and will look at the zone with you.
Quick Start
From order to online
- 1
Find out who is authoritative first
Run dig NS yourdomain.com and confirm the nameservers listed are the ones whose panel you are about to open. Adding a record to a zone that no longer answers is the single most common reason a perfectly correct token verifies nowhere.
- 2
Copy the token verbatim, prefix included
Paste it rather than retyping, and keep any leading prefix such as google-site-verification= exactly as given. Trailing whitespace from a copy-and-paste is real and invisible, so check the ends of the string before you save.
- 3
Add it, then read the saved row back
Enter the host part alone and let the panel append the zone. After saving, check how the Name field was expanded. If you see the domain twice, delete the row and recreate it rather than editing around it.
- 4
Query authoritative, then press verify once
Run dig TXT thename @ns1.yourprovider.example +norecurse and compare the output to the token character by character, including how any long value was split. Only when that matches should you press the service's verify button.
Built In
Loaded onto every plan
- SSH with Git and Composer on the developer plans
- Money back: 30 days on hosting, 7 on reseller
- Spam and virus screening on every mailbox as standard
- Free SSL on every plan, renewed before it can lapse
- Daily backups with self-service restores from the panel
- Staging environments for testing before you ship
- A renewal price identical to the one you signed up at
- Per-site PHP version switching in the control panel
- WordPress and 400+ other applications in one click
- 99.9% uptime as the target, monitored around the clock
Frequently Asked
What people ask us most often
dig shows my token but the service still refuses. What now?
Check the name, then the caching. Confirm the record is on the exact hostname the service asked for rather than on the apex or on a doubled name, since dig will happily show you a correct token at the wrong address. Then remember that an earlier failed attempt is cached as NXDOMAIN for the zone's SOA minimum, so a correct record can still fail for a while. Query authoritative with +norecurse and if that is right, wait rather than retry.
Can I hold several verification TXT records at once?
Yes. Multiple TXT records on the same name are legal and normal, and every verifier reads the whole set looking for its own string, so tokens from different services coexist without interfering. The one exception is SPF: you may have only one SPF record per name, and adding a second breaks authentication rather than combining them. Merge SPF into a single record with multiple include mechanisms.
Should the host be @ or the full domain name?
Use @ for the apex and a bare prefix for anything else, and let cPanel append the zone. Entering the full domain is what produces yourdomain.com.yourdomain.com, a name nothing will ever query. If you genuinely need a fully qualified value in a record's data field rather than its name field, that is where a trailing dot belongs.
How long should I wait before pressing verify again?
Long enough for the negative answer to expire, which is governed by the SOA minimum TTL for your zone rather than by the TTL on the record you just made. Read it with dig SOA yourdomain.com and wait that long. In the meantime, confirming the record from the authoritative nameserver directly tells you everything a retry would, without burning an attempt.
Keep reading
How to Harden a Site With .htaccess
Add the rules that actually help, and skip the copied blocks that cost a request and protect nothing.
How to Enable Two-Factor Authentication
Put a second factor on every account that can change code, without locking the team out.
TXT Record (Glossary)
The definition this page leans on, with the string-splitting limit explained.
Plesk Reseller Hosting
Plesk reseller hosting with per-account isolation and the panel your clients expect.
Secure Hosting
Hosting with malware sweeping, edge filtering and certificates that renew themselves.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Verify it, then get on with the build.
Every plan carries the essentials other hosts bill as extras, and the support queue is answered by engineers rather than a macro.
View Plesk Reseller Hosting plans