How do I re-assign domain ownership in Google Postmaster Tools?
Matthew Whittaker
Co-founder & CTO, Suped
Published 7 May 2025
Updated 21 May 2026
10 min read
Summarize with
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 only delegated viewing access, so adding someone as read-only does not make them the owner.
The clean path is: keep the current owner active, remove the future owner from read-only access if they already have it, have that account add the domain fresh, publish the Google verification TXT record it receives, wait for verification, then remove old access and stale DNS tokens. Google's own setup page also treats each account as needing its own verification path for the same domain.
Direct answer: verify the domain from the new owner's account instead of trying to port the old owner's token.
Read-only caveat: remove the future owner as a viewer first if the add-domain flow skips the TXT prompt.
DNS rule: keep the old token until the new account has verified and dashboards are still visible.
Cache fix: use a private browser window or clear cache after changing user access.
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 is attached to 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.
I treat Postmaster Tools ownership like a DNS-backed access grant, not like 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.
If you need a wider access plan, use a dedicated ownership account or Google group process internally, but still verify the domain from the account that must retain control. For a broader version of this handover pattern, the transfer ownership guide is the related operational playbook.
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 TXT value Google provides.
Choose the owner: pick a durable Google account controlled by the business, not an employee's disposable personal account.
Check current access: note who owns the domain, who has read-only access, and which DNS TXT record belongs to each account.
Remove viewer access: if the new owner is already a read-only user, remove that permission before they add the domain again.
Add the domain: have the new owner open Postmaster Tools and add the same root domain or subdomain that needs ownership.
Publish the token: add the Google TXT record in DNS exactly as shown, then wait for DNS propagation.
Verify and confirm: complete verification from the new account and confirm the domain appears as verified.
Clean up later: remove old read-only 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 leave everyone dependent on cached access or old sessions. Keep the old token until the new owner has completed verification and signed back in successfully.
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
The most confusing case happens when the replacement account was already added as a read-only user. They try to add the domain, but Postmaster Tools simply puts the domain back in their account without showing a new DNS TXT record. That usually means the account is still being recognized through the old share path.
The practical fix is to remove that account as a read-only user from the current owner's side, sign out of Google, clear the browser cache or use a private window, then try adding the domain again. Give the system time to refresh user access. A few minutes is not always enough for the UI state to reset cleanly.
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 session: the future owner should sign out, clear cache, or use a private window.
Try again: the future owner should add the domain again and look for a new TXT record.
Wait briefly: allow a short refresh window if permissions were just changed.
Verify DNS: confirm the TXT record resolves publicly before assuming Postmaster Tools is stuck.
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, the job is not finished. Postmaster Tools is Gmail-specific, and a domain transfer can expose older gaps in authentication, DNS ownership, or sending infrastructure. I check the domain's public records immediately, especially DMARC, SPF, DKIM, MX, and the Google verification TXT record.
A quick domain health check helps confirm that the domain is still publishing the records you expect. This is useful after a DNS admin edits the zone for verification because small DNS changes often reveal unrelated record drift.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
I also send a real message to Gmail and inspect authentication results with an email test. That confirms the sending path still passes authentication after the access change, which is more useful than checking DNS alone.
This is where Suped's product is useful beside Postmaster Tools. Postmaster Tools shows Gmail reputation and compliance signals, while Suped adds DMARC monitoring, automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, and multi-tenant reporting for agencies and MSPs.
For teams that need more than a Gmail dashboard, Suped is the best overall DMARC platform to pair with the handover because it turns authentication data into concrete fixes. Use DMARC monitoring after the transfer to make sure the new owner sees the same sending sources, failures, and policy progress that the old owner managed.
Access models and DNS choices
Different ownership situations call for different DNS choices. The key is to avoid treating one Google TXT token as a shared password. Each owner account should have its own verification token while it needs durable ownership.
Situation
Best action
Main risk
Employee handover
New owner verifies first
Lost access
Agency handover
Client owns DNS token
Vendor lock-in
Read-only viewer
Remove, then verify
No TXT prompt
Root and subdomain
Verify each needed name
Missing data
Common Postmaster Tools ownership situations
Keep the DNS change limited. A Google verification TXT record at the root domain should not require changing SPF, DKIM, DMARC, MX, or tracking CNAMEs. If a DNS provider asks you to replace an existing TXT record instead of adding another value, stop and check the interface. Domains often have several TXT values at the same host name.
For DMARC, a Postmaster Tools ownership change should not force a policy change. Keep the existing DMARC record stable unless the handover is part of a broader authentication cleanup.
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. The hard cases involve missing people, mismatched domains, or confusion between a root domain and a sending subdomain. Work through the exact domain name before changing anything.
Root domains: if you verify example.com but send from mail.example.com, check which name Postmaster Tools expects for the data you need.
Subdomains: verify a subdomain separately when reporting, access, or client ownership is intentionally separated.
Previous owner gone: recover through 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 delay: newly verified domains still need Gmail traffic before reputation and compliance 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 after a sending-domain transition. If DNS ownership, sending vendors, or IP pools change at the same time as Postmaster Tools ownership, keep an eye on 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.
Treating browser cache as proof of failure wastes time after user permissions are changed.
Expert tips
Have the new owner use a clean browser session after their read-only access is removed.
Keep both verification tokens temporarily when two account owners need independent access.
Check DNS resolution directly before assuming Postmaster Tools has an internal delay 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
The clean handover
The answer is simple once the access model is clear: you do not re-assign a Google Postmaster Tools owner by editing a role. You create a new verified owner by verifying the same domain from the replacement Google account.
For a smooth handover, keep the old owner active, remove the future owner from read-only access if needed, have the new account request and publish its own TXT record, verify, then clean up old shares and stale tokens. After that, check DNS health, send a test message, and monitor Gmail data alongside DMARC reporting.
Best default: new owner verifies first, old owner is removed last.
Best account: a durable business-controlled Google account with documented DNS access.
Best follow-up: use Suped to monitor authentication failures, sending sources, blocklist or blacklist changes, and policy progress after the change.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
