Correos del formulario de contacto que van a spam — la solución al remitente del servidor web (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Vea cómo calificamos.

Los correos del formulario de contacto y del sitio web acaban en spam porque su servidor web los envía sin autenticar — sin autorización SPF y sin firma DKIM. La solución fiable es enrutar ese correo a través de SMTP autenticado, no añadir el servidor a una lista blanca. El 46,4% de los 261.086.232 dominios calificados en el censo de Defaults.Exposed (datos a fecha de 2026-06-29) no publica ningún registro SPF.

El orden de los pasos importa y la mayoría de los tutoriales lo hacen al revés. Ejecute un análisis gratuito para ver qué publica realmente su dominio; enrute el correo del sitio a través de SMTP autenticado (su proveedor de correo o un servicio de correo transaccional) para que reciba una firma DKIM real; corrija la dirección From del formulario; y solo añada la IP del servidor al SPF como último recurso.

¿Por qué los correos de mi sitio web van a spam?

Por quién los está enviando en realidad. Cuando un visitante envía su formulario de contacto, el correo no lo manda su proveedor de correo — el servidor web lo genera él mismo, normalmente mediante mail() de PHP. Desde el lado receptor, ese mensaje:

procede de una IP que su registro SPF no autoriza (su SPF cubre a su proveedor de correo, no a su hosting web);
no lleva ninguna firma DKIM, así que nada lo vincula criptográficamente a su dominio;
a menudo sale desde una IP de hosting compartido cuya reputación la fijan los sitios de cientos de desconocidos.

El correo sin autenticar desde una IP de reputación mixta es exactamente lo que los filtros de spam existen para atrapar — Gmail y Outlook ven un servidor cualquiera afirmando ser usted. El panorama general es sombrío: el 46,4% de los dominios no publica SPF en absoluto, y solo el 10,59% (27.640.987 de 261.086.232 dominios calificados, censo a fecha de 2026-06-29) aplica una política DMARC.

¿Por qué afecta esto especialmente a los sitios WordPress?

WordPress envía todo su correo — notificaciones de formularios, restablecimientos de contraseña, confirmaciones de pedido — a través de una sola función, wp_mail(), que por defecto envuelve el mail() de PHP en el servidor web. Todo sitio WordPress que no se haya reconfigurado deliberadamente es un remitente sin autenticar de fábrica. Los plugins de formularios (Contact Form 7, WPForms, Gravity Forms) entregan todos el correo a la misma función: parece un problema del plugin pero es un problema de transporte.

La solución no es otro plugin de formularios sino un plugin SMTP (WP Mail SMTP y sus equivalentes), que redirige todo lo que envía wp_mail() a través de una cuenta de correo real y autenticada — infraestructura que su SPF ya autoriza, con una firma DKIM adjunta.

¿Qué método de envío debería usar el sitio?

Método de envío	SPF	DKIM	¿Sobrevive a una migración de hosting?	Veredicto
`mail()` de PHP / `wp_mail()` por defecto desde la máquina web	falla	ninguna	n/a — roto en todas partes	el problema, no una opción
SMTP autenticado a través de su proveedor de correo (Google Workspace, Microsoft 365, etc.)	pasa	firmado	sí — independiente del hosting	la solución para la mayoría de los sitios
Servicio de correo transaccional (SES, Postmark, Brevo, etc.) con su dominio verificado	pasa	firmado	sí	la solución a gran volumen (e-commerce, formularios grandes)
IP del servidor web añadida a su registro SPF	pasa (solo SPF)	ninguna	no — se rompe en silencio cuando cambia la IP	solo como último recurso — vea más abajo

Para unas pocas notificaciones al día, SMTP a través del buzón que ya paga es el camino más corto; a volumen real, un servicio transaccional está hecho para ello. Ambos le dan DKIM — el atajo de la lista blanca de IP nunca lo hace.

¿Cómo arreglo la entregabilidad del correo del formulario de contacto?

Ejecute el análisis gratuito en defaults.exposed antes de tocar nada. Muestra qué SPF, DKIM y DMARC publica realmente su dominio — si está arreglando el transporte del formulario, un registro que falta, o ambas cosas. ¿No hay SPF en absoluto? Empiece por cómo arreglar SPF.
Cree una identidad SMTP dedicada para el sitio — p. ej. [email protected] en su proveedor de correo, o un dominio de envío verificado en un servicio transaccional. Use una contraseña de aplicación o clave API que pueda revocar, no la contraseña del buzón de una persona.
Enrute el correo del sitio a través de ella. WordPress: instale un plugin SMTP y apúntelo a esa cuenta. Otras plataformas: configure el mailer del framework en lugar del mail() local.
Corrija la dirección From (el antipatrón de más abajo): From debe ser su propio dominio; el visitante va en Reply-To.
Si el remitente es un servicio transaccional, añada sus registros DKIM (normalmente un par de CNAME) para que el correo se firme con su dominio — los pasos de DNS son análogos a los de las guías de configuración de SPF.
Envíe una prueba desde el formulario y vuelva a analizar. Las cabeceras deben mostrar spf=pass y dkim=pass para su dominio; después resuelva cualquier otra cosa que señale el análisis mediante arreglar SPF y arreglar DKIM.

¿Por qué el formulario envía “desde” la dirección de correo del visitante?

Es la herida autoinfligida más común en la configuración de formularios, y muchos plugins solían hacerlo por defecto: la notificación llega From: la dirección del visitante, para que pueda pulsar responder. Parece cómodo, y es una falsificación. Su servidor no tiene ningún derecho a enviar correo como [email protected] — falla SPF y DKIM para gmail.com, y la política DMARC de Gmail indica a los receptores que lo manden a spam o lo rechacen. Arreglarlo no cuesta nada:

From: una dirección de su propio dominio (la identidad SMTP del paso 2)
Reply-To: la dirección del visitante — la respuesta sigue llegándole directamente

Todos los plugins de formularios habituales lo permiten; son dos campos en los ajustes de la notificación.

¿Por qué no añadir sin más la IP del servidor a mi registro SPF?

Es la solución a la que primero recurren la mayoría de los hilos de foros, y es el último recurso por algo. Añadir ip4:<server> (o un mecanismo a para su hosting web) al SPF hace que la comprobación básica pase — pero:

En hosting compartido autoriza a desconocidos. La IP pertenece a la máquina, no a usted; cualquier otro sitio en ese servidor puede ahora enviar correo que pasa SPF como su dominio.
Se rompe en silencio. Los hostings migran servidores y rotan IPs sin avisarle; su SPF sigue autorizando una dirección que usted dejó hace meses.
No le da DKIM. SPF por sí solo se rompe con el reenvío y no puede llevarle hacia la aplicación de DMARC como sí puede hacerlo una firma.

Reserve esta vía para el caso genuinamente limitado: un servidor dedicado con una IP estática que usted controla y una aplicación que no puede hablar SMTP — y acompáñela de firma DKIM en la máquina si puede.

¿SPF siquiera comprueba la dirección que mi formulario pone en “From”?

No — y esto hace tropezar a la mitad de los diagnósticos caseros. Los receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom), no contra la cabecera From. Los servidores web a menudo estampan su propio nombre de host en el Return-Path, de modo que su registro SPF nunca llegó a consultarse — el receptor comprobó el SPF de srv0421.examplehost.com. El SMTP autenticado también arregla esto: el Return-Path pasa a ser su dominio, así que el SPF aprobado por fin cuenta para usted. Es también la razón por la que DKIM importa — la alineación de DMARC necesita un resultado positivo ligado al dominio de From, y una firma DKIM viaja con el mensaje.

