Gmail dejará de dar soporte a "Send as" para direcciones de terceros, como @yahoo.com

Google está eliminando el soporte de Gmail para “Send as” en direcciones de terceros (p. ej., Yahoo, Outlook y dominios personalizados no alojados en Google), aunque lo mantendrá para alias de Google Workspace y otras identidades gestionadas por Gmail. Muchos usuarios que dependían de Gmail como centro para varias direcciones no pertenecientes a Google lo ven como un empujón hacia planes de Workspace de pago o proveedores alternativos como Fastmail, Proton, el alojamiento de correo iCloud+ de Apple o soluciones autoalojadas. Los comentaristas también interpretan esta medida como parte del alejamiento a largo plazo de Gmail de las funciones para usuarios avanzados, impulsado por medidas antiabuso (DMARC/SPF/DKIM) y por el deseo de Google de reducir costos de mantenimiento y monetizar aún más el correo electrónico.

Qué está cambiando y por qué importa

  • Gmail eliminará el soporte de “Send as” para direcciones de terceros/no pertenecientes a Google (p. ej., yahoo.com, outlook.com y dominios personalizados no alojados por Google).
  • “Send as” para identidades alojadas por Google (otras direcciones de Gmail, alias de Workspace) seguirá funcionando.
  • Varios comentaristas dicen que la función históricamente se implementaba de una de estas dos formas:
    • Gmail enviando correo directamente desde el SMTP de Google (con SPF/DKIM configurados adecuadamente), o
    • Gmail actuando como un cliente de correo normal usando el SMTP del proveedor de terceros.
  • Muchos usuarios la han usado durante años para conservar un dominio personal/personalizado mientras usan Gmail como su única interfaz.

Ambigüedades y confusión

  • No está claro qué cuenta exactamente como una “identidad alojada por Google”, especialmente en el caso de dominios personalizados que usan Google para el SMTP saliente pero otro proveedor (o reenvío) para el entrante.
  • Algunos documentos de soporte mencionan la app móvil de Gmail y el acceso de terceros, lo que genera confusión sobre qué sigue funcionando vía app/IMAP frente a la web.
  • Varias personas no saben si las cuentas personales de Gmail todavía pueden hacer “Send as” de dominios personalizados alojados en Workspace.

Motivaciones e interpretaciones

  • Un sector: esto está impulsado por el endurecimiento de DMARC/SPF/DKIM y la reducción del abuso; el reenvío a través de terceros es frágil y un vector de ataque.
  • Otro sector: esto es principalmente monetización y recorte de costos: empujar a los usuarios hacia Workspace de pago o deshacerse de funciones de borde costosas de mantener.
  • Algunos sostienen que la función probablemente tiene un uso mínimo y no supone un “suicidio” para Gmail; otros predicen que provocará deserciones importantes.

Impacto en los usuarios y reacciones

  • Entre los usuarios afectados se incluyen:
    • Personas y pequeñas empresas que usan Gmail como interfaz para correo de dominios personalizados alojado en otro sitio.
    • Personas que agregan muchas direcciones en una sola bandeja de entrada de Gmail y responden “desde” esas direcciones.
  • Para algunos, esto es la “gota que colma el vaso” y les impulsa a migrar fuera de Gmail/Workspace.
  • Otros lo ven como un empujón para ser dueños de su correo por completo (mediante su propio dominio y un proveedor que no sea de Google).

Alternativas y estrategias de migración

  • Proveedores mencionados con frecuencia: Fastmail, Proton, el correo iCloud de Apple con dominios personalizados, Migadu, MXRoute, mailbox.org, posteo, Tuta, Runbox.
  • Compromisos reportados:
    • Fastmail: generalmente positivo (bueno con dominios/alias, algunas quejas sobre la interfaz, límites de almacenamiento manejables).
    • Apple iCloud+: elogiado como alojamiento familiar barato con múltiples dominios personalizados.
    • Migadu: flexible con múltiples dominios, calendario más débil.
    • Tuta/Tutanota: E2EE fuerte pero sin IMAP/SMTP, lo que algunos consideran un factor decisivo.
  • Consejo común:
    • Pasar a tu propio dominio, para que luego los proveedores puedan intercambiarse cambiando los MX.
    • Usar reenvío más actualizaciones graduales de cuentas; mantener Gmail como un “catch-all” heredado hasta migrar por completo.