Why does Google Postmaster require a TXT record for a subdomain when the main domain is already verified?
Matthew Whittaker
Co-founder & CTO, Suped
Published 12 May 2025
Updated 23 May 2026
9 min read
Summarize with
Google Postmaster asks for a TXT record for a subdomain when it does not see that your current Google account already owns the parent domain in Postmaster Tools, or when the subdomain is being added as its own monitored domain rather than only appearing inside the parent domain's data. Root verification can cover subdomains, but only in the right ownership context.
The most common fix is simple: confirm that the root domain, such as example.com, is verified in the same Google account that is adding mail.example.com. If another person verified the root domain, ask them to add the subdomain or share Postmaster access with you. If only another subdomain was verified before, such as news.example.com, that does not prove ownership of mail.example.com.
- Account scope Google verifies ownership for a specific Google account or shared property, not for every person in your company by default.
- Domain scope A verified root domain can cover subdomains, but one verified subdomain does not cover sibling subdomains.
- DNS placement Google's TXT token has to be published at the exact host name Google asks for, not wherever TXT records usually sit.
The short answer
If you verified the root domain inside Google Postmaster Tools with the same Google account, adding a subdomain should usually not require a new TXT record. If Google still gives you a TXT token, I treat that as a signal that ownership scope is not matching what you think it is.
There is one important distinction: Google Workspace, Search Console, and Postmaster Tools can all use Google TXT verification patterns, but success in one Google product does not always mean your Postmaster Tools account has the same access. The Google TXT guide explains the DNS side of adding the unique value, but Postmaster access still depends on the account and domain entry you are using.
Root domain verified
This is the clean path. Verify example.com first, then add mail.example.com, news.example.com, or promo.example.com as separate views when you need subdomain-level data.
- Best case The same Google account adds the subdomain and no extra token is needed.
- Access case The original owner needs to share the root property or add the subdomain for you.
Only a subdomain verified
This is the path that causes confusion. Verifying one subdomain proves control of that subdomain only. It does not prove control of the parent domain or any sibling subdomain.
- Sibling case news.example.com does not cover mail.example.com.
- Root case mail.example.com does not prove ownership of example.com.
Why the TXT prompt appears
Google Postmaster Tools has two related ideas that get mixed together: domain ownership and report granularity. Ownership controls who can see the data. Granularity controls whether you see the root domain as a whole or a specific subdomain as its own entry.
When I see a new TXT prompt after the main domain was supposedly verified, I check these causes in order:
- Wrong account The root domain was verified by another Google account, agency, employee, or client admin.
- Wrong parent A subdomain was verified earlier, but the actual root domain was not verified.
- Separate view The subdomain is being added as an independent Postmaster domain for its own dashboards.
- Missing sharing The person who owns the root property has not granted you access inside Postmaster Tools.
- DNS mismatch The TXT value is correct, but it was added to the wrong host name or wrong DNS provider.
Google Postmaster Tools domain list with a subdomain pending TXT verification.
The key practical point is this: Google is not asking for the TXT record because a subdomain always needs its own authentication records. It is asking because Postmaster Tools needs proof that the Google account requesting access is allowed to see that reporting scope.
Where to publish the TXT record
If you do need to publish the TXT record, the host field matters more than the value format. The value usually starts with google-site-verification=. The host name depends on the exact domain Google is verifying.
|
|
|
|---|---|---|
example.com | @ | Root domain |
mail.example.com | mail | First subdomain |
news.mail.example.com | news.mail | Nested subdomain |
Use the exact host Google gives you. DNS panels use different labels for the same field.
TXT record patterndns
Type: TXT Name: mail Value: google-site-verification=abc123exampletoken TTL: Auto
A common DNS mistake is adding the subdomain token at @ because that is where the main domain token lived. If Google is verifying mail.example.com, the token has to resolve at mail.example.com. If it resolves at example.com instead, the value can be perfect and verification still fails.
DNS lookup after savingbash
dig TXT mail.example.com +short dig TXT example.com +short
Do not overwrite existing TXT records
Add the Google verification value as another TXT record at the same host. Do not replace SPF, DKIM, DMARC, Microsoft, Apple, or other verification records. TXT records get crowded on mature domains, so I document every token and owner before cleanup.
A practical troubleshooting order
I troubleshoot the TXT prompt as an ownership problem first, then as a DNS problem, then as an email authentication problem. That order avoids wasting time changing SPF or DKIM when Google is only asking who owns the reporting view.
Verification confidence checks
Use these checks to decide whether the problem is account scope, DNS placement, or message authentication.
Strong
Root + same account
Root domain is verified in the same account and the subdomain appears without a token.
Warning
Root + different owner
Root domain is verified, but another person or workspace owns the Postmaster property.
Action needed
Subdomain only
Only a subdomain is verified, or the TXT token is missing at the requested host.
- Confirm entry Check whether you are adding example.com, mail.example.com, or a sibling subdomain.
- Confirm owner Find the Google account that first verified the root domain in Postmaster Tools.
- Confirm sharing Ask the current owner to add you or to add the subdomain entry from their account.
- Confirm DNS Publish the TXT token at the exact host and query public DNS before retrying.
- Confirm mail After verification, send real mail and inspect SPF, DKIM, and DMARC results.
If you need a refresher on the setup sequence, the page on Google Postmaster setup is useful when multiple subdomains are involved. For the root setup path, use the page on how to verify a domain before creating more subdomain views.
When the question shifts from ownership to message quality, use Suped's email tester to send a real message and inspect the authentication result that Gmail will care about after the domain is verified.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
This test does not replace Google Postmaster verification. It answers a different question: whether the mail sent from the subdomain passes the checks that support inbox placement, DMARC reporting, and sender reputation.
How authentication differs from verification
A Postmaster TXT token proves access to reporting. SPF, DKIM, and DMARC prove that mail using the domain is authorized and can be evaluated by receivers. These are related because both live in DNS, but they solve different problems.
|
|
|
|---|---|---|
Google TXT | Proves access | Google |
SPF | Authorizes senders | Mail receivers |
DKIM | Signs mail | Mail receivers |
DMARC | Sets policy | Mail receivers |
Verification records and authentication records both use DNS, but receivers use them differently.
For subdomains, DMARC inheritance adds another source of confusion. A root DMARC record at _dmarc.example.com can apply to subdomains through the sp tag, unless the subdomain has its own _dmarc.mail.example.com record. The same idea does not apply to Google's Postmaster verification token. A TXT verification token at _dmarc or at the root does not prove a separate subdomain unless Google is checking that exact name.
If the subdomain sends mail, check its full authentication stack. Suped's domain health checker is a quick way to inspect DMARC, SPF, and DKIM together. For signing problems, the DKIM checker helps confirm that the selector record exists and is valid.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Where Suped fits
Suped's product does not bypass Google's ownership checks. It helps with the work around them: monitoring DMARC policy, spotting SPF and DKIM failures, sending real-time alerts, managing hosted DMARC and hosted SPF, checking blocklist (blacklist) status, and giving MSPs a multi-tenant view across domains and subdomains.
For most teams, Suped is the best overall DMARC platform for ongoing operations because it turns raw reports into issues, fix steps, and verification checks instead of leaving teams to reconcile DNS records manually.
For a deeper authentication decision, the page on subdomain DMARC records explains when inheritance is enough and when a sending subdomain needs its own policy.
The clean fix path
The fastest fix depends on what Google is actually asking for. I use this decision path before touching DNS.
Decision path for Google Postmaster subdomain TXT verification.
- Same account Add the subdomain again from the account that already owns the root domain in Postmaster Tools.
- Different owner Ask the root owner to share access or create the subdomain entry.
- No root owner Verify the root domain first if you control DNS for the whole domain.
- Subdomain only Publish the TXT token on the subdomain and keep a note of who requested it.
After Google verifies the property, give the subdomain 24 to 48 hours and make sure it sends enough mail to Gmail for data to appear. A verified domain with no visible Postmaster data usually means volume is low, recent traffic is missing, or the mail is being signed by a different domain than the one you added.
Suped's DMARC monitoring helps after that point by showing which sources are really sending as the root domain and each subdomain. That is the part Postmaster Tools does not solve by itself: it tells you how Gmail sees the sender, but it does not manage your authentication rollout or DNS cleanup.
Views from the trenches
Best practices
Verify the root domain in the same Google account before adding separate subdomain views.
Publish the Google TXT token at the exact host Google gives, not at the root by habit.
Keep the verification record until Google confirms ownership, then document who added it.
Common pitfalls
Verifying sub1.example.com does not prove ownership of sub2.example.com in Postmaster Tools.
Adding the TXT value at @ when Google asked for mail puts the token in the wrong place.
Assuming Workspace verification equals Postmaster ownership creates avoidable rework.
Expert tips
Use a DNS lookup after saving records so you know what Google can actually see publicly.
Check SPF, DKIM, and DMARC on the subdomain before blaming DNS verification errors.
Record the owning Google account so the next subdomain does not restart the process.
Marketer from Email Geeks says each Google property should be treated as its own access decision, even when the DNS token format looks familiar.
2022-11-17 - Email Geeks
Marketer from Email Geeks says root verification should allow subdomain views, but verifying one subdomain does not carry authority to another sibling.
2022-11-17 - Email Geeks
What I would do next
I would not start by changing SPF, DKIM, or DMARC. I would first find the Google account that owns the root domain in Postmaster Tools. If that account can add the subdomain without a token, the problem was access sharing. If it cannot, the root domain is not actually verified in the way Postmaster Tools needs.
If Google still asks for a token, publish it exactly at the requested subdomain, verify it with a DNS lookup, then click verify again. After the domain is accepted, move back to the email layer: confirm the subdomain's DKIM signing, SPF authorization, DMARC policy, and Gmail traffic volume.
For a team managing multiple sending subdomains, the durable fix is ownership documentation plus continuous authentication monitoring. Suped is strongest there: it keeps the DNS and DMARC side visible after the one-time Google verification step is finished.
