Gmail Is Ending Third-Party Send As: Audit Your Aliases Before 2027

Gmail will stop supporting third-party Send as addresses in January 2027. Gmailify and Gmail’s web-based POP fetching for third-party accounts will end at the same time.

If you send from an Outlook, Yahoo, hosting-provider, or other non-Google mailbox through your Gmail account, plan a migration now. Google-hosted Gmail addresses and Google Workspace aliases are not affected.

Which sender identities will actually stop working?

Google’s new third-party account guidance draws the boundary around the system hosting the identity, not the text after the @ alone.

Consider these four hypothetical addresses attached to one Gmail workflow:

That third row matters. A custom domain is not automatically a third-party address. If Google Workspace hosts the mailbox or alias, Google says the feature remains available.

Google’s Workspace documentation, updated August 14, 2026, says an administrator can attach an alternate address to a user and the user can send and receive through the primary Workspace account. Those aliases stay inside Google’s hosting boundary.

When was the change announced?

Google gives a quarter-level timeline rather than a day-level announcement date. Its support page says the notice period began in Q3 2026, migration runs through Q3 and Q4, and removal happens in January 2027.

Google has not published an exact January cutoff day. I would treat January 1 as the operational deadline instead of betting a business workflow on a few undocumented extra weeks.

Why does the mobile guidance look contradictory?

The feature removal applies to using a Gmail identity to send as a separately hosted address. It does not remove the Gmail mobile app’s ability to connect directly to a third-party account.

So, after the change:

• You cannot choose a third-party address from Gmail’s Send as configuration on web or mobile.
• You can still add that third-party mailbox directly to the Gmail mobile app and send through the provider’s account.
• You can still access Gmail itself from an external client through IMAP, POP, or the Gmail API.
• Messages already imported into Gmail will remain.
• Automatic forwarding from a third-party mailbox to Gmail will still work.

The common phrase “Gmail mobile still works” hides two different account paths. Test which account is actually selected and which server submits the message.

How can you inventory Send as identities with the Gmail API?

For one account, Gmail exposes the primary address and every custom From identity through users.settings.sendAs.list. The read requires an OAuth token with a supported Gmail scope, including gmail.settings.basic or gmail.readonly.

curl -s \
  'https://gmail.googleapis.com/gmail/v1/users/me/settings/sendAs' \
  -H "Authorization: Bearer $GMAIL_ACCESS_TOKEN" \
| jq -r '
  .sendAs[]
  | [
      .sendAsEmail,
      (.isPrimary // false),
      (.isDefault // false),
      (.verificationStatus // "n/a"),
      (.smtpMsa.host // "Google-managed")
    ]
  | @tsv
'

The output gives you the address, primary and default flags, Gmail’s ownership-verification state, and any configured SMTP relay host. Google’s alias API guide says external aliases should use a remote SMTP mail sending agent, so a custom identity with an smtpMsa host is a high-confidence migration candidate.

But do not turn that into a perfect classifier. A custom address without smtpMsa is not automatically safe, and a Workspace admin alias may appear beside other custom From identities. Confirm the hosting system and account configuration with the owner.

Will Gmail API sending preserve third-party aliases?

Google says Gmail API access will continue, and the current API still exposes SendAs resources. It does not say that an application may keep sending from a third-party identity after the Gmail feature is removed.

I would not read “the Gmail API continues” as an exception to “third-party Send as ends.” The SendAs resource documentation says its aliases correspond to the same Send mail as feature in Gmail’s web interface.

If an application depends on a non-Google From: address in a Gmail API request, move that stream to the mailbox provider’s SMTP or API before January. Keep the Gmail API for Gmail-hosted accounts and confirmed Workspace aliases.

Which migration path fits each workflow?

There is a fair objection here: the current setup still works, and January is months away. True.

The problem is that a mail migration needs more than changing a dropdown. You may need OAuth or SMTP credentials, SPF and DKIM changes, DMARC alignment checks, updated reply handling, bounce processing, and user training. Google also says new configurations may be restricted during the transition period.

What should you test before switching?

1. Inventory custom From identities in Gmail settings or with the API request above.
2. Record which provider hosts each mailbox and domain.
3. Move one low-risk identity to its replacement client, SMTP service, or API.
4. Send to Gmail and a non-Google mailbox, then inspect the visible From, Reply-To, SPF, DKIM, and DMARC results.
5. Reply from both destinations and confirm that the response reaches the intended mailbox.
6. Test forwarding, filters, signatures, vacation replies, and any application that selects a SendAs identity.
7. Remove the old dependency only after the replacement has handled normal and failure cases.

What does SendAs verification prove?

The Gmail API reports a custom identity as accepted or pending. That status means Gmail has or has not completed its ownership check for the sender alias.

It does not say whether a recipient address is deliverable, risky, or controlled by the person using it. Sender authorization and recipient verification answer different questions.

If your migration also changes signup, import, or notification lists, keep recipient checks separate. The emailverifier.dev API preserves deliverable, risky, undeliverable, and unknown outcomes without treating a sender-alias setting as mailbox evidence.

Inventory the aliases now. January is the cutoff, not the planning date.