Does the 2026 Gmail Send as Discontinuation Affect Google Workspace Email Aliases?

Check the policy boundary before changing an address

Google says Gmail will stop supporting Send as for third-party email addresses in January 2027. The same guidance says Google Workspace aliases and other Google-hosted identities are outside this change. The official help page is the policy reference; an account’s own settings and a test message are what establish how a particular address is configured.

This table is a triage tool, not a guarantee about an individual configuration. Google’s policy describes which sending feature is changing; it does not verify the provider, routing, permissions, or reply behavior of any specific account.

The practical check is to follow the sending identity, not the inbox where a message appears. A message arriving in Gmail could have been forwarded from an external mailbox, received directly by a Workspace account, or delivered through another route. Those paths can look similar in one inbox while behaving differently when you reply.

Identify who hosts the address, not what its domain looks like

A custom domain is a label readers can see; it is not enough to identify the service hosting the mailbox. A work address that ends in a company domain may be an address managed by Google Workspace, an external mailbox, or a forwarding address connected to another account. The policy question is whether the sending identity is a Google-hosted Workspace identity or a third-party address added to Gmail’s Send as settings.

Is this a Workspace alias or a third-party mailbox?

To confirm an address is a Workspace alias, check the organization’s Google Workspace administration and the account or alias assignment associated with the intended sender. Google’s administrator documentation explains the relationship between Workspace users and aliases; use that documentation alongside the organization’s own account configuration rather than inferring ownership from the address format.

For an external mailbox, check the provider that operates the mailbox and the settings in the Gmail account where the address was added. Gmail’s official instructions for sending mail from another address describe the Send as setup. If the address is listed as an external sender there, that is a different arrangement from an alias assigned within the organization’s Workspace environment.

Do not classify an address from its domain alone. That shortcut can lead to two opposite mistakes: migrating a Workspace alias that Google says is outside the change, or assuming an external Send as identity is safe because it uses a familiar custom domain.

Separate incoming forwarding from replying as the address

An external mailbox can forward incoming messages to Gmail while Gmail’s ability to send as that external address is configured separately. Google’s automatic forwarding instructions cover forwarding; they are distinct from the Send as setup for sending from another address.

That distinction answers a common concern: the planned change to third-party Send as does not, by itself, establish that a separate forwarding rule will stop. Google says third-party automatic forwarding can operate independently of Send as. But that does not guarantee delivery in every provider’s setup. The original mailbox, forwarding rule, authentication, and destination account all remain relevant. Google’s forwarding and authentication guidance provides advice for handling forwarded messages; use it as guidance, not as a promise that a particular provider will deliver every message.

A reply can use a different identity from the one that received the message. This is especially easy to miss when Gmail combines messages from several accounts. Before relying on an old workflow, send a test to an address you control and confirm both the visible sender and where a reply would go. Do not use a sensitive customer conversation as the first test.

Audit mixed Workspace and external-address workflows

When both kinds of address appear in one Gmail inbox, review each work or project identity separately. A freelancer might receive project messages forwarded from an external mailbox while sending client replies through a Workspace alias. Someone else may use the same inbox only to read messages but send directly from the original provider. The inbox view alone does not distinguish these arrangements.

Use a small address register. Record the address, who hosts it, how incoming messages arrive, where you send from, and which address recipients should reply to. Add an owner who can confirm the configuration and a review status so that unresolved entries do not get mistaken for verified ones.

A compact review should answer four questions for every address:

• Who hosts it? Confirm the provider or organization account instead of relying on the domain name.
• How does incoming mail arrive? Record whether messages go directly to Gmail or pass through a forwarding rule.
• Where does sending happen? Note whether the sender uses a Workspace identity, Gmail’s third-party Send as feature, or the provider’s own interface.
• What identity does the recipient see? Verify the From address and reply behavior with a test message.

This also prevents a frequent misreading of the change: a message arriving in Gmail does not mean the address is a Gmail-hosted identity. The receiving location and the sending service are different parts of the mail path.

Choose a sending route for each scenario

For a Workspace alias that is confirmed in the organization’s configuration, keep using the organization’s intended route unless the account test or administrator identifies a separate issue. Google says Workspace aliases are outside this third-party Send as change, but account-specific permissions and configuration still need to be checked locally.

For an external address that currently relies on Gmail’s Send as feature, plan a replacement sending route before the announced change takes effect. Options depend on the external provider and organizational requirements. The provider’s own mail interface or a mail client that supports the relevant account may be suitable, but check the provider’s documentation and test the actual sender identity before migrating. Google’s change notice describes alternative ways to access third-party accounts; it does not guarantee that every alternative supports every provider or workflow.

For a route that is unclear, preserve the current configuration while you gather evidence. Avoid deleting a sender, disabling a forwarding rule, or changing a public contact address until the receiving and sending paths have been tested separately. Keep a rollback option, such as a documented original setting or a confirmed way to send directly from the provider, in case the replacement route does not behave as expected.

A review sequence for administrators and individual users

1. List every address used for work, projects, or personal correspondence. Include addresses that only forward into Gmail as well as those used to send replies.
2. Confirm the hosting provider for each address. Check Workspace records or the external provider’s account. Do not use the domain suffix as proof.
3. Record the current incoming route. Mark whether mail is delivered to the mailbox directly or forwarded into Gmail, and identify who controls that rule.
4. Record the current sending route. Note the account and interface used. If Gmail is configured to send as an external address, mark it for review against Google’s announced scope.
5. Test sender and reply identity. Send a controlled message and verify the visible From address and expected reply destination.
6. Choose and test any replacement route. For an affected third-party sending identity, check provider support and organizational requirements before switching.
7. Update the register and tell the right people. Share confirmed changes with team members who send from the address, and leave unresolved entries visibly marked until their owner verifies them.

The timing should follow Google’s official policy page, which states that third-party Send as support is due to end in January 2027. Recheck that page before scheduling a migration because the official policy, implementation date, or applicability could change. The review sequence above is a configuration audit, not a prediction about how a specific third-party provider will behave.

Keep a review record you can revisit

The address register is most useful when it records evidence, not assumptions. For each entry, save the source of the hosting information, the forwarding or sending setting that was checked, the date of the test, and who verified it. Avoid storing passwords or other credentials in the register. Keep the policy link as the source for the announced scope, and use account settings plus test messages as evidence of your own configuration.

A clear status can be as simple as “confirmed Workspace identity,” “external Send as review needed,” or “forwarding tested; reply identity unverified.” These labels make it harder for a team to treat successful incoming delivery as proof that outgoing mail is configured correctly. They also give administrators a concrete list to revisit if Google updates its policy or a provider changes its mail service.

If you are planning a broader address system, our guide to email aliases and disposable addresses explains when a reusable address differs from a short-term one. For a planned address change, the alias exit checklist can help you think through what to update before retiring an address.

For a one-off signup that does not need an ongoing reply relationship, a temporary inbox can keep that registration separate from your primary work identity. InboxCloak is an option for that limited use, but it is not a substitute for Gmail’s third-party Send as feature, a Workspace alias, or a mailbox you need to use for long-term correspondence. Decide the sending route from the hosting records first; use a temporary address only when the account’s future mail and recovery needs make that appropriate.