How to regenerate GPT TXT record after removal from DNS?
Published 17 Apr 2025
Updated 20 Oct 2026
12 min read
Summarize with
Updated on 20 Oct 2026: We updated the TXT recovery steps for browser verification, API v2 and DNS caching.
If a GPT TXT record was removed from DNS, first check the existing domain in Google Postmaster Tools for More options > Verify domain. Copy the TXT record if it is available, or retrieve a token through API v2 or DNS history. Here, GPT means Google Postmaster Tools, and the domain should be the DKIM d= domain or SPF Return-Path domain used to authenticate outgoing mail.
The domain can still appear as verified after its DNS verification record is removed. That status does not prove the token is still published. Restore the record without deleting the domain where possible. The verification token proves domain control; it does not authorise sending mail or directly improve Gmail delivery.
Short answer
You do not need to recreate the original string by hand. Use one of these recovery paths, starting with the option that preserves the existing domain resource.
- Check the existing domain: Sign in with the owning Google account and look for More options > Verify domain on Manage Domains. Copy the TXT record if the option is available.
- Retrieve or recover a token: If the browser does not expose it, use the API v2 getVerificationToken method with TXT selected, or recover the old value from DNS history.
- Restore and verify: Publish the complete value at the requested hostname, confirm the public DNS answer, then verify the existing domain again.
- Keep deletion as a last resort: Only consider removing and adding the domain again after the other recovery paths fail. It removes the domain from your account and does not guarantee a different token.
- Confirm DNS health: After restoration, check that the DNS edit did not damage SPF, DKIM, DMARC, or other TXT records.
Do not delete the domain first. The browser verification option or API v2 can provide a token without removing the domain from your account. Before any deletion, record who has access and which integrations use the domain.
Why a missing TXT record can still show as verified
A DNS verification record proves control of a domain. Google checks the published token and records the verification state. If the TXT value is later deleted, the displayed status can still be verified until an ownership check fails. Google does not document a fixed recheck interval, so do not wait for a status change to recover the record.
The Postmaster Tools API v2 treats the domain and its verification token as separate resources. The domain resource includes its verification state and last verification time, while getVerificationToken returns a DNS token for TXT or CNAME verification.
Record kept
- Verification: The expected proof remains available whenever Google checks DNS.
- Operations: Domain ownership is easier to confirm during audits and account handovers.
- Risk: The zone gets longer, so each TXT record still needs an owner and purpose.
Record removed
- Verification: The domain can remain marked as verified even though the proof is absent from DNS.
- Operations: An administrator must retrieve a token or recover the original value before reverification.
- Risk: A later ownership check can fail until the DNS proof is restored.
Google Postmaster Tools domain management page with status and last checked details.
Recovery paths
Preserve the current Postmaster Tools domain resource and account access. Check the browser verification option first. API token retrieval is useful for teams with API access, while DNS history can recover the exact old value without changing the domain resource.
|
|
|
|---|---|---|
Open Verify domain | Verification option is available | No API setup needed |
Request API token | API enabled and OAuth authorised | Preserves domain |
Recover old value | DNS history exists | Lowest change risk |
Retry verification | Token is available | Requires public DNS |
Delete and re-add | Other paths failed | Removes domain resource |
Practical recovery choices for a missing Google Postmaster Tools TXT verification record.
If the TXT record was removed during a cleanup, the original value often exists in a zone export, DNS provider audit log, deployment diff, or change ticket. Check those sources before changing the domain in Postmaster Tools.
Google Postmaster Tools TXT record recovery using DNS history and ownership verification.
On Manage Domains, check the verification status for the exact domain and signed-in Google account. A domain reporting dashboard does not replace this ownership check. Access granted by another owner is different from independent DNS verification.
Recover the TXT record in the web interface
Follow Google's setup instructions for the existing domain before removing it. If the verification option is unavailable, use the API or DNS history.
- Open Manage Domains: Sign in with the account that registered the domain and locate the exact domain name.
- Open verification: Choose More options beside the domain, then Verify domain.
- Copy the DNS record: In the verification window, copy the TXT value and the hostname Google specifies. Keep any other verification records in DNS.
- Complete the check: Publish the record, confirm it resolves publicly, then return to the verification window and click Verify.
If the domain is already verified and the interface does not offer the record, keep the domain in place and continue with API v2 or the DNS change history. For dashboard access alone, ask an existing owner to use More options > Manage users instead of setting up independent DNS verification.
Retrieve the token with API v2
Google Postmaster Tools API v2 has getVerificationToken for domain ownership verification. The API reference requires TXT or CNAME as the verification method and returns a token field. This is an alternative when the browser does not expose the TXT value or your team already manages domains through the API.
- Authenticate the owning account: Enable the Postmaster Tools API in the Google Cloud project. Use OAuth for the account that registered the domain, with the postmaster or postmaster.domain scope. A traffic-reporting scope does not grant access to this domain-verification method.
- Use the exact resource name: For mail.example.com, the domain resource is domains/mail.example.com and the token resource is domains/mail.example.com/verificationToken.
- Request TXT verification: Send the GET request with verificationMethod=TXT and an empty body. Copy the response token field exactly; do not publish the JSON response as the TXT value.
- Publish and verify: Add the token to authoritative DNS, confirm it is publicly visible, then verify in the web interface. API clients can call domains.verify with verificationMethod set to TXT.
API v2 token request pathhttp
GET https://gmailpostmastertools.googleapis.com/v2/domains/mail.example.com/verificationToken?verificationMethod=TXT Authorization: Bearer ACCESS_TOKEN
API v2 ownership verification requesthttp
POST https://gmailpostmastertools.googleapis.com/v2/domains/mail.example.com:verify Authorization: Bearer ACCESS_TOKEN Content-Type: application/json {"verificationMethod":"TXT"}
Successful API verification returns an empty response body. If a request fails, check the account, domain resource, API enablement and OAuth permissions before changing DNS again.
A token belongs to the Google account's domain verification context. Separate DNS verification records are required for independently verified accounts. For shared dashboard access, an existing owner can add users without asking each user to publish another token. Do not overwrite another account's record.
Put the record back safely
Publish the recovered or newly requested token at the exact hostname Google provides. Match it to the DKIM d= domain or SPF Return-Path domain already added to Postmaster Tools. Compare the visible From address with those authentication domains rather than assuming they are identical.
Illustrative TXT record for mail.example.com in the example.com DNS zonetext
Host: mail Type: TXT Value: google-site-verification=REPLACE_WITH_GOOGLES_TOKEN TTL: 3600
The example is a placeholder, not a usable verification token. In a DNS editor that appends example.com automatically, Host: mail creates mail.example.com. For verification at example.com itself, use the root label required by the provider, commonly @ or a blank field. If mail.example.com has its own delegated DNS zone, its record belongs at that zone root.
Before adding a subdomain token, check whether the primary domain is already verified by the same account. Google says that separate subdomain ownership verification is unnecessary in that case. You can still add the subdomain for separate dashboard views, but the Compliance status dashboard reports for the primary domain, including its subdomains.
Do not paste a Google verification value into an existing SPF record. DNS can have multiple TXT records at one host, but SPF permits only one policy record beginning with v=spf1 at that name. Keep Google verification and SPF in separate TXT records; an unrelated verification TXT record does not count towards the SPF DNS lookup limit.
- Hostname: Confirm the final fully qualified hostname after saving. Avoid an accidental name such as mail.example.com.example.com when the editor appends the zone name.
- Record type: Create the TXT record separately instead of merging it into any email authentication record.
- Token value: Copy the complete value without extra spaces or a second google-site-verification= prefix. Quotation marks shown by dig are DNS presentation syntax; do not add literal quote characters to the token.
- TTL: Use a normal TTL such as 3600 seconds unless the DNS provider or change window requires another value.
- Ownership: Document the Google account, record purpose, and removal rule so a later DNS cleanup does not delete it.
If the DNS provider interface is unfamiliar, follow its editing workflow. These GoDaddy TXT steps show the host, record type, TXT value, and TTL fields found in many DNS editors.
Checks after restoration
Confirm the TXT answer in public DNS before asking Google to verify it. Google's verification status usually updates immediately after a successful check, but can take up to 10 minutes. That is not a DNS propagation deadline. Check the authoritative zone and nameserver delegation if the record is missing, and investigate DNSSEC if validating resolvers return SERVFAIL.
DNS checks for the token and email authentication recordsbash
dig TXT mail.example.com +short dig NS example.com +short dig @ns1.example.net TXT mail.example.com +noall +answer +authority dig TXT example.com +short dig TXT selector1._domainkey.example.com +short dig CNAME selector1._domainkey.example.com +short dig TXT _dmarc.example.com +short
Replace ns1.example.net with a nameserver authoritative for the token hostname, and use a DKIM selector and signing domain found in a recent message. If the subdomain has a separate delegated zone, query its nameservers. A DKIM selector published as a CNAME needs its target checked for the TXT key. Compare authoritative answers with recursive DNS answers; do not assume that +short proves which zone answered.
DNS resolvers cache missing-record answers as well as existing records. A cached NXDOMAIN or no-TXT answer can persist until its negative-cache TTL expires after restoration. An older cached TXT answer can also omit the restored token until that answer expires. Lowering the new record TTL does not clear an answer already in cache.
Check the email authentication records after the TXT edit. A duplicated SPF policy or removed DKIM key can cause authentication failures. A missing or malformed DMARC record also needs correction. Restoring the Google verification token does not repair those records.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's Domain health checker can check the domain's email authentication records in one pass. If the immediate concern is whether SPF stayed valid after the DNS edit, use Suped's SPF checker before sending more mail from the affected domain.
DNS readiness for verification
Use these checks to decide whether DNS is ready before verifying the domain again.
Ready
Safe to verify
Token visible publicly and authentication records remain valid.
Watch
Wait and recheck
Token appears through some resolvers, but cached answers remain.
Problem
Fix DNS first
Token is absent after the expected TTL or authentication checks fail.
If the verification token disappeared during SPF cleanup, restore it as a separate TXT record and check SPF immediately. Review the SPF lookup count before changing include mechanisms. This TXT formatting guide explains how to avoid accidental changes to unrelated TXT values.
A verified domain with an empty dashboard does not establish that the TXT record is wrong. Google's dashboard documentation says reporting usually updates within 24 hours but can take longer, and low sending volume can leave data unavailable. Keep the valid token in DNS while checking traffic for the authenticated domain.
Check authentication after DNS changes with Suped
Suped's DMARC reporting and email authentication platform is useful after the immediate Google Postmaster Tools recovery. Postmaster Tools reports on mail sent to personal Gmail accounts. Suped helps check email authentication records and review DMARC aggregate reports for the affected sending sources.
After restoring the Google verification token, use Suped's domain health checker to check authentication DNS. Review DMARC reports for unexpected sending sources or authentication failures following the change. Suped does not regenerate Google's verification token, and DMARC aggregate reports do not contain it.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
Where SPF records have many include mechanisms or repeated vendor changes, Suped's SPF flattening and Hosted SPF can reduce manual edits to the SPF record. Keep the Google verification token separate even when SPF management is automated.
Manual DNS recovery
- Visibility: DNS provider history and administrator notes help recover the token.
- Validation: Each authentication record must be checked after the edit.
- Alerting: Run a record check after the change and investigate any delivery symptoms.
Suped workflow
- Visibility: Authentication health and sending-source data are available in one workflow.
- Validation: Record checks point to the DNS value that needs investigation.
- Follow-up: Review reported authentication failures after the DNS change; aggregate reports are not immediate.
Views from the trenches
Best practices
Keep verification TXT records documented with account, purpose, date, and removal rules.
Try the browser verification option or API v2 before deleting a Postmaster Tools domain.
Check DNS provider history and change tickets to recover the original verification TXT value.
Common pitfalls
Do not treat an undocumented recheck cadence as a dependable token recovery method.
Keep Google verification TXT values separate from the SPF policy already published at that host.
Check the primary domain and owning Google account before publishing a subdomain token.
Expert tips
Protect verification and authentication TXT records with documented cleanup rules.
Record the account and exact hostname for every token so ownership stays traceable.
After restoration, check all affected records so one fix does not create another.
Marketer view
Marketer from Email Geeks says a verified GPT domain often does not need the TXT value until the product checks ownership again.
2023-10-09 - Email Geeks
Marketer view
Marketer from Email Geeks says the GPT status details are on the domain management page, not inside the individual domain view.
2023-10-09 - Email Geeks
Frequently asked questions
You cannot calculate the original token yourself. Copy a TXT value from the existing domain verification window if it is available, request one through API v2, or restore the exact old value from DNS history. Retrieving a token does not guarantee a different string.
No. Check More options > Verify domain first, then use API v2 or recover the old DNS value. Keep deletion as a last resort after recording existing access and integrations. Removing and adding the domain again does not guarantee a new token.
Google says subdomains do not need separate ownership verification when the primary domain is already verified by the same account. Add the subdomain for separate dashboard views when needed. Compliance status still reports for the primary domain and includes its subdomains.
Independent ownership verification requires a separate DNS verification record for each account. For shared dashboard access, an existing owner can use Manage users instead. Keep every published token documented with its account owner.
No. Publish it as a separate TXT record at the requested host. An SPF policy has SPF syntax and must not contain an unrelated Google verification string.
After successful verification, the status usually updates immediately but can take up to 10 minutes. DNS caches have their own expiry times, and dashboard data usually updates within 24 hours but can take longer. An empty dashboard alone is not a reason to regenerate the TXT record.
