Si tu formulario muestra «mensaje enviado» pero el correo no te llega, casi nunca falla el formulario: falla el envío del correo que sale de tu web. «Enviado» solo quiere decir que la web pasó el mensaje a su sistema de correo, no que haya llegado a tu bandeja, y eso se comprueba con una prueba sencilla y se arregla configurando bien quién envía y cómo.
Aquí tienes qué está pasando, cómo comprobarlo tú mismo y qué pedir a quien te lleva la web. Usamos WordPress como ejemplo, pero la lógica vale para casi cualquier web.
Por qué el formulario dice «enviado» y no llega nada
WordPress manda todos sus correos, también los de los formularios, con una función interna llamada wp_mail(). Su documentación oficial avisa de que, cuando responde que todo ha ido bien, no significa que el destinatario lo haya recibido: solo que el método de envío aceptó la petición sin errores.
Es como echar una carta al buzón: el formulario te dice «carta echada», y es verdad, pero si el sobre no lleva un remite fiable, el destino puede apartarla o devolverla sin que te enteres.
Lo grave es que no se ve: un cliente pide presupuesto, la web le da las gracias y tú nunca recibes nada. Él cree que no le has contestado y tú, que no escribe nadie.
Las cinco causas más habituales
- El remitente no está autenticado o no es de tu dominio. Google pide a cualquier remitente que su dominio esté autenticado (con SPF o DKIM, ver más abajo) y que no suplante a nadie en el campo «De». Si el formulario envía como si fuera el cliente o desde una dirección que tu dominio no autoriza, el correo resulta sospechoso. En el foro oficial de Webempresa hay un caso resuelto en 2024: con Contact Form 7 el formulario enviaba, pero Google rechazaba los mensajes por ir sin autenticar, y se arregló enviando por SMTP con una cuenta del propio dominio.
- El servidor no envía bien «a la antigua». Por defecto WordPress usa la función mail de PHP. La ficha oficial del plugin WP Mail SMTP explica que muchos alojamientos no están preparados para enviar así y que Gmail, Yahoo, Office 365 o Zoho comprueban que el remitente sea legítimo: sin autenticación, el correo puede ir a spam o perderse.
- El registro SPF está mal o duplicado. Con dos registros SPF, o con uno que no incluye a quien envía los correos del formulario, la comprobación falla.
- El destinatario está mal escrito o un filtro se lo come. Una letra de más, una dirección antigua que nadie mira o una regla del buzón que mueve esos mensajes a otra carpeta. Es lo primero que hay que descartar.
- Una actualización rompió algo. Se actualiza un plugin o cambias de tema o de servidor, y el formulario deja de enviar.
La prueba de extremo a extremo, paso a paso
Antes de tocar nada, comprueba qué pasa de verdad. No hace falta saber de código.
- Envía desde otro dispositivo. Usa el móvil con datos móviles, igual que haría un cliente.
- Usa dos correos distintos. Si puedes, que el formulario avise a un correo de tu dominio y, para la prueba, también a un Gmail. Si llega a uno y no al otro, ya tienes una pista.
- Apunta la hora exacta del envío y el texto que escribiste, por ejemplo «prueba 4 de noviembre, 11:05».
- Mira la bandeja de entrada y la de spam de los dos correos.
- Mira el registro de envíos, si lo tienes. Plugins del directorio oficial como WP Mail Logging apuntan cada correo que sale de la web y permiten verlo y reenviarlo. Si usas Contact Form 7, Flamingo guarda una copia de cada mensaje dentro de la propia web.
Con eso llegarás a una de tres conclusiones:
- El mensaje no aparece en ningún registro: falla el formulario o algún plugin.
- Aparece en el registro pero no llega: falla la entrega del correo.
- Llega, pero a spam: falta autenticación o el remitente no está bien configurado.
Si guardas copia de los mensajes, son datos personales: guarda solo lo necesario, bórralas cada cierto tiempo y comprueba que tu política de privacidad lo recoge.
La solución habitual: enviar por SMTP con una cuenta de tu dominio
SMTP es la forma estándar de enviar correo con una cuenta real, con usuario y contraseña. La web envía como lo haría tu programa de correo, con la identidad de tu dominio (por ejemplo, avisos@tunegocio.es).
En WordPress se hace con un plugin. Un ejemplo muy usado es WP Mail SMTP, que envía por SMTP o por la conexión directa de varios proveedores de correo. Es de la empresa de WPForms y no es la única opción: hay alternativas como Easy WP SMTP, Post SMTP o FluentSMTP. Lo importante es que el envío vaya autenticado.
Los datos que te pide (servidor, cifrado, puerto, usuario y contraseña) te los da tu hosting o tu proveedor de correo. En Webempresa, por ejemplo, están en la sección de correos de su panel. Si envías por Gmail, la conexión también tiene que ir autenticada, por ejemplo con una contraseña de aplicación.
Un consejo práctico: que el remitente («De») sea una cuenta de tu dominio y que el correo del cliente vaya en «Responder a». Así respondes al cliente con un clic y no suplantas a nadie, que es lo que pide Google.
SPF, DKIM y DMARC sin jerga
Son tres registros que se ponen en el DNS de tu dominio. El DNS es la ficha pública del dominio: dice a dónde apunta tu web y quién gestiona tu correo.
| Registro | Qué hace | Lo que debes saber |
|---|---|---|
| SPF | Dice qué servidores pueden enviar correo en nombre de tu dominio. | Solo puede haber uno. Si añades un servicio, se edita el que ya existe. |
| DKIM | Firma cada correo para demostrar que sale de tu dominio. | Lo activa tu proveedor de correo o tu hosting. |
| DMARC | Indica al receptor qué hacer con los correos que no pasan SPF ni DKIM. | Se empieza con la política «none», que solo informa. |
Un solo SPF. La norma técnica del SPF (RFC 7208) dice que un dominio no debe tener más de un registro SPF: con dos, la comprobación da error. Además, admite como máximo 10 consultas encadenadas, como los «include». Por eso, si tu formulario o un servicio nuevo envía en tu nombre, edita el SPF existente para incluirlo, no crees otro. Google lo explica así: un formulario que envía mensajes automáticamente es un remitente de tu dominio y tiene que estar en el SPF.
DMARC, con calma. Tiene tres políticas: none (solo informa), quarantine (manda a spam) y reject (rechaza). Google recomienda empezar con none y esperar 48 horas después de configurar SPF y DKIM.
En muchos hostings, por ejemplo Webempresa, SPF y DKIM se generan solos en su DNS. Si el dominio y el correo están en sitios distintos, hay que revisarlo. Si no tienes acceso al DNS o no sabes quién lo administra, no lo toques: pide ayuda.
¿Te afectan las reglas de Gmail y Outlook?
Desde el 1 de febrero de 2024, Google pide a todos los remitentes SPF o DKIM en el dominio, DNS directo e inverso válidos, conexión cifrada (TLS), pocas quejas por spam, un formato correcto y no suplantar a nadie en el «De». Las exigencias reforzadas (SPF, DKIM y DMARC a la vez, con el dominio alineado) son para quien envía más de 5.000 mensajes al día.
Microsoft hizo algo parecido en Outlook.com (Hotmail y Live): desde mayo de 2025, los mensajes de dominios que envían más de 5.000 correos al día y no cumplen van a correo no deseado.
Un formulario de un negocio local no se acerca a ese volumen: las reglas reforzadas no son tu caso, pero las básicas sí. Las campañas de correo a clientes son otra historia: la contamos en nuestras estrategias de email marketing.
Qué pedir a tu hosting o a quien lleva tu web
La guía de Google para formularios lo resume: el fallo suele estar en cómo se autentica el correo que envía el formulario, no en el formulario. Google no da soporte de servicios de terceros, así que pregunta a quien corresponda, por escrito:
- ¿Mi web envía los correos por SMTP autenticado o con la función mail del servidor?
- ¿Desde qué dirección salen los avisos del formulario? ¿Es de mi dominio?
- ¿Mi dominio tiene un único registro SPF que incluye a quien envía esos correos? ¿Tiene DKIM?
- ¿Hay un registro donde ver qué pasó con mi prueba de las 11:05?
- ¿Se guarda copia de cada mensaje dentro de la web?
- Si hay que cambiar algo en el DNS, ¿quién lo hace: el hosting, quien me hizo la web o yo?
Si el correo rebota con un aviso que menciona DMARC, por ejemplo con el código 550-5.7.26, Google indica que lo más probable es que el SPF no incluya a todos los que envían en tu nombre. Pasa ese aviso tal cual a quien lo vaya a arreglar.
El hosting puede decirte si el envío sale y qué dicen sus registros; quien lleva la web configura el plugin y el SMTP; el DNS lo toca quien administra el dominio. En nuestra guía sobre qué mirar al contratar un hosting explicamos qué cubre cada uno y qué accesos debes tener tú.
Cómo evitar que vuelva a pasar
- Guarda copia de los mensajes en la web, con Flamingo o la opción de tu plugin, para no perder una consulta aunque el correo falle.
- Ten un registro de envíos. WordPress lanza un aviso interno cuando un envío falla al salir y los plugins de registro lo apuntan. Solo detecta los fallos de salida: si el buzón de destino aparta el mensaje, no lo verás. Por eso la prueba sigue haciendo falta.
- Haz una prueba al mes y otra después de cada actualización de WordPress, del tema o del plugin del formulario.
- Ofrece otra vía de contacto visible, como el teléfono o WhatsApp en tu web, para que nadie se quede sin respuesta.
Probar el formulario es de lo que más se olvida, como contamos en los errores comunes de diseño web. También es parte de un buen mantenimiento: actualizar y comprobar que los mensajes siguen llegando. Si prefieres no estar pendiente, nuestro servicio de mantenimiento web también se encarga de los formularios.
Si tienes un negocio en La Rioja
Lo primero es saber quién tiene cada pieza. Haz una lista con tres líneas: dónde está alojada la web, dónde está el correo y dónde está el dominio con su DNS. Pueden ser tres sitios distintos, a veces a nombre de quien hizo la web hace años. Con esa lista sabes a quién llamar.
Ejemplo inventado para explicarlo: una clínica de fisioterapia de Haro tiene la web en WordPress y el correo en Google Workspace. El formulario dice «enviado», pero las consultas no llegan; en la prueba con un Gmail, aparecen en spam. La causa: la web enviaba con la función mail del servidor, desde una dirección que el SPF no incluía. La solución: enviar por SMTP con una cuenta del dominio, revisar el SPF que ya existía sin crear otro y repetir la prueba.
Si te interesa cómo están las empresas de aquí, tienes los datos del INE sobre empresas con web en La Rioja. Y si tu formulario no llega y no sabes por dónde empezar, cuéntanoslo y te decimos qué miraríamos primero.
