El cliente llena el formulario, aprieta enviar, ve el mensaje de gracias y sigue con su día. Tú nunca recibes nada. Días después aparece una cotización perdida y nadie sabe en qué punto se cortó la conversación.

Es una de las fallas más caras y más silenciosas de un sitio de empresa, porque el formulario sí responde: no hay error, no hay pantalla en blanco, no hay aviso. Simplemente el mensaje se fue a una ruta que nadie estaba mirando.

La buena noticia es que casi siempre el problema está más adelante: en el camino que recorre el correo después de enviarse, no en el formulario mismo.

Qué significa exactamente que el formulario “no envíe”

Conviene separar tres escenarios, porque cada uno se diagnostica distinto:

  • El formulario muestra un error. El envío ni siquiera salió del sitio: falta un campo, un complemento quedó mal configurado, la página se recarga y borra lo escrito.
  • Dice “mensaje enviado” pero no llega nada. Es el caso más común. El sitio entregó el mensaje al servidor de correo, y ahí se perdió, se rechazó o quedó en una carpeta que no revisas.
  • Llega, pero a la carpeta de spam o a la cuarentena. El mensaje existe, solo que el filtro del destinatario desconfía de él.

En la mayoría de esos dos últimos casos la causa de fondo es la misma: el correo sale del sitio sin la autenticación que el proveedor del destinatario espera. Por eso el mensaje de gracias puede ser cierto —el sitio hizo su parte— y aun así el correo nunca aparecer.

Por qué en WordPress falla más que en otros sitios

WordPress envía correo con la función wp_mail(), que por defecto usa el correo interno del servidor (mail() de PHP). Esa función entrega el mensaje a un servicio de correo local, sin usuario, sin contraseña y sin ninguna verificación de que el sitio tenga derecho a enviar en nombre del dominio.

Ese es el punto débil. El servidor web solo sabe mandar; no sabe autenticarse. Y desde hace años los proveedores grandes —Gmail, Outlook, Yahoo— miran justamente eso: si el dominio declara en su DNS qué servidores pueden enviar por él, y si el mensaje viene firmado.

Las consecuencias típicas:

  • El mensaje sale con un remitente que no es una casilla real del dominio, como [email protected] o el correo que escribió el visitante.
  • La IP que envía no está autorizada en el registro SPF del dominio, así que ese registro no la respalda.
  • El mensaje no viene firmado con DKIM, o viene firmado por un dominio distinto al del remitente.
  • El proveedor del destinatario lo rechaza sin que tú lo veas (el rebote llega a una casilla que nadie revisa), o lo manda a spam.

La pregunta inevitable es “si esto siempre fue así, ¿por qué antes funcionaba?”. Porque el correo cambió. Los filtros se volvieron más estrictos, el sitio pudo cambiar de servidor, o alguien movió el correo del dominio a Google Workspace y dejó la web donde estaba. Cualquiera de esos cambios rompe una cadena que antes pasaba desapercibida.

El remitente que no existe

Hay una práctica que parece inofensiva y es una de las causas más frecuentes: poner la dirección del visitante como remitente del mensaje, para poder responder apretando “responder”.

El problema es que ese remitente no pertenece a tu dominio y no está autorizado a enviar desde tu servidor. El proveedor del destinatario lo interpreta como suplantación: un mensaje que dice venir de un Gmail cualquiera pero que salió de la IP de tu hosting. El resultado habitual es spam o rechazo directo.

La forma correcta es la inversa:

  • De (remitente): una casilla real de tu dominio, por ejemplo [email protected].
  • Responder a: la dirección que escribió el visitante.

Así el correo queda autenticado como tuyo y, cuando aprietas responder, la respuesta va al cliente. Es un cambio de un campo en el complemento del formulario y suele ser la diferencia entre recibir y no recibir.

Correo en Google Workspace y web en otro hosting

Este es el escenario que más confunde, porque todo “está bien configurado” por separado.

