Alguien llena tu formulario de contacto. La página lo confirma: “Gracias, nos pondremos en contacto”. Cierra la pestaña y espera tu respuesta.
Nunca llamas, porque nunca recibiste el mensaje. No llegó ningún correo, ni ese día ni nunca. El posible cliente se queda ahí en silencio y luego sale a buscar el siguiente negocio cuyo formulario sí funcione. Nada en la pantalla les avisó a ninguno de los dos que algo falló.
Cómo envía WordPress realmente este correo
Esta es la tubería, en términos simples. Cuando alguien envía un formulario de WordPress, el sitio llama a una función llamada wp_mail, que por defecto le pasa el mensaje a la función integrada mail() de PHP en lugar de a un servicio de correo dedicado. El correo de PHP no inicia sesión en ningún lado, no demuestra que de verdad eres tú quien lo envía y no pasa por el tipo de infraestructura verificada que Gmail u Outlook esperan de un remitente legítimo. Solo le pide a tu servidor web que saque un correo por la puerta y espera que todo salga bien. Antes eso bastaba. Hoy casi nunca basta, porque los proveedores de correo endurecieron sus defensas justo contra este tipo de envío sin autenticar y de bajo esfuerzo, y una simple llamada a mail() rara vez pasa el filtro.
El correo dice venir de ti, y nadie se lo cree
Tu formulario de contacto suele estar configurado para enviar “desde” una dirección como you@yoursite.com, o desde algo que ni siquiera existe, como wordpress@yoursite.com. El campo De dice que eres tú, pero el servidor que realmente hace el envío nunca fue autorizado para enviar correo en nombre de tu dominio. Todos los grandes proveedores de correo revisan esa autorización hoy en día. Cuando falta, no te devuelven el mensaje con un error claro que puedas notar. Lo descartan en silencio o lo archivan en algún lugar que nunca vas a abrir. Tu sitio no está roto de ninguna forma que puedas detectar mirándolo. Está haciendo una afirmación que no puede respaldar, y los proveedores dejaron de creerla a ciegas.
Tu hosting no envía el correo, o envía muy poco
No todos los planes de hosting permiten que un sitio envíe correos libremente. El hosting compartido en particular suele limitar cuántos mensajes puede enviar un dominio por hora, o bloquea directamente la función de correo de PHP, porque algún otro cliente del mismo servidor la usó alguna vez para enviar spam y el proveedor cerró toda la función. Si tu proveedor es de los estrictos, tu formulario puede verse perfecto (la página confirma, el código corre sin errores) mientras el envío real se pierde antes de salir del edificio. No vas a ver ningún mensaje de error, porque la falla ocurre en una infraestructura que no puedes ver por dentro.
Tu dominio no puede demostrar que el correo es legítimo
Incluso cuando el correo sí se envía, los proveedores que lo reciben revisan unos registros DNS llamados SPF y DMARC para decidir si confiar en él. Juntos, son la forma en que tu dominio declara qué servidores tienen permiso para enviar correo en su nombre y qué debe hacer un servidor receptor con un mensaje que no pasa esa revisión. En un sitio WordPress donde nadie los configuró a propósito, muchas veces faltan o están mal configurados, y el correo de tu dominio termina pareciéndose exactamente al tipo de mensaje que estos sistemas existen para filtrar.
Funcionaba, hasta que una actualización cambió algo
El núcleo de WordPress, tu tema y cada plugin del sitio se actualizan cada uno a su ritmo, y cualquiera de ellos puede cambiar en silencio la forma en que se envía el correo. Una actualización del plugin de formularios cambia su librería de correo. Un plugin de seguridad empieza a bloquear una conexión saliente que antes permitía. Un plugin de caché sigue mostrando la página de confirmación vieja incluso después de que el envío en el servidor empezó a fallar. Nada de esto aparece como error en tu Escritorio, porque desde el punto de vista de WordPress el formulario se envió bien. Lo que dejó de funcionar en silencio es la capa de abajo, y una actualización es la razón más común por la que esa capa cambia sin que nadie la toque a propósito.
La prueba de 10 minutos
Antes de arreglar nada, confirma qué está pasando en realidad. Esto toma unos diez minutos y te dice con cuál de las fallas de arriba estás lidiando.
- Haz un envío de prueba real, usando una dirección de correo que no sea de Gmail: una dirección del trabajo, una cuenta de Outlook, la que tengas. El filtro de spam de Gmail es tan agresivo por sí solo que una prueba solo con Gmail puede esconder un problema que otro proveedor sí habría detectado.
- Revisa la carpeta de spam o correo no deseado, no solo la bandeja de entrada, en la dirección con la que probaste. Un mensaje que está en spam es un problema distinto de un mensaje que nunca llegó, y te apunta hacia la sección de SPF y DMARC de arriba en lugar de a un bloqueo del hosting.
- Mira el registro de correo real, no el mensaje de confirmación. La mayoría de los proveedores tienen un registro de correo en cPanel o en su panel de control, o puedes instalar un plugin gratuito como WP Mail Logging, que registra cada correo que WordPress intenta enviar y si lo logró. Este solo paso te dice si WordPress siquiera lo intentó.
- Envía una segunda prueba a otro proveedor. Si llega a Outlook pero no a Gmail, es una señal fuerte de que se trata de un problema de autenticación propio de cómo un proveedor evalúa tu dominio, y no de un bloqueo general del hosting.
- Pasa tu dominio por el Chequeo de salud del sitio. Revisa tus registros SPF y DMARC (no DKIM, que necesita otro tipo de consulta) y te dice en menos de un minuto si tu dominio está configurado para demostrar que su correo es legítimo. Una alerta ahí suele explicar todo lo anterior.
Las opciones honestas para arreglarlo
Una vez que sabes con qué falla estás lidiando, la solución suele ser una de unas pocas cosas. Ninguna es un truco; cada una es una forma genuina de resolverlo.
Instala un plugin SMTP. Es la respuesta estándar de los desarrolladores, y es una respuesta justa. Un plugin SMTP desvía tu correo saliente a través de un servicio de correo real en lugar de la función mail() de PHP, lo que arregla el problema de autenticación de raíz, porque ahora el correo sí sale de una infraestructura en la que los proveedores ya confían. Toma unos veinte minutos si te sientes cómodo creando una clave de API y pegándola en una pantalla de configuración. Si no, es una hora de trabajo razonable para encargarle a un desarrollador.
Cámbiate a un servicio de formularios. Las herramientas hechas específicamente para manejar envíos de formularios, en lugar de un plugin montado sobre wp_mail, suelen enviar las notificaciones a través de su propia infraestructura de envío verificada, y así esquivan todo el problema. Pierdes un poco de control sobre el aspecto y el comportamiento exactos del formulario. Ganas un servicio cuyo único trabajo es asegurarse de que el mensaje llegue.
Que alguien administre el sitio por ti. Si prefieres no aprender qué significa SPF, es una postura válida, no una falla de tu parte. Este es exactamente el tipo de mantenimiento que se escapa en un sitio WordPress administrado por uno mismo: nadie lo nota hasta que un posible cliente llama a la competencia. Si prefieres dejar de ser quien revisa un registro de correo cada vez que una actualización rompe algo, salta a la opción para no volver a lidiar con esto.
Por qué esto se sigue rompiendo
Un sitio WordPress no es algo que se termina. Es una pila de piezas que se actualizan cada una por su lado (el núcleo, el tema, una docena de plugins, el hosting debajo de todo) y cualquiera de ellas puede mover el suelo que pisan las demás. Una actualización de un plugin dentro de seis meses puede volver a romper este mismo formulario de una forma completamente distinta, y no va a ser tu culpa, igual que no lo es ahora. Ese es el costo de tener software que nadie está vigilando activamente. La versión más extrema que hemos visto ni siquiera tenía que ver con un formulario: 32 enlaces de spam ocultos estaban inyectados en el código WordPress de una empresa de mudanzas fundada por veteranos, invisibles en la página, hundiendo en silencio su posición en los buscadores hasta que una auditoría los detectó. Un formulario de contacto roto es la falla que notas, porque los posibles clientes dejan de llamar. Muchas fallas de WordPress nunca se notan.
Si no quieres volver a depurar esto nunca
Si prefieres no ser quien revisa registros de correo y lee registros DNS cada vez que esto se rompe, eso es lo que Surmado Sites resuelve como parte de administrar el sitio: el hosting y la entrega de correo, además del mantenimiento que evita que un arreglo se deshaga con la siguiente actualización. Lo pides una vez, en palabras simples, y queda resuelto.
Preguntas frecuentes
¿Por qué el formulario dice “enviado” si no llega nada?
WordPress genera la confirmación de “mensaje enviado” en el momento en que se envía el formulario y se llama a wp_mail. No espera a que un servidor de correo le confirme si el mensaje de verdad se entregó, porque la mayoría de las configuraciones de formularios de contacto no están hechas para revisar eso. La confirmación significa que WordPress intentó el envío. No significa que alguien lo haya recibido.
¿Los envíos están llegando a spam?
A veces, pero no siempre. Si tus registros SPF o DMARC están mal configurados, el correo que sí se envía suele caer en spam, porque los proveedores que lo reciben no pueden verificar que de verdad viene de tu dominio. Si tu hosting está bloqueando el envío por completo, o un conflicto entre plugins lo detiene antes de salir de tu servidor, el correo nunca se envía, así que tampoco está en spam. Revisar un registro de correo, o el resultado de tu Chequeo de salud del sitio, te dice en cuál de las dos situaciones estás.
¿Por qué dejó de funcionar después de una actualización?
Porque algo en esa cadena de actualizaciones cambió cómo se envía el correo, o si se envía, y ninguno de esos cambios aparece como un error visible en ningún lugar de WordPress. Casi nunca es el plugin que sospecharías primero. Por eso vale la pena revisar el registro de correo justo después de cualquier actualización, algo que toma dos minutos, antes de empezar a buscar la falla a ciegas.
¿Necesito un plugin SMTP?
No siempre, pero muchas veces sí. Si los registros SPF y DMARC de tu dominio están bien y el problema real es que tu hosting bloquea o limita el correo de PHP, un plugin SMTP que envíe el correo a través de un servicio de correo real es la solución más directa. Si el problema son los registros DNS, arréglalos primero; un nuevo método de envío no va a ayudar si el propio dominio sigue sin poder demostrar que es legítimo. En cualquier caso, un plugin SMTP es una solución real y común, no un parche, y también es una cosa más que configurar y mantener funcionando, que es justo la parte que un servicio de formularios o un sitio administrado te quitan de encima.