Las invitaciones de reunión iban al spam — era «a través de google.com»

Desarrollé notificaciones de reunión de Google — y fueron directo al spam

Desarrollé una función: cuando un usuario crea una reunión de Google en el sistema, recibe una notificación enviada por los servidores de Google Calendar. Al terminarla, las notificaciones sí llegaban — pero todas acababan en spam.

Probé varias cosas: mover el aviso de spam a la bandeja de entrada, añadir el remitente a contactos. Nada resolvía el problema. Al crear otra reunión, la notificación seguía yendo directo al spam.

La pista: «a través de google.com»

El asunto era algo así:

«Invitación actualizada: Alguna reunión - miércoles, X de mes de 2026, 13:00 – 14:00 (GMT+8)»

Y en la línea del remitente aparecía:

[email protected] a través de google.com

La clave estaba en ese «a través de google.com». Cuando el sistema crea un evento de Google Calendar e invita a los participantes con la identidad [email protected], quien realmente envía el correo es el servidor de Google Calendar (la ruta pasa por google.com).

Para Gmail en el lado receptor, la pantalla viene a decir: este mensaje dice ser de yuwen-c.com, pero lo envió Google en su nombre — y el DNS de yuwen-c.com no había autorizado a Google a enviar correo en nombre de ese dominio.

Identidad: [email protected]
        │ crear invitación de reunión
        ▼
Los servidores de Google Calendar lo envían de verdad
        │ From parece yuwen-c.com
        │ ruta real: google.com
        ▼
Gmail receptor: consulta el SPF de yuwen-c.com
        │
        ├─ Google no autorizado → parece falsificado → spam
        └─ Google incluido → coincide → más fácil que entre en la bandeja

Configurar SPF: declarar quién puede enviar en nombre del dominio

Se lo pregunté a Gemini. La solución más efectiva era configurar SPF, DKIM y DMARC. El SPF, en resumen, es una lista que publicas en el DNS de tu dominio y que declara: «En todo el mundo, solo los servidores A, B y C pueden enviar correo en mi nombre.»

Gemini también explicó: sin SPF, ese «el nombre no coincide con quien envía de verdad» se parece exactamente a cómo los estafadores falsifican el correo, así que los filtros de Gmail lo tratan como spam. Cuando Gmail comprueba que el mensaje sí viene de un servidor de Google que está en tu lista autorizada, lo deja pasar.

En efecto: en cuanto quedó configurado el registro, la siguiente notificación llegó bien a la bandeja de entrada.

¿Entonces los estafadores solo tienen que configurar SPF para pasar la verificación?

En la respuesta de Gemini señaló que los estafadores no pueden hacerse pasar por dueños de un dominio ajeno y configurar el SPF de ese dominio.

Ahí me faltaba un contexto: los estafadores suelen hacerse pasar por un dominio conocido al enviar correo. El mecanismo sirve para comprobar que «la identidad que proclaman es de verdad la suya». Sí pueden comprar su propio dominio y ponerle SPF — pero no pueden fingir ser otro dominio famoso.

Aunque compren su propio dominio, Gemini mencionó otra señal: la Domain Reputation de Google, que también tiene en cuenta la Domain Age. Un dominio de apenas unos días que de pronto envía un volumen enorme de correo parece un riesgo alto de phishing.

Esa respuesta me dejó de un modo curioso satisfecha. La confianza funciona igual que entre personas: hace falta tiempo para construirla. Incluso en el mundo de las máquinas — la confianza y el valor se juzgan mejor con el tiempo.