La empresa tiene el correo en Google Workspace. Los registros MX del dominio apuntan a Google, y por eso el correo que llega a las casillas funciona perfecto. Pero el sitio web sigue alojado en otro proveedor, y el formulario envía desde la IP de ese hosting.

Ahí aparece el desajuste: el SPF del dominio autoriza a Google, no al servidor de la web. El mensaje sale con una IP que el dominio no reconoce.

Hay dos salidas y no valen lo mismo:

  1. Agregar el hosting al SPF del dominio. Autoriza también al servidor web, pero suma entradas al registro y hay que mantenerlo cada vez que cambies de proveedor. Si el dominio ya tiene varios servicios autorizados, conviene revisar el total: el estándar limita las búsquedas DNS del SPF y pasarse deja el registro inválido.
  2. Enviar por el servidor del proveedor de correo, con autenticación. El sitio deja de enviar por su cuenta y entrega el mensaje a Google (u otro proveedor) con usuario y contraseña. El correo sale desde una IP ya autorizada y firmada por DKIM. Es la opción estable a largo plazo.

El detalle de autorizar servicios externos sin romper el SPF está en cómo autorizar un facturador, un CRM o un boletín sin romper el SPF, y aplica igual para el formulario de contacto.

Cuando el límite está en el hosting

No todo es autenticación. El hosting también pone reglas, y algunas explican fallas intermitentes:

  • Tope de envío por hora o por día. Pensado para que una cuenta comprometida no convierta el servidor en una máquina de spam. Cuando se alcanza, los mensajes siguientes se rechazan o se encolan.
  • Función de correo deshabilitada. Algunos planes la apagan por defecto para evitar abusos.
  • Puerto de salida bloqueado. Muchos proveedores cierran el puerto 25 saliente porque es el que más se usa para spam. Si tu complemento intenta enviar por ahí, no sale nada. Por eso la recomendación es usar el puerto de envío autenticado (el 587), que sí está abierto.

La señal típica de un tope es la irregularidad: llega uno de cada cinco, o funciona en la mañana y deja de funcionar en la tarde. Si el patrón es “nunca llega”, el problema es de configuración, no de cuota. Los topes y la reputación del dominio se explican con más detalle en correos masivos y boletines desde el hosting.

Cómo saber dónde se perdió el mensaje

Antes de tocar configuración, hay que ubicar el punto de corte. Cinco comprobaciones, en este orden:

  1. Envía el formulario a una casilla propia en otro proveedor. Si llega a Gmail pero no a la casilla de la empresa, el problema está en el filtro del destino, no en el sitio.
  2. Revisa la casilla completa. Spam, cuarentena, pestañas de promociones y cualquier filtro o regla que desvíe mensajes con asunto o remitente desconocido. Un mensaje puede estar llegando hace meses a una carpeta que nadie abre.
  3. Pide la traza al proveedor de hosting. Con la hora exacta del envío, el remitente y el destinatario, el registro del servidor de correo dice si el mensaje salió, si fue rechazado y con qué código. Es la prueba que zanja la discusión.
  4. Revisa el registro de errores del sitio. Los errores de PHP relacionados con el envío de correo quedan ahí, y suelen nombrar la causa: función deshabilitada, conexión rechazada, tiempo agotado.
  5. Mira las cabeceras del mensaje recibido. En Gmail es “Mostrar original”: ahí aparecen las líneas spf=, dkim= y dmarc= con pass o fail. Si el mensaje llegó a spam con spf=fail, ya sabes qué corregir. Sobre cómo interpretar esos resultados está ¿los correos de tu empresa llegan a spam?.

Vale la pena detenerse en los filtros del destinatario, porque son los que más veces hacen pasar un formulario por roto. Un filtro antispam corporativo puede retener mensajes de remitentes desconocidos en cuarentena sin avisar a nadie; una regla creada hace meses puede estar moviendo todo lo que diga “formulario” a una carpeta secundaria. Cuando el correo llega a la cuarentena, ni tú ni el cliente lo ven: el mensaje está entregado y, al mismo tiempo, perdido.

