Gmail is ending “Send mail as” in January 2027: what to do with your support@ address

If you answer support@yourproduct.com from a personal Gmail account using “Send mail as”, that setup has an end date. Google’s help page for the feature now says:

“Starting January 2027, Gmail will no longer support the ‘Send as’ feature for third-party email addresses.”

It adds: “This change does not affect Google Workspace aliases or other Gmail addresses you own.” (Gmail Help: Send emails from a different address or alias)

Two related features are going too. Gmailify, and fetching mail from other accounts over POP, stopped accepting new users after the first quarter of 2026. Google says “Existing users can still use the feature until January 2027.” (Gmail Help: upcoming changes to Gmailify & POP)

This post covers who’s affected, what stops working, and the realistic options for a branded support address.

The timeline

Google’s page on the change sets out three stages (Gmail Help: changes to third-party email account support):

• Q3 2026: “‘Send as’ announcement and notice period begins. All affected users will receive an in-product notification.”
• Transition period: “‘Send as’ for third-party accounts, Gmailify, and POP continue to work, but Gmail may restrict new configurations.”
• January 2027: “Gmail will fully remove ‘Send as’ for third-party accounts, Gmailify, and POP.”

We’re in the transition period now. Existing setups keep working, but if you were planning to add another product’s address to Gmail, Google may not let you.

Who’s affected

You’re affected if Gmail sends mail for you from an address that isn’t a Google address. The common support setup looks like this: mail to support@yourproduct.com is forwarded to your Gmail, and you reply from support@ by picking it in Gmail’s From menu. Every product you’ve set up that way is affected.

You’re not affected if the extra address is another Gmail address or a Google Workspace alias. Google states: “Gmail-to-Gmail aliases and Google Workspace ‘Send as’ functionality is not affected.”

You’re also affected if you use Gmail’s “Check mail from other accounts” to pull support mail in over POP, or use Gmailify on a linked account.

What stops working, and what doesn’t

From January 2027, in Google’s words: “You will no longer be able to send mail from third-party email accounts in Gmail on the web or in the Gmail mobile apps.” POP fetching and Gmailify end at the same time.

Several things keep working, and Google lists them:

• Forwarding into Gmail. “You can configure your third-party provider to auto-forward messages to your Gmail address.” So customers’ messages can still reach your Gmail.
• The Gmail mobile app. “You can continue to add and use non-Google accounts in the Gmail mobile app as you do today.”
• Mail you already have. Messages synced before the change stay in Gmail.

The practical effect for support: mail to support@ can still arrive in your Gmail inbox, but replies sent from Gmail on the web will come from your Gmail address, not support@. That’s the part to fix before January.

Your options

There’s no single right answer. It depends on how many products you run and how much support mail you get. Here are the options, including the ones Google suggests.

1. Send from your mail provider’s own app or website

If support@ already lives at a provider that hosts mailboxes, reply from that provider’s web app or mobile app instead of Gmail. Google suggests exactly this. It works and costs nothing extra, but support then lives in a second place, and with several products, several places.

2. A desktop mail client

Google also suggests a desktop client: “Configure a desktop client to connect to your third-party account via IMAP/SMTP to manage multiple accounts in one place.” That brings everything together on one computer. You still need a provider with IMAP and SMTP for each address, and the setup doesn’t follow you to your phone or to a teammate.

3. Google Workspace or another mailbox provider

Google’s page also suggests that businesses “Use Google Workspace for a custom domain.” Workspace aliases keep working with “Send as”, so if you’re happy paying for Workspace, it’s the smallest change. Other providers sell mailboxes on your own domain too. Either way you get a proper mailbox with DKIM signing. The trade-off is cost and admin for each domain, and support mail still shares an inbox with everything else.

4. A forwarding service plus somewhere to reply from

Forwarding services (many registrars include one, and Cloudflare offers Email Routing) handle the receiving side for free. But forwarding only gets mail to you, and the reason you used “Send mail as” was replying. On its own, forwarding doesn’t replace it; you need one of the other options for sending.

5. A help desk

Help desks receive mail for your support addresses and send replies from them, with assignment, macros and reporting on top. If you have a support team, that’s the natural move. For one founder answering a handful of messages a day, it can be more tool than the job needs.

6. A shared support inbox

InboxNest sits between Gmail and a help desk. Each product’s domain gets as many addresses as you want, all in one inbox of their own. Replies go out from the address the customer wrote to, and each connected domain gets its own DKIM key and custom Return-Path. You can keep your existing email and forward only the support addresses, or point a domain with no mailbox straight at InboxNest (Direct MX or forwarding?). Setup is DNS records and a forwarding rule; it doesn’t ask for your email password. Google’s page warns about third-party services that “often require access to your email credentials or OAuth tokens”, which is worth keeping in mind whichever tool you choose.

What “Send mail as” did well, and what to keep

It’s worth being fair to the feature that’s going away. “Send mail as” was free, built into an app you already used, and Gmail lets you send from up to 99 addresses. Whatever replaces it should keep the parts that mattered:

• Replies from the branded address. Google notes some recipients saw “From yourname@gmail.com on behalf of othername@otherdomain.com”. A replacement should send as the brand outright.
• One place to read everything. If you run several products, avoid swapping one inbox for five.
• Authentication per domain. Each sending domain needs SPF, DKIM and DMARC set up for whatever sends its mail. See SPF, DKIM and DMARC explained in plain English.

A checklist before January 2027

1. In Gmail, open Settings → Accounts and list every address under “Send mail as”. Note which ones are Google addresses (unaffected) and which aren’t.
2. For each non-Google address, note where its mail arrives today: forwarding, POP fetching or a provider mailbox.
3. Pick a replacement for sending, using the options above. If you rely on POP fetching, switch to forwarding at the other provider.
4. Set up the DNS your new setup needs, then run each domain through the support email checker to confirm MX, SPF, DKIM and DMARC.
5. Send a test message to each support address from an outside account, reply, and check the reply arrives from the branded address and passes SPF, DKIM and DMARC.
6. Update any auto-replies, signatures or help pages that mention the old setup, then remove the old “Send mail as” entries.

Related reading

• How to set up support@ for your SaaS without Google Workspace
• How to manage support email for multiple products from one inbox
• SPF, DKIM and DMARC for support email, explained in plain English