You added your domain to the OAuth consent screen. Google says it is not verified. You open Search Console and the domain is sitting right there — verified, green tick, has been for years. Nothing you change in the Cloud Console moves the answer.
In most of these cases the domain is not the problem. The problem is the type of Search Console property the verification lives in, and the shortcut method that property type let you use.
What Google actually asks for
Two separate rules are in play, and they are published in two different places, which is a large part of why teams miss the second one.
That is the rule most people find. The second rule lives in Google’s OAuth remediation guidance, and it is far more specific about how the verification has to exist:
Read that carefully, because the distinction is easy to overstate. Google instructs you to use a Domain property. Google does not publish a statement anywhere saying a URL-prefix property is rejected. So the honest position is this: a Domain property is the configuration Google’s own remediation path names, and if your verification is anything else, you are arguing against the instruction sheet the reviewer is working from.
The two property types are not interchangeable
| URL-prefix property | Domain property | |
|---|---|---|
| Coverage | “Includes only URLs with the specified prefix, including the protocol (http/https).” | “Includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp).” |
| Verification methods | “Many possible methods” — HTML file upload, HTML tag, Google Analytics, Tag Manager, or DNS. | “DNS record verification only.” |
| Named in Google’s OAuth guide | No | Yes |
The consequence is the part that catches teams out. Google states plainly, method by method, that HTML file upload, the HTML meta tag, the Google Analytics tracking code and Google Tag Manager each “can be used for URL-prefix properties, but not Domain properties.” Every fast, no-DNS-access way of proving ownership produces exactly the property type the OAuth guide tells you not to rely on.
There is one useful asymmetry: Google notes that if you use the domain-name-provider method on a URL-prefix property, “you will also be auto-verified for the Domain property.” Which means the fix is always DNS — there is no path to a Domain property that avoids the registrar.
Where this turns into a real blocker
The DNS zone is not yours to edit
A Domain property can only be verified with a DNS record — and Google is explicit that you choose “between a TXT record and a CNAME record depending on how your site is configured.” If DNS sits with a client, an agency, a registrar reseller or a departed contractor, the OAuth submission is now blocked on an access problem, not a code problem.
Ordering is not cosmetic
Google’s branding documentation instructs you to “add your Authorized Domains before you add your redirect or origin URIs, your homepage URL, your terms of service URL, or your privacy policy URL.” Teams almost always do it in the opposite order, then spend the afternoon fighting a console that rejects entries for no visible reason.
Every URL in the project counts
The authorized domains list must cover the top private domains behind the app home page, privacy policy and terms of service — and “the redirect URIs and/or JavaScript origins authorized in your ‘Web application’ OAuth client types.” A single staging callback on a forgotten domain is enough to fail the check.
Public suffixes are refused outright
Search Console states it does not support “domain-property verification of public suffixes.” If your app lives on a platform subdomain that sits on the Public Suffix List, there is no Domain property to create, and the authorized-domain route as documented is simply unavailable to you.
The account behind the record matters
Whose Google account holds the verification is a separate failure mode from the property type, and it is the one covered in detail on why app name, logo and homepage get rejected. Worth noting: Google’s own pages disagree with each other here — the developer documentation says owner or editor on the Cloud project, while the remediation guide says Project Owner. Assume the stricter reading.
DNS is not instant, and it can lapse
Google warns that “it can take up to two or three days for your provider to start serving the record.” It also means a registrar migration, a nameserver change or a zone rebuild can silently drop the record long after verification passed — and nothing tells you until the next submission.
The ceiling nobody plans for: ten domains
Two separate published limits converge on the same number, and multi-brand or white-label products hit both.
If your product signs customers in on their own vanity domains, this is an architecture decision disguised as a console limit, and it is much cheaper to discover before the eleventh customer than after.
How the work is actually sequenced
Inventory every URL the project touches
Home page, privacy policy, terms of service, every redirect URI and every JavaScript origin across every OAuth client in the project — including the staging and legacy ones nobody has looked at in a year.
Collapse that list to top private domains
The list that matters is not the URLs, it is the registrable domains behind them. This is where the ten-domain arithmetic gets done, and where an architecture problem surfaces if there is one.
Establish DNS-level ownership under the correct account
A Domain property, verified with a DNS record, held by a Google account with the right role on the Cloud project. Two independent conditions, both of which have to be true at the same time.
Register domains first, then the URLs
Following Google’s stated order removes an entire class of console rejections that otherwise look like bugs.
Reconcile branding state, then re-open the review
Google’s branding page distinguishes draft branding from published branding, and states that “compliant verification results are valid for 7 days” before the status reverts to needing re-verification. If a submission was already rejected, Google’s guidance is to reply to the email from the OAuth verification team — fixing the DNS alone does not restart anything.
Why these submissions stall
- Verified — but as a URL-prefix property. The green tick in Search Console is real. It is just not the property type Google’s OAuth guidance names.
- Verified with a method that cannot back a Domain property. HTML file, meta tag, Analytics and Tag Manager all work in Search Console and all dead-end here.
- Verified by the wrong Google account. Personal account verified it years ago; the Cloud project is owned by a workspace account. Google does not reconcile the two for you.
- The URLs went in before the domains. Console rejections that look inexplicable are frequently just the documented ordering rule.
- A forgotten redirect URI on an eleventh domain. Counted by second-level domain, whether or not the endpoint is still live.
- DNS control sits outside the engineering team. The technical fix is five minutes. Getting registrar access can take three weeks.
- The record lapsed after a migration. Verification is not permanent — it is a DNS record, and DNS records get rebuilt.
Where this sits in the wider review
Domain verification is a precondition, not the review itself. Passing it puts you back in the queue for brand verification and, separately, for the sensitive and restricted scope review — which is a different set of evidence with a different failure profile. Teams that fix the DNS and assume they are finished usually are not.
If you would rather have the whole chain audited and submitted properly than work through it in stages, that is what the Google API verification service covers.
An honest note. Google reviews and approves applications independently. No consultant controls that decision, and no specific outcome or timeline can be promised. What can be controlled is that the configuration matches Google’s published requirements and that the evidence is what a reviewer expects — which is what removes the avoidable rejections. This is technical implementation and submission support, and it is not affiliated with or endorsed by Google LLC.
Sources: Google — OAuth API Verification FAQs / Domain Verification quick reference (support.google.com/cloud/answer/13804266), Manage OAuth App Branding (answer/15549049), Verification requirements (answer/13464321), Domain Limit Exceeded FAQ (answer/7650096), Brand Verification (developers.google.com/identity/protocols/oauth2/production-readiness/brand-verification, last updated 22 March 2026), Search Console property types (support.google.com/webmasters/answer/34592) and Verify your site ownership (answer/9008080). Reviewed August 2026. Google’s documentation changes; verify against the current pages before acting. Note that Google’s own pages currently disagree on whether an Editor or only a Project Owner may hold the verification.