Por eso la prueba con dos casillas de proveedores distintos es tan útil: separa el problema del sitio del problema del destino. Si en Gmail entra a la bandeja y en la casilla de la empresa no aparece, no hay nada que arreglar en el formulario.

La solución que aguanta: envío autenticado con una casilla del dominio

El arreglo definitivo es dejar de usar el correo interno del servidor y configurar el sitio para que envíe por el servidor de correo real, con usuario y contraseña. Se hace con un complemento de correo SMTP (WP Mail SMTP, Fluent SMTP o Post SMTP, entre otros) y estos datos:

  • Servidor: el mismo que usas en Outlook o en el celular para enviar correo.
  • Puerto: 587 con cifrado STARTTLS, o 465 con SSL. Evita el 25.
  • Usuario: la casilla completa, con el arroba incluido.
  • Contraseña: la de esa casilla.
  • Remitente forzado: la misma casilla, para que ningún otro complemento la sobrescriba.
  • Responder a: el correo que escribió el visitante.

Si el correo del dominio está en Google Workspace, el servidor es smtp.gmail.com en el puerto 587 y la autenticación exige una contraseña de aplicación o autorización de la cuenta, no la contraseña normal del usuario. Ojo con un detalle: la contraseña de aplicación solo existe si esa cuenta tiene la verificación en dos pasos activada; si no la tiene, hay que activarla primero o el complemento no podrá autenticarse. En proveedores con panel propio, los datos están en la ficha de la casilla de correo.

Dos recomendaciones que ahorran problemas después:

  • Crea una casilla dedicada para el formulario, por ejemplo [email protected]. Separa el correo automático del de las personas, permite aplicar filtros y, si algún día empieza a recibir spam, se cambia sin tocar la cuenta de nadie.
  • Prueba después de configurar. Envía un mensaje real, confirma que llega a la bandeja de entrada y revisa las cabeceras: spf=pass, dkim=pass y dmarc=pass significan que la cadena quedó bien.

Si el formulario recibe mucho spam entrante, eso es otro problema y se ataca con captcha o campo trampa. No afecta la entrega de los mensajes legítimos, pero sí puede hacerte creer que el formulario falla cuando en realidad está funcionando y nadie revisa la bandeja.

Qué pedirle a tu proveedor de hosting

Cuando el sitio es de una pyme y no hay quien administre servidores, estas son las preguntas que conviene hacer antes de contratar o al abrir un reclamo:

  • ¿Entregan la traza de un mensaje cuando el formulario no llega?
  • ¿Permiten el envío autenticado por el puerto 587 hacia un servidor externo?
  • ¿La IP del hosting está en listas negras de correo, y qué hacen si aparece?
  • ¿Se puede activar DKIM para el dominio?
  • ¿Hay un tope de envío y dónde está escrito?

Un proveedor que responde esas cinco preguntas te ahorra el diagnóstico a ciegas. Uno que no las responde te va a mandar a revisar el formulario durante días mientras el problema está en otra capa.

Y si el sitio está en WordPress, mantener los complementos al día importa: un formulario desactualizado puede dejar de enviar después de una actualización del tema o del propio WordPress. La rutina está en WordPress y plugins al día.

¿Necesitas ayuda con el correo de tu empresa?

Si el formulario lleva semanas sin entregar mensajes y ya probaste cambiar el complemento sin resultado, el problema está en la configuración de correo del dominio, no en el sitio. Podemos revisar juntos el SPF, el DKIM, el remitente y la salida de correo del hosting, y dejar el formulario enviando con autenticación real.

Escríbenos por la página de contacto contando qué pasa —si llega a spam, si no llega nada, desde cuándo— y revisamos tu caso. Si además necesitas hosting para empresas o prefieres delegar la administración del sitio, están los planes de hosting web para empresas y de WordPress administrado.