Cuando alguien descubre que Gmail va a dejar de traer correo con POP, la primera idea suele ser: “activo el reenvío en el hosting y listo”. Suena limpio. A veces funciona un tiempo. Después llegan los casos raros: mails que no aparecen, que caen en spam, o que el destinatario nunca vio.
No es superstición. Es autenticación de correo.
Qué rompe el reenvío
Un mensaje sale firmado para el dominio original. Si el servidor del hosting lo reenvía hacia Gmail, el camino cambia. SPF dice qué servidores pueden mandar en nombre de ese dominio. DKIM firma el contenido. Al reenviar, esas señales dejan de cuadrar con lo que Gmail espera. Resultado típico: cuarentena, spam, o rechazo silencioso.
Por eso durante años el POP de Gmail fue el plan B preferido. Gmail iba al buzón original, bajaba el mensaje, y lo guardaba en tu cuenta. No dependías de que el forward “pareciera legítimo”.
Forward vs sincronización
- Forward: el otro servidor empuja una copia hacia Gmail. Gmail la juzga como mail entrante de terceros.
- Sincronización (IMAP/POP + API): un proceso lee el buzón y escribe el mensaje dentro de tu Gmail. El origen sigue siendo el servidor de la casilla.
La diferencia se siente en dominio propio, casillas de cPanel, y correos de ISP chicos. Ahí el forward suele doler más.
Cuándo el forward sí puede servir
Si controlás DNS, SRS, y el volumen es bajo, a veces se puede armar un forward decente. También sirve como respaldo temporal. No lo trataría como el reemplazo definitivo del Mail Fetcher si tu negocio depende de no perder leads.
Una salida práctica
Si querés seguir abriendo todo en Gmail web, buscá un esquema de sincronización. GetPopMail conecta casillas IMAP (y POP cuando aplica) y deja los mensajes en Gmail con etiquetas. Evitás pelearte con SPF cada vez que el hosting cambia algo.
Antes de apagar el POP viejo, mandate un mail de prueba a cada casilla y confirmá que llega donde corresponde. Suena obvio. Es lo que más gente saltea.