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

Google’s current migration guidance now makes part of the transition more concrete. Gmail’s dedicated Gmailify/POP notice says new users have not been able to start those integrations since after Q1 2026, while existing users can keep them until the January 2027 shutdown. The broader January 2027 retirement remains unchanged: personal Gmail will stop third-party “Send as”, Gmailify and web POP fetching, while Google Workspace aliases, direct third-party accounts in the Gmail mobile app, forwarding into Gmail, and external-client access to Gmail remain available.

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.