How to verify a domain in Google Postmaster Tools?
Published 14 May 2025
Updated 24 Oct 2026
13 min read
Summarize with
Updated on 24 Oct 2026: We clarified DNS verification, authentication-domain selection, and the checks to use when ownership verifies but Gmail data is missing.
To verify a domain in Postmaster Tools, sign in with a Google account, add the domain that authenticates your outbound mail, copy Google's DNS verification record, publish it in authoritative DNS, wait for DNS to answer publicly, then click Verify. If verification fails, check the exact DNS host and token in the active DNS zone. Choosing a domain used in DKIM or SPF determines which sending data appears after ownership is verified.
Start by checking the domain in the DKIM d= tag and the SPF Return-Path. Google Postmaster Tools works on authentication domains, not always the visible website domain or the friendly From domain. It reports on mail sent to personal Gmail accounts, including addresses ending in @gmail.com or @googlemail.com.
- Add the organizational domain first, verify it, then add subdomains for separate dashboard views.
- If you need subdomain-specific data, add the exact DKIM signing domain or SPF Return-Path domain.
- Use the provider shown by the domain's authoritative nameservers, not a guess based on the registrar or website host.
- If TXT verification looks correct but fails repeatedly, use CNAME verification if Google offers it.
Verify domain ownership step by step
Google Postmaster Tools add domain dialog with DNS verification.
The official Google setup steps use this flow: add the authentication domain, click Create, return to Manage Domains, open More options, choose Verify domain, copy the TXT or CNAME record, publish it at your DNS provider, then click Verify. Google also says primary-domain verification lets subdomains be added without extra DNS verification, which is why the root domain should usually be verified before separate subdomain dashboards.
You can click Not now and continue setup without finishing verification, but Postmaster Tools will not show email data for that domain until it is verified. A Google or Google Workspace account is required to sign in. Added users need one of those accounts and receive read access, while each separate owner account needs its own DNS verification record.
- Open Google Postmaster Tools using the Google or Google Workspace account that should own the domain.
- On Manage Domains, click Add new domain, enter the domain used to authenticate mail sent to personal Gmail users, then click Create and Back.
- Beside the domain, open More options and click Verify domain.
- Copy the TXT or CNAME record shown in the Verify ownership of domain window.
- Add the record at the authoritative DNS provider for that exact domain.
- Confirm the record is visible publicly before changing the token or retrying setup.
- Return to the verification window and click Verify after DNS answers with the expected value.
- After verification, use More options and Manage users to grant read access, then tell each user because Google sends no automatic notice.
Separate ownership verification from reporting
A Postmaster Tools TXT or CNAME record proves domain ownership. A domain can verify successfully even when it is not used to authenticate mail. For traffic dashboards, add the exact DKIM signing domain or SPF Return-Path domain; primary-domain verification lets you add its subdomains without another DNS ownership check.
Flowchart for choosing a Google Postmaster Tools verification domain.
Choose your DKIM or SPF authentication domain
Before adding anything to Postmaster Tools, inspect a real message that was sent through the same mail stream. The DKIM signing domain appears in the d= tag. In Gmail, open a delivered message, click More next to Reply, then Show original. Check DKIM-Signature and Return-Path to identify the authentication domains. A DKIM checker can then check the public key for the signing domain and selector found in that message.
Google's own wording is important here: Postmaster Tools expects the DKIM signing domain or the SPF Return-Path domain. If the DKIM and SPF domains are the same, Google can use messages authenticated by SPF, DKIM, or both for dashboard data. The marketing domain, click tracking domain, bounce host, and sending infrastructure host are not automatically interchangeable.
|
|
|
|---|---|---|
DKIM d=example.com | example.com | Matches the root DKIM signing domain. |
DKIM d=mail.example.com | mail.example.com | Adds a separate subdomain view after root verification. |
SPF only | Exact Return-Path domain | Matches SPF authentication; DKIM-only dashboards still need signed traffic. |
Intermediate subdomain | Only add if used in DKIM or SPF | Ownership verification alone does not create traffic data. |
Domain ownership verification and authentication-domain reporting are separate.
Root domain first
- Verify example.com before adding mail.example.com or mta.news.example.com.
- One verified primary domain reduces repeated DNS work for child domains.
- Good when several sending streams sit under the same organizational domain.
Subdomain first
- Useful when a subdomain needs its own authentication or delivery-error data.
- An unused intermediate subdomain can verify successfully but still show no sending data.
- Use the domain shown in DKIM or SPF, not the domain that looks tidiest.
If the team needs separate dashboards for several child domains, treat that as a reporting decision after the primary domain is verified. The exact mechanics are covered in more detail in subdomain setup, but the short version is simple: root first, exact subdomain second.
Publish the TXT or CNAME verification record
After choosing the right domain, copy the DNS record exactly. Add it in the DNS zone published by the domain's authoritative nameservers, not automatically where the domain was purchased or where the website is hosted. A host value of @ means the zone apex in many DNS systems, but other systems want the field left blank or filled with the bare domain name. For mail.example.com in the example.com DNS zone, the TXT host is usually mail. If mail.example.com has its own delegated DNS zone, @ refers to that subdomain instead. The examples below are illustrative; use the actual values supplied by Postmaster Tools.
Illustrative TXT record, use Google's actual tokentext
Host: @ Type: TXT Value: google-site-verification=abc123xyz TTL: 3600
Add Google's value as a new TXT record. Do not paste it into the SPF record, do not edit the DMARC record, and do not remove an existing Google verification record unless ownership cleanup has been planned. Multiple TXT records can exist at the same host when they are separate records.
TXT verification is the normal route. CNAME verification is a fallback if Google offers it and the TXT record is correct but verification still fails. The CNAME form changes both the host and target, so do not convert a TXT token into a CNAME manually.
Illustrative CNAME record, use Google's host and targettext
Host: abc123 Type: CNAME Value: gv-abc123.dv.googlehosted.com TTL: 3600
Common DNS mistakes
- The record is added under a DNS provider that is not authoritative for the domain.
- The DNS panel appends the domain twice, creating a hidden host name mismatch.
- The token has an extra space, missing character, smart quote, or copied label.
- An existing SPF, DMARC, DKIM, or verification TXT record is overwritten instead of adding a new record.
- The record is correct, but recursive resolvers still return the previous DNS state.
When the DNS host is unclear, check the domain's current nameservers first. Compare the authoritative answer with a recursive resolver's answer to distinguish an unpublished record from a cached response.
Troubleshoot failed verification
When verification fails, check the exact domain added, the authoritative DNS record, cached resolver responses, and the Google account that requested the token. Ownership verification depends on DNS control; matching the DKIM or SPF domain determines which sending data appears.
|
|
|
|---|---|---|
Record not found | Missing record or wrong DNS zone | Check the exact host at the authoritative nameservers. |
Wrong account token | Token copied from another owner's setup | Sign in as the intended owner and publish that account's token. |
Subdomain unverified | Record published at the parent apex | Use the subdomain host, or add the subdomain under a verified primary domain. |
Verified, no data | Too little qualifying traffic or a different authentication domain | Compare DKIM or SPF domains and allow for reporting delay. |
Access denied | Google account has no domain access | Ask an owner to grant read access to that Google account. |
Fast diagnosis for common Postmaster Tools verification failures.
Verification timing
Google usually verifies a readable DNS record immediately, but the status can take up to 10 minutes to update. DNS propagation and caching take separate time.
DNS publication
TTL dependent
Check the authoritative record and allow cached DNS answers to expire.
Ownership check
Usually immediate
Google can read the exact record for the domain being verified.
Status refresh
Up to 10 min
Allow the verification status to update after Google can read the record.
Compare authoritative and cached DNS answersbash
dig NS example.com +short dig @AUTHORITATIVE_NAMESERVER example.com TXT +short dig example.com TXT +short dig abc123.example.com CNAME +short
Replace example.com with the domain being verified and AUTHORITATIVE_NAMESERVER with one of its authoritative nameservers. For CNAME verification, replace abc123.example.com with Google's full verification host. The TXT token or CNAME target must match Google's value. If the authoritative answer is correct but a resolver still returns an older answer, allow that cached response to expire before retrying.
Verification and reporting are separate. A domain can verify successfully and still show empty dashboards until Gmail receives enough authenticated mail for that domain. Most dashboard data is updated within 24 hours but can take longer, and Google suppresses low-volume data for user privacy. Some dashboards require DKIM-authenticated messages, and Google does not publish a universal daily message minimum. The 5,000-message bulk-sender threshold does not guarantee dashboard data. If that happens, use the no data checks before changing DNS again.
For automated checks, the domain lookup guide uses v1 domain lookups to inspect registered domains. The Postmaster Tools API v2 reference documents domains.getVerificationToken for requesting a TXT or CNAME token and domains.verify for checking DNS ownership. The v2 API uses a different schema from v1, so existing integrations need client code changes.
Use Postmaster Tools v2 and Compliance status
Google encourages senders to move to Postmaster Tools v2, which launched in 2024. The legacy v1 web interface will eventually retire, but Google has postponed that retirement and has not published a replacement date. The legacy Domain and IP Reputation dashboards will also retire as Google develops more actionable replacements, so do not build a monitoring process around those two ratings alone. See Google's deprecation notice.
- The Compliance status dashboard is available to senders that send mail to personal Gmail accounts, including senders below the bulk-sender threshold.
- Compliance status is shown for the primary domain and includes relevant traffic from its subdomains.
- Most dashboard data usually updates within 24 hours, while a Compliance status change can take up to seven days.
- Postmaster Tools uses UTC and offers 7, 30, 60, 90, or 120-day dashboard windows.
Verification does not equal compliance
DNS verification proves that the Google account controls the domain. It does not prove that outgoing mail meets Gmail's sender requirements. After verification, check Compliance status for SPF and DKIM, DNS records, message format, encryption, and user-reported spam. Bulk senders should also review DMARC and unsubscribe requirements.
Compliant means the evaluated messages meet that requirement. Needs work identifies a requirement to fix. No data found means Google lacks enough qualifying messages to evaluate it. DNS-related statuses describe the settings observed when those messages arrived, rather than a live lookup of the current record.
If Compliance status says Needs work after a fix, wait up to seven days before judging the change. Its rolling data and primary-domain scope can make it differ from the Authentication or subdomain dashboards. Use the Deliverability analysis area for a recommendation tied to Gmail's current view of the domain. See Google's dashboard documentation for status definitions and reporting delays.
Use verification with authentication monitoring
Google Postmaster Tools gives senders a Gmail-specific view of spam rate, authentication, encryption, delivery errors, feedback loop data, and sender-requirement compliance. Some dashboards appear only when Gmail has enough authenticated traffic. The data applies to mail sent to personal Gmail accounts, not every inbox provider or receiving network. DMARC reports add authentication results from participating receivers.
Postmaster Tools
- Shows Gmail-specific signals for authenticated mail.
- Useful for Gmail delivery, complaint, authentication, and compliance checks.
- Does not explain every source, vendor, or DNS issue.
Suped
- Unifies DMARC monitoring with SPF and DKIM checks.
- Groups DMARC report data by sending source for investigation.
- It complements Postmaster Tools rather than replacing Gmail's own data.
Suped's DMARC reporting product helps identify the sending sources behind authentication failures seen in Postmaster Tools. Start with a domain health checker scan to review DNS, then use DMARC monitoring to review each source's SPF and DKIM results before changing DMARC policy.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
After DNS verification, send a real message through the live sending path and inspect the result with an email tester. The test shows authentication results and message headers at Suped's receiving server. Also inspect a message received in Gmail because routing and filtering differ between receivers.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For ongoing access, use an organization-managed owner account and grant teammates read access through their own Google accounts. Document each separate owner's DNS verification record so access can be reviewed during staff changes.
Views from the trenches
Best practices
Verify the primary domain first, then add subdomains for separate reporting where needed.
Check the DKIM d= value before choosing the domain in Postmaster Tools DNS setup.
Use CNAME verification if Google offers it and the correct TXT record still fails to verify.
Common pitfalls
Adding an unused intermediate host can leave dashboards empty after ownership verifies.
Pasting the token into the wrong DNS zone makes the record invisible to Google lookup.
Expecting instant dashboard data causes false alarms after successful verification.
Expert tips
Use an organization-managed owner account and give each teammate separate read access.
Document each token, host field, owner account, and verification date for recovery.
Pair Postmaster data with DMARC reports so Gmail signals have source context and fixes.
Marketer view
Marketer from Email Geeks says Google verification usually fails because the TXT record has a typo or is published in the wrong DNS zone.
2023-02-15 - Email Geeks
Marketer view
Marketer from Email Geeks says the domain added to Postmaster Tools needs to match the DKIM d= domain or the SPF Return-Path domain.
2023-02-15 - Email Geeks