Preguntas frecuentes

¿Un plugin SMTP arreglará también los correos de restablecimiento de contraseña y de WooCommerce? Sí. En WordPress todo fluye a través de wp_mail(), así que redirigirlo arregla las notificaciones de formularios, los restablecimientos de contraseña y los correos de pedidos de una sola vez.

¿Sigo necesitando registros SPF y DKIM si uso un plugin SMTP? Sí — el plugin cambia qué infraestructura envía su correo; los registros son lo que la autoriza. Si su dominio está entre el 46,4% de los 261.086.232 dominios calificados sin registro SPF (censo, 2026-06-29), el SMTP autenticado por sí solo no le salvará. La lista de comprobación de correo para dominios nuevos cubre el conjunto completo de registros.

Los correos de mi formulario pasan SPF pero siguen fallando DMARC — ¿por qué? Casi siempre es el antipatrón de suplantación del From descrito arriba, o que SPF pasa para el dominio del Return-Path del hosting en lugar del suyo. Corrija primero From/Reply-To; si sigue fallando, la pieza que falta es una firma DKIM alineada — vea “DKIM signature not valid”. Si también fallan herramientas SaaS más allá del sitio web, la guía de SPF fallando con SaaS cubre el orden de arreglo.

¿Merece la pena todo esto por un formulario de contacto con poco tráfico? El formulario suele ser por donde entra el dinero — una consulta perdida es un cliente que nunca supo que perdió. Y la solución es gratis; la barrera es saber que el servidor web era el remitente sin autenticar desde el principio.

Envíe el informe al propietario

Si usted es el desarrollador o contratista que arregla esto: cuando la prueba del formulario pase, vuelva a ejecutar el análisis gratuito y reenvíe el informe calificado al propietario del sitio — un registro fechado y en lenguaje claro de que el dominio se autentica correctamente, y el documento que necesitará para la próxima renovación del ciberseguro o cuestionario de seguridad de clientes. Si usted es el propietario y lee esto porque dejaron de llegar consultas: envíe esta página y su informe de análisis a quien gestione su sitio web — un trabajo de una tarde con un antes y un después que pueden enseñarle.

Compruebe su dominio → · ¿SPF fallando con sus herramientas SaaS? → · Arreglar SPF → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.