Gmail Send As Alternative for Custom Domain
Put every mailbox on one board and let AI categorize and de-spam each message.
Gmail removes Send as for third party accounts in January 2027, so a business address at your own domain can no longer borrow the Gmail compose window. The replacement is a mail client that connects the mailbox directly over IMAP and SMTP, which sends from the real address rather than relabeling a Gmail message. Forwarding keeps the mail arriving but does not fix the reply address, and Google own support page names an IMAP and SMTP client as one of the three alternatives.
Most people meet this change from the receiving side, because the setting labeled check mail from other accounts is the one they remember switching on. For a business the sending side is the expensive half. If quotes, invoices and client replies have been leaving Gmail wearing your domain address for the last few years, that arrangement has a date on it now.
What exactly is being removed
Google is retiring three connected features together. Send as for third party accounts, which let you pick an outside address in the From field. Gmailify, which applied Gmail spam filtering and inbox categories to an outside mailbox. And POP fetching from third party accounts, the setting most people call check mail from other accounts.
The published timeline runs in three stages. A notice period began in the third quarter of 2026, with an in product notification to affected users. Through a transition period into the fourth quarter of 2026 the features keep working, but Gmail may restrict new configurations. In January 2027 all three are fully removed.
Two details are worth pinning down because a lot of secondhand coverage gets them wrong. First, several widely shared articles give the removal date as January 2026; Google support documentation gives January 2027. Second, this is not Gmail closing itself off to other software. Google states that if you use a third party email client your experience is unchanged, and that IMAP and SMTP remain fully supported for accessing Gmail from other apps. The feature being withdrawn is Gmail acting as a collector and a mask for other people mailboxes, not the protocols underneath.
Mail you have already imported stays put. Google is specific that messages pulled into your Gmail mailbox remain there, and that the change affects sending as and syncing from that point forward.
Why forwarding does not replace Send as
The advice you will see most often is to switch on forwarding at your domain host and carry on. That half works. Incoming mail keeps landing in Gmail with no more configuration, and it costs nothing.
Then a customer replies to a quote and the message goes out from yourname at gmail dot com. That is the whole problem in one line. Forwarding is a one way pipe: it moves mail toward you and has nothing to say about what leaves. Send as was the piece that made the return trip look right, and it is the piece being removed.
For a sole trader emailing three people a week it may not matter much. For anyone invoicing, quoting or handling client work it matters immediately, and in a specific way. Replies from a personal address get filtered more aggressively, they break the thread a client filed under your company name, and they quietly undercut the domain you paid for. A payment request that arrives from a gmail.com address is also exactly the shape of the invoice fraud every finance team is trained to look out for, so the practical cost is not just presentation.
The four honest replacements
| Route | Sends from your domain | Everything in one place | What it costs |
|---|---|---|---|
| IMAP and SMTP mail client | Yes, the mailbox sends as itself | Yes, all accounts on one board | Nothing, up to a paid client |
| Forwarding into Gmail | No, replies are your Gmail address | Yes | No license fee |
| Your host own webmail | Yes | No, a separate tab per mailbox | Usually included with hosting |
| Google Workspace on your domain | Yes, it becomes a Google mailbox | Yes, within Google | From 7 dollars per user per month, billed annually |
Those are the real options, and which one is right depends on a question worth answering honestly before you spend anything: how many mailboxes are actually in play?
One domain mailbox and nothing else. Move to Google Workspace on your own domain, or just use your host webmail. Workspace turns the address into a proper Google mailbox, so Send as becomes irrelevant, and the Starter tier is 7 dollars per user per month on the annual commitment. If the whole business is one address, this is the least disruptive path and you keep the Gmail interface you already know.
A domain mailbox plus two or three others. This is where a client earns its place. Workspace only tidies the addresses you move into it, and moving an old Yahoo or AOL address is usually not on the table because it is attached to a decade of accounts. A client connects them all where they already live.
Mailboxes you do not control. If a supplier or a client gave you an address on their system, a client is the only route, because you cannot migrate a mailbox that is not yours.
How the client route actually works
Instead of asking Gmail to collect and relabel, you point software at each mailbox directly. IMAP reads the mail and leaves it on the server it arrived at. SMTP sends through that same provider, so the message genuinely originates from your domain address with your domain authentication behind it. Nothing is being spoofed or relabeled, which is why this survives a change that Send as does not.
The practical work is small. For each mailbox you need the server names and a credential. Most providers no longer accept your ordinary password from third party software and issue a generated app password instead, which you paste in once and can revoke later without touching your real password. If that step is new, we wrote up what an app password is and how to create one. A mailbox at your own domain is usually the easy one, because it typically still takes the normal mailbox password from your hosting control panel and the servers are commonly mail dot yourdomain on port 993 for IMAP and 465 or 587 for SMTP.
Gmail itself becomes one more account in that list. Google is explicit that IMAP and SMTP access to Gmail is unaffected, so the mailbox you are moving away from as a collector stays exactly where it is as a mailbox. Nothing is exported, nothing is deleted, and you can run the old fetch setting alongside the new client until it switches off by itself.
The one category that will not connect this way is Microsoft. Hotmail, Live, Outlook.com and Microsoft 365 require OAuth, so a client that has not implemented it cannot hold those mailboxes, and it is worth checking your list for one before you commit to a tool. Our IMAP email client page goes through what the protocol does and does not give you.
Choosing between the clients
Thunderbird carries no license fee, merges accounts through Unified Folders, and runs on Windows, macOS and Linux. It is the default recommendation for a reason and it will do this job. The catch is that it installs per machine, there is no ChromeOS build, and the interface is closer to 2010 than most people want in front of them all day.
eM Client is the polished Windows and macOS option, at 39.95 dollars a year for the Personal subscription or 59.95 dollars once for a single device on the version you buy. Those are the US prices; its euro price list is cheaper. It is genuinely good software with a real unified inbox, and the limitation is the same as Thunderbird plus a price: two platforms, per device, and nothing for Chromebooks or Linux.
A browser based client trades the native application feel for running anywhere, which matters more than it sounds if you work across a laptop, a locked down office machine and a Chromebook. It is also the only category that needs no install permission, which is the usual blocker on a work computer. That is the shape of what we build: connect Gmail, Yahoo, AOL, iCloud, Zoho, Fastmail and your own domain with app passwords, see them on one board, and reply from whichever address the sender wrote to.
Do this before January 2027, not on the day
There is no emergency. There is one good reason not to leave it: Gmail may restrict new configurations during the transition period, so the ability to set things up the old way closes before the feature does. If you need to add another address to the current arrangement, that window is the one shrinking.
A sensible order of work. Open Gmail settings and list every address under both check mail from other accounts and send mail as, because most people are wrong about how many there are. Decide per address whether it moves to Workspace or into a client. Generate the app passwords. Add the mailboxes, including Gmail, and leave the old fetch running in parallel. Send one test message from each address and confirm it arrives showing the right sender, since outgoing mail fails separately from incoming. Then let January 2027 arrive without it being an event.
One thing that tends to surface during this exercise: a business mailbox is not only correspondence. Supplier invoices and receipts land there too, and once they are no longer buried under a personal Gmail they turn out to be the next bottleneck, since pulling the numbers off supplier receipts by hand is its own weekly job. Worth noticing while you have the mailbox open.
The full comparison of every replacement route, including the dated timeline in Google own terms and which providers connect, is on our check mail from other accounts replacement page. If your other mailbox is a Gmail address and you want the server values, the IMAP settings for Gmail, Outlook, Yahoo and iCloud are collected in one table.