How do I re-assign domain ownership in Google Postmaster Tools?
Published 7 May 2025
Updated 24 Jul 2026
11 min read
Summarize with
Updated on 24 Jul 2026: We clarified Google's current verification flow, account handover steps, DNS guidance, and primary-domain rules.
You re-assign domain ownership in Google Postmaster Tools by having the replacement account verify the domain again with its own DNS TXT record. There is no simple owner-transfer button that changes the original verified owner into a different verified owner. Read-only access is delegated viewing access, so adding someone as read-only does not make them an owner.
The clean path is to keep the current owner active, have the replacement account add the authenticated sending domain, publish the Google verification TXT record it receives, wait for verification, then remove old access and stale DNS tokens. If existing read-only access prevents a fresh TXT prompt, remove that share and retry in a clean session. Google's setup page says that independent access for multiple accounts requires a separate DNS verification record for each account.
- Direct answer: verify the domain from the new owner's account instead of trying to port the old owner's token.
- Domain choice: add the domain used by the DKIM d= value or SPF Return-Path for outgoing mail.
- Read-only caveat: remove the future owner as a viewer if the add-domain flow skips the TXT prompt.
- DNS rule: keep the old token until the new account has verified and can open the dashboards.
- Session check: use a private browser window with only the replacement Google account signed in.
- Operational check: confirm Gmail reputation, spam rate, authentication, and delivery data still appear after the switch.
What ownership means in Postmaster Tools
In Postmaster Tools, a verified owner is the Google account that proved control of the domain by placing Google's verification token in DNS. A read-only user can view the domain data that an owner shares, but that user has not proven DNS control from their own account. That difference matters during handover because the viewer's access depends on the old owner's sharing setup.
Read-only access
- Purpose: lets another Google account view the domain's Postmaster Tools data.
- Limit: does not create a separate DNS verification record for that account.
- Handover issue: the domain can reappear without offering a fresh TXT record.
Verified owner access
- Purpose: proves that the Google account controls the domain's DNS.
- Requirement: needs a Google-generated TXT verification record in the domain zone.
- Handover value: the new account keeps access without depending on the old owner.
Treat Postmaster Tools ownership like a DNS-backed access grant, not a user role that can be renamed. That framing prevents the common mistake of handing someone read-only access and assuming the domain has been transferred. It has not. The replacement account needs its own proof of control.
Google Postmaster Tools Manage Domains screen with owner and read-only access.
For a durable access plan, use a business-controlled Google account as the verified owner and document its recovery process internally. Verify the domain from every account that needs independent ownership, then use read-only sharing for people who only need dashboard access.
The safe re-assignment workflow
The safest workflow keeps both access paths alive until the new one is proven. Do not start by deleting the old owner's DNS token. Start by preparing the replacement account and giving the DNS administrator the exact host and TXT value Google provides.
- Choose the owner: pick a durable Google account controlled by the business, not an employee's personal account.
- Check current access: note who owns the domain, who has read-only access, and which DNS TXT record belongs to each verified account.
- Choose the domain: use the DKIM d= domain or SPF Return-Path domain that authenticates the outgoing mail you want to monitor.
- Add the domain: have the new owner open Postmaster Tools and add that same authenticated sending domain.
- Publish the token: add the Google TXT value at the exact DNS host shown without replacing other TXT values.
- Verify and confirm: click Verify from the new account and allow up to 10 minutes for the status to update.
- Troubleshoot read-only access: if no new TXT prompt appears, remove the replacement account's viewer access and repeat the add-domain step in a clean session.
- Clean up later: remove old shares and stale TXT records only after the new owner has stable access.
Example Google TXT verification recordDNS
example.com. 3600 IN TXT "google-site-verification=abc123exampleToken"
Do not remove the old verification first
Removing the existing owner's TXT record before the new account verifies can remove the fallback access path. Keep the old token until the new owner has completed verification, signed in again, and opened the expected dashboards.
- Safer order: new token first, new verification second, old cleanup last.
- Audit note: record the Google account and DNS token owner in your internal runbook.
If you are doing this for a client, make the client account verify the domain and then grant your team read-only access. That keeps ownership with the organization that controls the domain. If your team owns the token and leaves later, the same handover problem returns.
When the new owner only sees read-only access
A confusing case occurs when the replacement account was already added as a read-only user. They try to add the domain, but Postmaster Tools puts the shared domain back in their account without showing a new DNS TXT record. The account is still using delegated access rather than a separate verification path.
Remove that account as a read-only user from the current owner's side, sign out of every Google account, then use a private window to sign in only as the replacement owner and add the domain again. If permissions were just changed, allow time for Postmaster Tools to refresh the access state.
Flowchart showing read-only removal, DNS verification, and old token cleanup.
- Remove sharing: the current owner should remove the future owner from read-only access.
- Reset the session: the future owner should sign out and use a private window with no other Google accounts signed in.
- Try again: the future owner should add the authenticated sending domain again and look for a new TXT record.
- Allow a refresh: wait for the permission change to appear before repeating the same steps.
- Verify DNS: confirm the exact TXT value resolves publicly, then allow up to 10 minutes for Google's status to update.
If the TXT prompt still does not appear
Check that the future owner is using the intended Google account, not a browser profile tied to a different account. Also check that the old owner removed the exact email address that is trying to verify the domain.
If the original owner left the company and nobody can remove read-only access, the recovery path changes. Use the regain admin access workflow and gather DNS access proof before escalating internally.
What to check after the handover
Once the new owner is verified, confirm that the expected Gmail dashboards remain available. Postmaster Tools data applies only to messages sent to personal Gmail accounts, and low-volume domains can have empty or incomplete charts because Google applies privacy thresholds.
The ownership handover does not require changes to SPF, DKIM, DMARC, MX, or the sending infrastructure. A quick domain health check can confirm that the Google verification TXT value was added without disturbing the domain's existing mail records.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Send a real message to a personal Gmail account and inspect the authentication results with an email test. This checks the live sending path separately from the Postmaster Tools ownership change.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's product can sit beside Postmaster Tools when the team needs DMARC reporting beyond Gmail-specific dashboards. Suped parses DMARC aggregate reports so the new owner can identify sending sources, authentication failures, reporting gaps, and changes in policy coverage after the handover.
Use DMARC monitoring to confirm that reporting reaches the expected destination and that known sending sources continue to authenticate after any related DNS administration work.
Access models and DNS choices
Different ownership situations call for different DNS choices. Do not treat one Google TXT token as a shared password. Each account that needs independent verified ownership should have its own verification token.
|
|
|
|---|---|---|
Employee handover | New owner verifies first | Lost access |
Agency handover | Client owns DNS token | Vendor lock-in |
Read-only viewer | Verify independently | No TXT prompt |
Primary and subdomain | Verify primary first | Wrong reporting scope |
Common Postmaster Tools ownership situations
Keep the DNS change limited. Add Google's verification value at the exact host shown in Postmaster Tools. Do not replace SPF, DKIM, DMARC, MX, tracking CNAMEs, or existing Google tokens. DNS zones can publish several TXT values at the same host name.
A Postmaster Tools ownership change does not require a DMARC policy change. Keep the existing DMARC record stable unless the handover is part of a separately planned authentication change.
Example DMARC record to leave stableDNS
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; " "rua=mailto:dmarc@example.com" )
If the new owner is also responsible for authentication, pair the Postmaster Tools handover with a short DNS inventory. The verification walkthrough covers the add-domain part in more detail.
Edge cases that change the plan
Most re-assignment work is simple once DNS access is available. Harder cases involve missing people, limited DNS access, a domain that does not match the authenticated mail stream, or confusion between a primary domain and a sending subdomain. Confirm the exact domain name before changing anything.
- Authenticated domains: add the DKIM d= domain or SPF Return-Path domain used by the messages you want Postmaster Tools to report.
- Subdomain dashboards: add a subdomain after the primary domain when it needs a separate dashboard; a verified primary domain generally covers subdomain verification.
- Compliance dashboard: expect compliance status at the primary-domain level even when traffic uses subdomains.
- Previous owner gone: recover through a new DNS verification and internal account controls instead of waiting for a former employee.
- DNS provider limits: add another TXT value at the same host rather than replacing SPF or existing Google tokens.
- Data thresholds: newly verified domains need sufficient traffic to personal Gmail accounts before privacy-protected charts populate.
A practical access policy
Use a business-controlled Google account as the verified owner, document the DNS token, and grant read-only access to individuals who need reporting. That keeps ownership separate from day-to-day user turnover.
- Owner account: should be tied to a durable business identity.
- Viewer accounts: should be removed when people leave the role.
- DNS notes: should identify which verification record belongs to which account.
The same housekeeping matters for blocklist and blacklist checks if the handover coincides with a sending-domain transition. When DNS ownership, sending vendors, or IP pools change at the same time, monitor domain and IP reputation for several sending cycles.
Views from the trenches
Best practices
Keep the current owner active until the replacement account verifies with its own TXT record.
Record who owns each Postmaster domain and which DNS token proves that account's access.
Use a short DNS change window, then confirm Gmail dashboards still populate after handover.
Common pitfalls
Leaving the new owner as read-only can stop the fresh verification prompt from appearing.
Removing the old TXT record first can break access before the replacement owner is ready.
Using the wrong Google session can make a successful permission change look ineffective.
Expert tips
Have the new owner use a private window after their read-only access is removed.
Keep both verification tokens temporarily when two accounts need independent ownership.
Check public DNS resolution before treating a verification delay as a product issue.
Marketer from Email Geeks says ownership is not really ported. The new account should add the domain and publish its own DNS verification record.
2021-09-02 - Email Geeks
Marketer from Email Geeks says removing read-only access first can force the clean TXT verification path to appear for the replacement account.
2021-09-02 - Email Geeks
Final handover checklist
You do not re-assign a Google Postmaster Tools owner by editing a role. You create a new verified owner by verifying the same authenticated sending domain from the replacement Google account.
Keep the old owner active, have the new account request and publish its own TXT record, verify the new account, then clean up old shares and stale tokens. If read-only access suppresses the verification prompt, remove that share and repeat the add-domain step in a clean browser session.
- Best default: new owner verifies first, old owner is removed last.
- Best account: a business-controlled Google account with documented recovery and DNS access.
- Best follow-up: confirm Gmail dashboards, test live authentication, and review DMARC reporting after related DNS work.
