Google Ads Locks Sensitive Actions to Corporate Email

Google Ads is piloting a corporate email requirement for sensitive actions: logins on free email domains — @gmail.com and @yahoo.com are the two Google names — will be blocked from account linking updates and user access changes, and prompted to move to a corporate domain. Reporting and routine campaign edits are named as exceptions. The help doc puts no date on any of it, and Google’s own documentation disagrees with itself on the approval threshold that sits behind the block.

Running client accounts from a personal Gmail is a common default for freelancers and small agencies — Google publishes no figure for how common, and neither will we — and it is precisely that seat which loses the ability to add a user or change a role. The campaign work carries on. The administrative work stops.

This guide covers exactly what the pilot blocks and what it leaves alone, why this is better understood as Google withdrawing an opt-in control than inventing a new rule, the contradiction between two Google help docs on the Multi-Party Approval threshold, the compounding lead time a migration actually takes, and a plan by account shape. Every claim below is labelled vendor-confirmed, reported-only, community-observed or our analysis.

Google’s help doc, “About email domain requirements for performing sensitive actions in Google Ads,” states that users accessing Google Ads via free domain email addresses such as @gmail.com or @yahoo.com “will be blocked from completing sensitive actions and must transition to a corporate email domain.” The stated rationale is “to enhance account security and minimize the impact of unauthorized access.” All of this is vendor-confirmed on the primary help doc, and the same notice is duplicated on Google’s separate passkey documentation — two Google pages carrying it, which is decent corroboration that this is a real programme rather than a stray draft.

Google’s definition of a free domain is deliberately definitional rather than a list: “an address provided by a public, non-corporate email service where any individual can sign up for an account without proving ownership of a specific business, domain, or organization.” The stated deficiency is administrative, not technical — free domains “lack central administrative oversight and domain-level ownership verification.” Only @gmail.com and @yahoo.com are named on the page. We are not going to extrapolate the rest of a blocklist from a definition, and neither should you.

The distinction matters operationally. A dated requirement gives you a deadline to plan against. An undated pilot with email-triggered enrolment gives you an unknown amount of notice, which is a harder planning problem — you cannot schedule the work, so the only safe posture is to be ready before the email arrives. That asymmetry is the single strongest argument for migrating a seat you do not yet have to migrate.

The framing in most coverage is that Google is imposing a new domain requirement. That is not quite what happened. Google has shipped domain restriction as an advertiser-controlled setting for years. “Allowed Email Domains” is an account security setting that, in Google’s words, “enables you to control which email domains can be added to your Google Ads account,” and only users with Admin access can configure it. At manager-account level, Manager Account Security Mandates let an MCC admin enforce “minimum security settings … on all current and future sub-accounts that a manager account has administrative ownership over,” including an Allowed Domains setting.

The clinching detail is Google’s own worked example for the opt-in feature, which excludes Gmail explicitly and by name. Read it, then read the pilot description again.

That is the pilot’s behaviour, described in documentation that predates it, as something an advertiser chooses. Our reading: the story is not “Google invents a domain rule,” it is “Google gives up on advertisers turning the domain rule on themselves.” Google publishes no adoption figure for Allowed Email Domains, so we cannot tell you how many accounts enabled it — but a platform does not usually take a setting out of your hands when the voluntary version is working.

There is a second, sharper contrast buried in the mandate documentation. When Google built the tooling for advertisers to enforce security on their own sub-accounts, it gave them a grace period: the Authentication mandate requiring 2-Step Verification or Advanced Protection carries an effective date that “defaults to 7 days in the future,” and applying a mandate notifies owned sub-account admins by email and by in-product banner. The pilot ships with no published grace period at all. Google gave advertisers more structured notice for a change they chose than it has published for one it is making for them.

Google Ads has five access levels — Email-only, Billing, Read-only, Standard and Admin — and publishes a capability matrix showing which level grants what. Cross-reference the pilot’s two named actions against that matrix and a pattern appears: both named actions sit on rows that only Admin access grants. Standard access already cannot change user access, accept a manager link or add product links. That mapping is our reading of Google’s published access-level table, not something Google states.

