Audit Gmail Third-Party Send-As Workflows Before January 2027
The risky part is not replacing a button. It is finding every sender identity, reply path, delegated user, and automation that assumed Gmail could relay a third-party address.
- Written by
- Marketing Wiki Research Automation
- Review status
- Not independently reviewed
- Published
- Updated
- Evidence checked
- Sources
- 4
Inventory consumer Gmail third-party Send-as dependencies, separate unaffected Workspace aliases, and migrate reply, authentication, and approval paths with received-message tests.
Inventory every consumer Gmail workflow that sends from a non-Gmail, non-Workspace address, then migrate the sender, reply handling, delegation, and archive path together. Do not assume the replacement is complete because a new compose screen can send one test.
Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Sources were refreshed on September 5, 2026.
Google's third-party account change notice says the announcement and notice period begins in Q3 2026 and consumer Gmail's third-party Send as feature ends in January 2027. The notice distinguishes this from Gmail-to-Gmail aliases and Google Workspace aliases, which are not affected by this specific retirement.
Scope first. A rushed migration can move unaffected Workspace aliases or miss a shared consumer Gmail account that quietly relays several business identities.
Classify each identity#
| Current pattern | In stated retirement scope? | Next check |
|---|---|---|
| Consumer Gmail sending as Outlook, Yahoo, ISP, or custom third-party mailbox | Yes, according to Google's notice | Identify native provider and approved client |
| Consumer Gmail sending as another Gmail address | No, not by this specific change | Verify ownership and current alias settings |
| Google Workspace user sending as a Workspace alias | No, not by this specific change | Confirm administrator policy |
| ESP campaign using a verified domain | Different system | Confirm sender authentication and reply path |
| Helpdesk or CRM using Gmail API/SMTP | Do not infer | Check the integration contract separately |
Record the account type and source of truth. The words “Gmail” and “alias” are not enough to classify the dependency.
Build the dependency inventory#
For every affected address, capture:
- visible From name and address;
- authentication method and credential owner;
- reply-to address and where replies arrive;
- sent-message archive location;
- signatures, templates, and canned replies;
- delegates and mobile users;
- filters, labels, forwarding, and retention;
- CRM, calendar, helpdesk, and automation links;
- daily message type and volume;
- legal or customer-service owner.
Do not copy passwords into the inventory. Reference the approved secret or identity record.
Choose the replacement by job#
Use the third-party provider's native web or mobile app when the work is human mailbox correspondence. Use a managed desktop or mobile client when people need several mailboxes in one interface. Use a campaign or transactional platform when the work is permission-based bulk or automated email with audience, suppression, scheduling, and event requirements.
Migma's export documentation separates sending in Migma from handing reviewed HTML to another marketing platform. Its campaign documentation includes sender, verified domain, reply-to, audience, test, schedule, and tracking fields. That is useful when a team had been using Gmail as an informal campaign sender. It does not replace a shared support inbox or one-to-one correspondence workflow.
Run a received-message acceptance test#
Send only to controlled accounts. For each new path, inspect:
| Surface | Acceptance evidence |
|---|---|
| Compose | Correct From choices; no unauthorized identity |
| Received headers | Expected SPF, DKIM, and DMARC alignment for the path |
| Display | Correct friendly name and address in target clients |
| Reply | Reply reaches monitored mailbox and creates expected ticket or thread |
| Archive | Sent copy appears in approved system with searchable identifier |
| Mobile | Authorized user can send and reply without hidden old account |
| Delegation | Former and current delegates have expected access |
| Failure | Authentication rejection is visible and actionable |
Preserve the original message source, timestamp, and Message-ID. A screenshot of the inbox row does not prove the authentication or reply route.
Migrate in cohorts#
Start with one low-risk address and one user. Keep the old route available only during a defined rollback window. Then move shared identities, mobile users, and integrations. Notify people before the visible From picker changes; otherwise they may choose a personal or default address by mistake.
Freeze changes to signatures and routing during the cohort. Comparing too many moving parts makes failures hard to attribute.
Stop conditions#
Stop when the account classification is uncertain, replies land in an unmonitored mailbox, received authentication differs from the approved design, sent records are missing, a delegate gains broader access, a compliance footer or unsubscribe path disappears, or an automation still uses the old credential.
Retirement record#
identity: "support@example.com"
current_account_type: "consumer-gmail-third-party-send-as"
replacement_job: "shared-human-correspondence"
replacement_system: "provider-native-shared-mailbox"
reply_test_message_id: "<recorded-id>"
authentication_result: "reviewed received headers"
archive_verified: true
delegates_reviewed: true
old_route_disable_on: "2026-11-15"
owner: "named mail administrator"
Evidence limits#
Marketing Wiki did not inspect an in-product Google notice or test an account. The January 2027 date and exception scope come from Google's current help pages. Google can update transition details. Confirm the visible account state and current administrator guidance before disabling a working route.
Sources behind this page
Claims remain tied to dated source review. Method and corrections stay public.