Google has announced that Gmail will remove Send as for third-party accounts in January 2027. The same deadline kills Gmailify and web-based POP fetching for existing users. The three features formed a quiet bridge between Gmail’s interface and email identities hosted somewhere else.
That bridge let a person receive mail for a custom domain, reply through the domain’s SMTP server, and keep Gmail as the working surface. A school address, tiny-business domain, old ISP mailbox, community organisation, family domain, Yahoo account, or Hotmail account could live behind one familiar inbox. Google now wants those identities hosted by Google, handled in a separate provider interface, or moved into another mail client.
three removals close the loop
The new Gmail support notice joins three deprecations under one deadline.
Send as currently allows Gmail to submit outgoing mail through a third-party SMTP server while presenting the address that the user owns. Google’s existing setup guide supports up to 99 addresses and explicitly documents work, school, business-domain, Yahoo, and Outlook identities. That path disappears from Gmail on the web and in its mobile apps.
Check mail from other accounts lets Gmail poll external mailboxes through POP and import messages into the main account. New configurations were already restricted after the first quarter of 2026. Existing configurations survive until January.
Gmailify applies Gmail’s spam filtering, inbox categories, search, and notifications to selected third-party mailboxes. It dies with POP fetching.
Together, those features supplied both directions of a unified inbox. POP brought outside mail in. Gmailify processed it. Send as pushed replies back through the identity’s own server. Remove all three and forwarding becomes a receive-only workaround. The reply path breaks unless the user switches interfaces or migrates the domain.
the protocol still works outside the product
Email itself has not lost SMTP, IMAP, or POP. Google says third-party clients such as Thunderbird, Apple Mail, and Outlook can keep accessing Gmail. Dedicated clients can also connect directly to outside providers. Gmail’s mobile app will continue adding third-party accounts through IMAP.
The boundary is Gmail as a hosted web application. Google is withdrawing its server-side role as a client of other mail systems while preserving routes that bring users into Google-hosted identity or push aggregation onto local software.
The security explanation is thin. Google says the features demand disproportionate maintenance resources and recommends official provider apps, desktop clients, Gmail mobile, or Google Workspace. Third-party replacement services receive a warning because they may need credentials or OAuth tokens. Fair enough. Mail account aggregation carries ugly authentication, certificate, abuse, and support burdens.
Send as already required an authenticated SMTP server with SSL or TLS for normal configurations. Its removal reaches beyond old POP polling and weak account passwords. Google is deleting the modern outbound bridge too. The package looks like product simplification with a convenient commercial exit.
forwarding preserves delivery and fractures identity
Google recommends automatic forwarding for people who want outside messages to keep arriving in Gmail. That preserves the visible inbox, but it does not preserve the system.
Forwarding creates a copy. It does not synchronize read state, folders, deletions, or server-side actions with the source mailbox. Historical mail stays wherever it already lives. Delivery can also become brittle when forwarding crosses modern authentication rules. The original sender’s SPF authorization does not automatically bless the forwarding server, and broken DKIM signatures or missing ARC handling can turn a routine relay into spam-folder archaeology.
The larger failure appears at reply time. An incoming message can land in Gmail under person@small-domain.example. After Send as disappears, a reply composed in Gmail comes from the user’s Google identity unless another application handles the outside SMTP account. The conversation crosses an identity seam that the old setup hid.
A migration guide from LiveAgent maps the practical choices: provider forwarding, a desktop client, Gmail mobile, or a full migration. A TidBITS operator discussion shows the messy reality behind that neat list: long-lived family domains, small hosting accounts, forwarding concerns, local Mail rules, and people moving aggregation back to desktop software.
This is how platform power usually lands. A feature page changes. Thousands of private arrangements become migration projects.
the webmail client became the identity landlord
Gmail won by making email search, spam control, storage, threading, and browser access feel dramatically better than the alternatives. Its ability to absorb outside accounts strengthened that position. Users could keep a portable domain or legacy address while outsourcing the daily interface to Google.
That arrangement looked like interoperability. It also trained users to treat Gmail as the permanent home and their domain host as a replaceable pipe. Once the interface owns years of history, filters, labels, contacts, search habits, and muscle memory, removing the pipe does not create a neutral choice. It creates a conversion funnel.
Google Workspace is the cleanest migration for a custom domain because it restores the integrated experience. It also changes the relationship. The domain owner moves mail hosting, administration, billing, retention, and account recovery into Google’s stack. Address portability survives at the DNS layer. Operational independence shrinks.
Desktop clients preserve the healthier architecture. Each account remains a peer. The client talks IMAP and SMTP, stores local state, and can be replaced without moving the domain. That model is older, less fashionable, and structurally better. The client works for the user. A hosted webmail service has its own account system to defend and expand.
open protocols need clients willing to use them
Email remains one of the internet’s great interoperable systems. Anyone can host a domain, publish MX records, sign messages with DKIM, enforce DMARC, and exchange mail across providers. Protocol survival alone does not guarantee usable interoperability.
People experience protocols through products. When the dominant product drops a bridge, the protocol still exists while practical access contracts. The surviving choices demand more software, more account switching, more administration, or another monthly bill. Standards can remain open while the popular interface becomes a walled garden one deprecation at a time.
Google gave users five months to move. That is adequate notice for a feature retirement and a brutal deadline for anyone who discovers the dependency when the first January reply leaves from the wrong address.