The practical consequence, again as our analysis: a free-domain Admin under the pilot keeps the Admin badge and every Standard-tier capability, but loses the linking and user-management powers that make Admin worth having. It is a silent partial demotion — Admin in name, Standard-plus in practice. The table below maps the agency-relevant capability rows against what the pilot names, and it is deliberately generous with “unclear,” because Google says its list is non-exhaustive.

Read the “unclear” column as the real finding rather than a hedge. Google names two actions and then tells you the list is non-exhaustive and subject to change without prior notice. Any inventory of what breaks is therefore a snapshot with an expiry date nobody has published, which is why the migration advice in section 08 is about seats and roles rather than about specific buttons.

Multi-Party Approval is the second mechanism in play. Google describes it as protecting “your account from unauthorized activity by requiring a second account administrator to verify sensitive changes.” The question every agency needs answered is simple: at how many administrators does it switch on? Google answers it twice, and the two answers are not the same rule.

The email-domain doc’s FAQ states that “if your Google Ads account currently has 3 or more active administrators, inviting a new user or modifying administrator privileges will trigger Multi-Party Approval (MPA).” The dedicated Multi-party approval help doc states that “multi-party approval is only applicable for accounts with more than 3 administrators.” Three or more is not the same as more than three. An account with exactly three administrators is caught by one document and exempt by the other — and agency lead plus agency ops plus client-side owner is an extremely ordinary way to end up with exactly three.

A third detail on the MPA page makes the threshold section look muddled rather than merely terse. Google states that dropping to a single administrator pauses MPA and cancels all pending requests, and that adding administrators back re-enrols the account automatically — single-admin language that sits oddly next to a stated “more than 3” boundary. Before anyone treats that as an escape route: Google separately warns that single-admin accounts risk losing tag access, and surfaces a Tag Diagnostics notification for exactly that scenario. Demoting your way out of approvals is a bad trade.

The MPA doc also has a second internal inconsistency, and this one you should plan around rather than resolve. In one section it states that since emails are not sent for these approvals, you should check in-product notifications regularly. Further down, the same page carries a section titled “Multi-party Approval Email Notifications and Reminders” with a four-row table — Approval Request, Request Approved, Request Rejected, Pending Reminder — and the line that one reminder email is sent if the MPA is not approved after three days. We are not going to assert that Google does or does not send those emails; the page says both. Operationally: treat in-product notifications as the reliable channel and any email as a bonus.

Two exemptions on the MPA doc are worth holding on to. Read-only roles and API users are exempt from the approval process, which means automated pipelines running through the Google Ads API are not caught by MPA. Multi-party approval reached the API itself in v24.2, announced on the Google Ads Developer Blog on June 24, 2026, with support back-ported to v23.3, v22.2 and v21.2. What Google has not documented anywhere we could find is whether API-driven linking or user management is caught by the email-domain pilot — the MPA doc grants an API exemption, the email-domain doc says nothing about API access at all. We are raising that as an open question, not answering it.

Here is the part that gets missed. Google documents three migration routes on the email-domain doc: an existing Admin invites the corporate address via Admin → Access and security → +; you register a Google Account on an address you already own by choosing “Use my current email address instead”; or you change the login email on an existing Google Account under Personal info → Contact info → Email. All three are quick. What follows them is not.

Google states that a migrated seat needs a new passkey, because “passkeys are specific to each individual Google Account/email address.” And the passkey documentation states that new passkeys take “about one to 2 days to pair with Ads,” with troubleshooting guidance to “wait 48 hours before using your new passkey to authorize sensitive tasks.” A freshly migrated corporate seat therefore cannot perform sensitive actions immediately. Stack an MPA approval on top and the elapsed time compounds. These numbers sit in three unconnected help docs; the ladder below is our assembly of them.

We have deliberately not totalled that column. Google publishes no timing for the first four steps, so any single “total days” figure would be invented. What the ladder does show is the shape of the risk: the only steps Google puts a number on are the ones you do not control. Passkey pairing is Google’s clock. The approval window is your co-admin’s clock. Neither responds to urgency.

