Gmail vai encerrar o suporte a "Send as" para endereços de terceiros, como @yahoo.com

Artigo original ↗ Discussão no Hacker News ↗

O Google está encerrando o suporte do Gmail a “Send as” para endereços de terceiros (por exemplo, Yahoo, Outlook e domínios personalizados não hospedados pelo Google), mantendo-o para aliases do Google Workspace e outras identidades gerenciadas pelo Gmail. Muitos usuários que dependiam do Gmail como um hub central para vários endereços não Google veem isso como um empurrão para planos pagos do Workspace ou para provedores alternativos como Fastmail, Proton, o iCloud+ Mail da Apple ou soluções auto-hospedadas. Comentadores também enquadram a mudança como parte do afastamento de longo prazo do Gmail de recursos para usuários avançados, impulsionado por medidas antiabuso (DMARC/SPF/DKIM) e pelo desejo do Google de reduzir custos de manutenção e monetizar ainda mais o e-mail.

O que está mudando e por que isso importa

  • O Gmail vai remover o suporte a “Send as” para endereços de terceiros/não Google (por exemplo, yahoo.com, outlook.com e domínios personalizados não hospedados pelo Google).
  • O “Send as” para identidades hospedadas pelo Google (outros endereços Gmail, aliases do Workspace) continua.
  • Vários comentaristas dizem que o recurso foi historicamente implementado de duas formas:
    • o Gmail enviando e-mail diretamente pelos SMTP do Google (com SPF/DKIM configurados apropriadamente), ou
    • o Gmail agindo como um cliente de e-mail comum usando o SMTP do provedor de terceiros.
  • Muitos usuários usaram isso por anos para manter um domínio pessoal/personalizado enquanto usavam o Gmail como sua única interface.

Ambiguidades e confusão

  • Não está claro o que exatamente conta como uma “identidade hospedada pelo Google”, especialmente para domínios personalizados que usam o Google para SMTP de saída, mas outro provedor (ou redirecionamento) para entrada.
  • Alguns documentos de suporte mencionam o app móvel do Gmail e acesso de terceiros, gerando confusão sobre o que ainda funciona via app/IMAP versus web.
  • Várias pessoas não têm certeza se contas pessoais do Gmail ainda podem “Send as” domínios personalizados hospedados no Workspace.

Motivações e interpretações

  • Uma corrente: isso é impulsionado pelo fortalecimento de DMARC/SPF/DKIM e redução de abuso; o relay de terceiros é frágil e um vetor de ataque.
  • Outra corrente: isso é principalmente monetização e redução de custos — empurrando usuários para o Workspace pago ou descarregando recursos de borda que exigem muita manutenção.
  • Alguns argumentam que o recurso provavelmente tem uso mínimo e não é “suicídio” para o Gmail; outros preveem que ele levará a deserções significativas.

Impacto nos usuários e reações

  • Usuários afetados incluem:
    • indivíduos e pequenas empresas que usam o Gmail como UI para e-mail de domínio personalizado hospedado em outro lugar.
    • pessoas que agregam muitos endereços em uma única caixa de entrada do Gmail e respondem “como” esses endereços.
  • Para alguns, isso é a “gota d’água” que leva à migração para longe do Gmail/Workspace.
  • Outros veem isso como um incentivo para realmente ter o próprio e-mail (via seu próprio domínio e um provedor não Google).

Alternativas e estratégias de migração

  • Provedores frequentemente mencionados: Fastmail, Proton, Apple iCloud Mail com domínios personalizados, Migadu, MXRoute, mailbox.org, posteo, Tuta, Runbox.
  • Compromissos relatados:
    • Fastmail: geralmente positivo (bom com domínios/aliases, algumas reclamações de UI, limites de armazenamento administráveis).
    • Apple iCloud+: elogiado como hospedagem barata para famílias com múltiplos domínios personalizados.
    • Migadu: flexível com múltiplos domínios, calendário mais fraco.
    • Tuta/Tutanota: E2EE forte, mas sem IMAP/SMTP, o que alguns chamam de impeditivo.
  • Conselho comum:
    • Mude para o seu próprio domínio; então os provedores se tornam substituíveis via mudanças de MX.
    • Use encaminhamento e atualizações graduais de contas; mantenha o Gmail como um “catch-all” legado até a migração completa.