Saltar al contenido

ideformsPágina 2 de 5

Por qué los correos de un formulario web llegan a spam

Pocas cosas son tan frustrantes para un negocio como descubrir, semanas después, que alguien le escribió desde su web y el mensaje nunca llegó. Casi siempre la culpa no es del formulario, sino de cómo envía el correo.

Enviado no es lo mismo que recibido

Cuando un formulario dice «Mensaje enviado», lo único que garantiza es que la web ha entregado el correo a un servidor de salida. Lo que pasa después ya no depende de ella. El servidor de destino, el de Gmail, Outlook o el de tu propio dominio, decide si lo acepta, si lo coloca en la bandeja de entrada, si lo manda a spam o si lo rechaza sin más.

A esa capacidad de llegar a la bandeja de entrada se le llama entregabilidad. No es un sí o un no, sino una reputación que se construye con cada mensaje, y depende de quién envía, desde dónde lo hace y con qué credenciales.

El remitente que no es quien dice ser

El error más extendido es también el más fácil de entender. Muchos formularios envían el aviso como si lo hubiera escrito el propio visitante: si María rellena el formulario con su dirección de Gmail, el aviso llega a tu correo con María como remitente.

Parece cómodo, porque basta con pulsar responder. Pero para el servidor que lo recibe, el mensaje dice venir de gmail.com y en realidad sale del servidor de tu web, que no tiene ningún permiso para enviar en nombre de Gmail. Es exactamente lo que hace quien intenta suplantar una identidad, y los filtros lo tratan como tal: a spam o directamente rechazado.

Un servidor compartido con miles de webs

El segundo problema está en el origen. En muchos alojamientos, la web envía el correo con la función de envío del propio servidor, que comparten cientos o miles de webs de otros clientes. La reputación de ese servidor es la suma de todo lo que se envía desde él.

Basta con que una de esas webs esté infectada o haga envíos masivos para que la dirección del servidor acabe en listas negras, y con ella el correo de todos los demás. Tu web puede estar haciéndolo todo bien y aun así pagar los platos rotos de un vecino al que no conoces.

Una configuración que nadie revisa

El tercero es el olvido. Para que un servidor de destino confíe en el correo de un dominio, ese dominio tiene que publicar en su configuración quién puede enviar en su nombre y cómo comprobarlo. Son registros que se configuran una vez, normalmente cuando se crea la web o se cambia de alojamiento, y que rara vez alguien vuelve a mirar.

Si faltan, si están mal o si se quedaron anticuados tras una mudanza, el correo sale sin credenciales. Durante años eso apenas tenía consecuencias. Hoy las tiene, como veremos más adelante.

La cuenta personal metida en el formulario

Para esquivar todo lo anterior se popularizó una solución casera: configurar el formulario para que envíe a través de una cuenta de correo normal, muchas veces una cuenta de Gmail o de Outlook, con su usuario y su contraseña escritos en los ajustes de la web.

Funcionaba, pero tenía dos problemas. Uno, que la contraseña de una cuenta personal quedaba guardada en la web, a la vista de cualquiera que la comprometiera. Otro, que los grandes proveedores han dejado de permitirlo, y muchas webs que funcionaban así dejaron de enviar avisos de un día para otro sin que nadie lo notara.

El silencio, que es lo peor

Todos estos fallos comparten una característica: no hacen ruido. El visitante ve el mensaje de confirmación y se va tranquilo. La web no recibe ningún error. Tú no recibes nada, y nada te dice que deberías haber recibido algo.

Por eso la entregabilidad no se puede dejar al azar. Hace falta que el correo salga con unas credenciales que los servidores de destino sepan comprobar, y eso es lo que explicamos a continuación.

SPF, DKIM y DMARC explicados sin tecnicismos