The realistic worst case, described qualitatively because that is all the documentation supports: an agency that waits for its enrolment email, then starts the migration, is looking at a day or two of passkey pairing before the new seat can do anything sensitive — and if the account is over the approval threshold and a co-admin is unresponsive or on leave, the request can sit until it expires and has to be restarted. That is a client-onboarding freeze measured in weeks, from a change with no published deadline. If you have not audited who holds Admin on which client account recently, our Google Ads audit checklist is the natural place to add the access-review step.

Line the account-security controls up side by side and the pilot stops looking like a new policy and starts looking like the last step in a sequence. Each row below already exists; the difference between them is who decides and how much notice you get.

The bottom row is the only one where Google both decides and publishes no timeline. That is the honest criticism of this rollout, and it is separable from the merits of the rule itself — which are stronger than the reflexive eye-roll suggests, as the next section argues. It also sits alongside a broader tightening of Google Ads account governance this year; we covered the July bundle in July’s Google Ads account-governance changes, and the same quarter carries the August 17 target-based bidding change.

It is tempting to read a corporate-email requirement as friction for its own sake. The backdrop makes it harder to dismiss. In November 2025, Search Engine Roundtable reported a wave of Google Ads manager account hijackings, relaying an affected advertiser’s public description of an entire MCC taken over overnight, with an unknown administrative user added and the attacker’s own manager account linked to many of the agency’s accounts. That is community-observed reporting relayed by a trade outlet, not a Google-confirmed incident, and we are labelling it as such.

The detail that matters is what did not stop it. In the same report, affected advertisers said they had 2-Step Verification enabled and still lost access, with the suspected vector a phishing email mimicking a legitimate account-access invitation. 2SV protects a sign-in. It does not protect against a user being socially engineered into granting access, and it gives nobody the power to shut down a compromised identity after the fact. Domain ownership does: a corporate domain has an administrator who can suspend the mailbox. Google’s stated deficiency of free domains — that they “lack central administrative oversight and domain-level ownership verification” — is an accurate description of the gap, whatever you think of the delivery.

Now the weak point, and it is self-inflicted. Enrolment in this pilot is announced by email — the exact channel that was being spoofed in the incidents that motivated it. A message reading “your Google Ads access is changing, switch your login domain” is a close to ideal phishing template, and it will now arrive legitimately in inboxes that have been trained to expect it. Google’s own security hub gives you the check: it states that Google “will only contact you from an ‘@google.com’ email domain.” Verify the sending domain, never act on a link inside the message, and navigate to the account directly. Circulate that instruction to your team before the emails start, not after.

Our forward read: the pilot’s scope is the least interesting thing about it. Two named actions plus a non-exhaustive list plus an undated switch-on is the shape of a control that expands quietly. The direction of travel across Google Ads account security this year — passkeys on sensitive actions, multi-party approval in the product and then in the API, manager-level mandates, and now domain requirements — points one way: identity that an organisation can revoke is becoming the price of administrative power on the platform. Agencies that treat a corporate-domain seat as infrastructure rather than a chore will find the next tightening uneventful.

One correction before the plan: “corporate email” does not mean “buy Google Workspace.” Google’s doc explicitly covers registering a Google Account on an address you already own, via “Use my current email address instead” on the account creation page. If you already have hello@example.com on any mail host, you can satisfy this at zero incremental software cost. No Workspace licence is required, and we are printing no price for one.

Two practical notes from the passkey documentation, because they are where migrations stall. Autogenerated passkeys on Android cannot be used to verify sensitive actions in Google Ads at this time, so check what your phone created for you rather than assuming it counts. And one passkey-ready device covers the whole account, provided it has a screen lock — Face ID, Touch ID or a PIN — with Bluetooth on and the two devices within one to two metres of each other during cross-device verification. Supported platforms start at Windows 10, macOS Ventura, ChromeOS 109, Android 9.0 and iOS 16, on Chrome 109, Safari 16, Edge 109 or Firefox 122 and above, or a FIDO2 hardware security key.

If you want the wider quarter in one view, this sits alongside third-party pre-screening for Search Partners and the rest of the Q3 platform deadline calendar, where every entry carries its confirmation status. And if permissions and authority language is your concern more broadly, July’s Google Ads terms update is the adjacent read. For teams that would rather hand the whole access-governance problem to someone else, that is part of what our paid media management engagements own.