Gmail to end support for "Send as" for third-party addresses, such as @yahoo.com

Original Article ↗ Hacker News Discussion ↗

Google is ending Gmail’s “Send as” support for third-party addresses (e.g., Yahoo, Outlook, and custom domains not hosted on Google), while retaining it for Google Workspace aliases and other Gmail-managed identities. Many users who relied on Gmail as a central hub for multiple non-Google addresses see this as a push toward paid Workspace plans or alternative providers like Fastmail, Proton, Apple’s iCloud+ mail hosting, or self-hosted solutions. Commenters also frame the move as part of Gmail’s long-term drift away from power-user features, driven by anti-abuse measures (DMARC/SPF/DKIM) and Google’s desire to reduce maintenance costs and further monetize email.

What is changing and why it matters

  • Gmail will remove “Send as” support for third‑party/non‑Google addresses (e.g., yahoo.com, outlook.com, and custom domains not hosted by Google).
  • “Send as” for Google‑hosted identities (other Gmail addresses, Workspace aliases) continues.
  • Several commenters say the feature was historically implemented either by:
    • Gmail sending mail directly from Google’s SMTP (with SPF/DKIM set up appropriately), or
    • Gmail acting like a regular mail client using the third‑party provider’s SMTP.
  • Many users have used this for years to keep a personal/custom domain while using Gmail as their sole interface.

Ambiguities and confusion

  • Unclear what exactly counts as a “Google‑hosted identity,” especially for custom domains that use Google for outbound SMTP but another provider (or forwarding) for inbound.
  • Some support docs mention the Gmail mobile app and third‑party access, leading to confusion about what still works via app/IMAP vs web.
  • Multiple people are unsure whether personal Gmail accounts can still “Send as” Workspace‑hosted custom domains.

Motivations and interpretations

  • One camp: this is driven by DMARC/SPF/DKIM hardening and abuse reduction; third‑party relaying is fragile and an attack vector.
  • Another camp: this is primarily monetization and cost‑cutting—pushing users toward paid Workspace or offloading maintenance-heavy edge features.
  • Some argue the feature likely has tiny usage and is not “suicide” for Gmail; others predict it will drive meaningful defections.

User impact and reactions

  • Affected users include:
    • Individuals and small businesses using Gmail as the UI for custom‑domain mail hosted elsewhere.
    • People aggregating many addresses into one Gmail inbox and replying “from” those addresses.
  • For some, this is “last straw” prompting migration away from Gmail/Workspace.
  • Others see it as a nudge to fully own their email (via their own domain and non‑Google provider).

Alternatives and migration strategies

  • Frequently mentioned providers: Fastmail, Proton, Apple’s iCloud Mail with custom domains, Migadu, MXRoute, mailbox.org, posteo, Tuta, Runbox.
  • Reported tradeoffs:
    • Fastmail: generally positive (good with domains/aliases, some UI gripes, storage limits manageable).
    • Apple iCloud+: praised as cheap family hosting with multiple custom domains.
    • Migadu: flexible with multiple domains, weaker calendar.
    • Tuta/Tutanota: strong E2EE but no IMAP/SMTP, which some call a deal‑breaker.
  • Common advice:
    • Move to your own domain, then providers become swappable via MX changes.
    • Use forwarding plus gradual account updates; keep Gmail as a legacy “catch‑all” until fully migrated.