Gmail will stop sending as third-party addresses in January 2027

Google has begun the Q3 2026 notice period for a January 2027 retirement of three ways Gmail integrates third-party mailboxes. Personal Gmail users will no longer be able to use the web or mobile Gmail client’s “Send as” feature to send from non-Google addresses, and Gmail on the web will stop Gmailify and POP-based “Check mail from other accounts”. Google says Google Workspace aliases and other Gmail addresses are unaffected, third-party accounts can still be added directly to the Gmail mobile app, Gmail itself remains accessible from external clients through IMAP/POP/API, and forwarding from an outside mailbox into Gmail will continue.

A common low-cost small-business setup uses a custom-domain mailbox or forwarding service behind a personal Gmail account, with Gmail acting as both inbox and outbound client. January’s change breaks the outbound half of that pattern and removes Gmail’s web-side POP aggregation. The migration is operational rather than merely cosmetic: users may need to move the domain to Google Workspace, use the mail provider’s own client, adopt a desktop client that connects to the outside mailbox, or redesign forwarding and reply handling. Teams should avoid unsafe replacement extensions that require broad mailbox credentials or OAuth access.

“Send as” lets a Gmail user configure SMTP credentials for an address hosted outside Google and choose that address in Gmail’s From field. Gmailify and “Check mail from other accounts” let Gmail pull messages from supported outside mailboxes. Google is ending those integrations in January 2027; the change is not a shutdown of Gmail’s own SMTP, IMAP, POP or API access.

Google explicitly says automatic forwarding from a third-party provider into Gmail will keep working, and already imported mail will remain in the Gmail mailbox. That means a forwarding-only custom-domain setup can still receive into Gmail, but it will no longer be able to send from that outside address through Gmail’s third-party “Send as” path. Replies that must preserve the custom-domain identity need another sending client or a Google-hosted identity.

The Gmail mobile app will continue to support adding non-Google accounts directly. That is different from configuring a third-party address as an alternate identity on a Gmail account. Builders and small teams documenting migration options should test the exact account configuration rather than assuming every non-Google address disappears from Gmail.

Google recommends using the outside provider’s own interface, a desktop client with IMAP/SMTP, the Gmail mobile app for direct third-party accounts, or Google Workspace for custom domains. Moving to Workspace can preserve a Gmail-native experience but introduces a paid hosted-mail dependency; using a desktop or provider client keeps the mailbox elsewhere but changes the user workflow.

Google warns that extensions or services promising to recreate “Send as” may request mailbox credentials or OAuth tokens. Teams should treat those as privileged email integrations: inspect scopes, credential storage, revocation, account recovery and provider reputation before using one to preserve an old convenience feature.