If a GPT TXT record was removed from DNS, the direct fix is to recover the original TXT value or delete and re-add the domain in GPT so it issues a new verification value. In this email authentication context, I am treating GPT as Google Postmaster Tools, because the record is tied to an authenticated sending subdomain.
Once Google Postmaster Tools still thinks the domain is verified, it usually will not show the original TXT string again. That is the awkward part. The account has a verified domain object, while DNS no longer has the proof that created it. The best recovery path depends on whether you need the old domain data, how quickly you need the record restored, and whether you can risk deleting the domain inside GPT.
My order of operations is simple: check whether the old value exists in DNS history or internal change logs, check the GPT domain management page for its last verification check, then delete and re-add only when a fresh token is worth the data and access tradeoff.
Short answer
You normally cannot regenerate the same GPT TXT value while the domain remains verified. You have four practical choices, and the cleanest one is not always the fastest one.
- Recover it: Look in DNS provider history, pull request history, Terraform state, screenshots, ticket comments, password manager notes, or an internal runbook that captured the original TXT value.
- Wait for recheck: Google Postmaster Tools commonly rechecks domain verification on a periodic cadence. After the check fails, the product can require verification again.
- Delete and re-add: Remove the domain from GPT, then add it again to force a new TXT value. Treat this as a deliberate change because historical visibility can be affected.
- Confirm DNS health: After the TXT record is back, check that no SPF, DKIM, DMARC, or other TXT records were damaged during the edit.
Do not delete the domain in GPT as the first move if the team depends on existing reputation and delivery history. Deleting and re-adding is the quickest way to get a new TXT value, but it is also the option with the highest product-side risk.
Why the old value disappears
A DNS TXT verification record is proof of control at a point in time. GPT asks you to publish a token under the domain or subdomain, checks DNS, then marks the domain as verified. After that, the UI often focuses on the verified state, not the original setup token.
That design is common across DNS verification systems. Some systems let the record be removed after verification, while others periodically re-check and fail the domain later. The safest operational rule is to keep verification TXT records in DNS unless the vendor documentation clearly says the record can be removed and the account owner accepts the risk.
Record kept
- Verification: Future checks keep passing because the expected token still appears in DNS.
- Operations: DNS ownership is easier to prove during audits, vendor reviews, and handovers.
- Risk: The zone gets longer, so TXT record ownership needs documentation.
Record removed
- Verification: The domain can stay verified until the next product-side DNS check.
- Operations: A future admin has to recover or regenerate a token without the original value.
- Risk: A periodic recheck can fail and interrupt access to domain data.
For similar DNS verification questions, the answer usually depends on whether the verifier treats the TXT record as a one-time check or a continuing proof. That same distinction appears in general discussions about records after verification and cases where a team has a lost TXT record.
Google Postmaster Tools domain management page with status and last checked details.
Recovery paths
My preferred recovery path is conservative: preserve the current GPT domain object when the historical data matters, and only regenerate the record when the old value cannot be recovered.
|
|
|
|---|---|---|
Recover old value | DNS history exists | Lowest risk |
Wait for recheck | GPT still verified | Slower |
Delete and re-add | Need new token | Possible data gap |
Use account notes | Setup was documented | Depends on process |
Practical recovery choices for a missing GPT TXT verification record.
Start with records of the DNS change. If the TXT was removed during a cleanup, the original value often exists in the old zone export, a DNS provider audit log, a deployment diff, or the ticket that requested GPT verification. If the DNS provider supports record history, check that before touching GPT.
A simple recovery flow for a missing GPT TXT record.
If the old value is gone, open the GPT domain management page and look for the status column or information icon next to the domain. The domain detail page is the wrong place for this check. The management table is where the verification status and last checked information usually appear.
Put the record back safely
When you have either the recovered token or a new token, add it at the exact hostname GPT asks for. If GPT verified the authenticated sending subdomain, publish the TXT record on that subdomain, not automatically on the root domain.
Example GPT verification TXT recordtext
Host: mail Type: TXT Value: google-site-verification=AbCdEfGhIjKlMnOpQrSt TTL: 3600
Do not paste the GPT value into an existing SPF record. DNS can have multiple TXT records at the same host, but SPF has a specific syntax and a domain must not publish more than one SPF record. Verification TXT strings and SPF mechanisms have different jobs.
- Hostname: Use the subdomain shown by GPT, such as mail.example.com, rather than guessing based on the sending domain.
- Record type: Create a separate TXT record for the GPT token instead of merging it into SPF, DMARC, or DKIM.
- TTL: Use a normal TTL such as 3600 seconds unless your DNS provider or change window requires something else.
- Ownership: Document the record owner and the reason it exists so a future DNS cleanup does not remove it again.
If the DNS provider UI is unfamiliar, follow the provider's own editing workflow. For example, these GoDaddy TXT steps show the basic fields most DNS editors ask for: host, TXT value, and TTL.
Checks after restoration
After publishing the TXT record, verify DNS before clicking any product-side verification button. DNS propagation is not a fixed timer. The record should be visible from public resolvers after the relevant TTL expires, but parent zone setup, DNSSEC problems, and provider caching can create delays.
DNS checks after adding the recordbash
dig TXT mail.example.com +short dig TXT example.com +short dig TXT _dmarc.example.com +short
I also check the rest of the email authentication zone because TXT edits are where mistakes happen. A missing quote, duplicated SPF record, or removed DKIM key can create delivery problems that look unrelated to GPT.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The Domain health checker is useful here because it checks DMARC, SPF, and DKIM in one pass. If the only question is whether SPF stayed valid after the DNS edit, use the SPF checker before sending more mail from the subdomain.
Restore confidence levels
Use these checks to decide whether the DNS side is ready before changing GPT again.
Ready
Safe to verify
TXT visible, no SPF duplication, DMARC still valid.
Watch
Wait and recheck
TXT visible in some resolvers, but TTL has not fully elapsed.
Problem
Fix DNS first
TXT absent after TTL, or SPF and DKIM checks fail.
If the GPT TXT record disappeared during SPF cleanup, separate the two jobs. Restore the verification record first, then review SPF length, DNS lookup count, and includes. A TXT formatting guide helps prevent accidental merging of unrelated TXT values.
How Suped keeps DNS changes controlled
Suped's product fits this workflow after the immediate GPT recovery is handled. GPT tells you about Gmail-facing domain reputation, while Suped monitors the authentication records that keep your sending domain trustworthy across mailbox providers.
For most teams, Suped is the best overall DMARC platform because it turns DNS and authentication data into specific issues and fixes. It brings DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, real-time alerts, blocklist monitoring (blacklist monitoring), and MSP multi-tenancy into one workflow.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
The practical benefit is change control. When someone edits DNS to restore a GPT TXT value, Suped can show whether SPF, DKIM, and DMARC still pass afterward. If SPF records are too long or spread across too many include mechanisms, SPF flattening and Hosted SPF reduce the amount of manual DNS editing needed later.
Manual DNS recovery
- Visibility: You rely on DNS provider history, screenshots, and individual admin memory.
- Validation: Each authentication record has to be checked separately after the edit.
- Alerting: Failures are noticed when someone checks manually or delivery symptoms appear.
Suped workflow
- Visibility: Authentication health, verified sources, and problem records sit in one view.
- Validation: DMARC, SPF, and DKIM checks point to the exact record that needs work.
- Alerting: Real-time alerts catch authentication failures after DNS changes.
Views from the trenches
Best practices
Keep verification TXT records documented with owner, purpose, date, and removal rules.
Check the GPT domain management page before deleting a verified domain for a new token.
Use DNS history and change tickets first, because they often contain the exact old value.
Common pitfalls
Do not confuse the GPT status column with a DNS history table in another interface.
Do not merge Google verification TXT strings into SPF records during DNS cleanup work.
Do not delete a verified GPT domain before confirming whether historical data matters.
Expert tips
Set DNS cleanup rules that protect verification, SPF, DKIM, and DMARC TXT records.
Create a rollback note for every TXT edit so removed verification values stay recoverable.
After restoration, check SPF, DKIM, and DMARC so one fix does not create a new issue.
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 from Email Geeks says Google commonly rechecks DNS verification around a 30-day cadence, so waiting can trigger a new verification step.
2023-10-09 - Email Geeks
The practical path
The right answer is not to keep clicking around GPT looking for the old TXT value. If the domain is still verified, GPT usually hides the original token. Recover the old value from DNS records or internal history first. If that fails, decide whether to wait for GPT to fail a recheck or delete and re-add the domain for a new token.
Once the TXT record is restored, leave it in place and label it clearly. The operational cost of keeping a small verification TXT record is lower than the cost of rediscovering it during an incident, a vendor handover, or a rushed DNS cleanup.
- Fastest route: Delete and re-add the domain only when a fresh token matters more than preserving current GPT state.
- Safest route: Recover the original token and republish it without changing the verified domain object.
- Best process: Treat all verification TXT records as owned configuration, not as temporary setup clutter.
