Formularios por dentro: envío, validación, antispam y RGPD bien resueltos

Una academia de idiomas con la que trabajamos llegó al estudio convencida de que su web había dejado de funcionar como fuente de alumnos. Las visitas seguían igual, pero los contactos habían caído casi a cero. El formulario se veía perfecto y, al enviarlo, mostraba un «¡Gracias!» muy simpático. El problema estaba después: el servidor enviaba los avisos con la función de correo del hosting y, tras un cambio en el DNS, todos acababan en la carpeta de spam de la academia. Durante semanas, cada persona que escribía recibía las gracias y nadie leía su mensaje.

El diseño de un formulario, qué campos pedir y cómo mostrar los errores, es la parte que se ve, y la tratamos en formularios de contacto que se rellenan. Esta guía va de la otra mitad: lo que pasa por dentro. Validar lo que llega, guardarlo, avisar a quien tiene que responder, frenar a los bots y cumplir con la protección de datos.

Es la parte menos vistosa del desarrollo web y, a la vez, la que más tranquilidad da cuando está bien hecha. Un formulario sólido es aquel en el que cada mensaje enviado por una persona llega, y ninguno enviado por un bot molesta.

01Qué pasa cuando alguien pulsa «Enviar»

Un formulario bien construido recorre siempre las mismas etapas, en este orden:

1. 01Validación en el navegador. Antes de enviar, se comprueba que los campos obligatorios están rellenos y que el correo tiene forma de correo. La persona recibe ayuda inmediata.
2. 02Envío seguro. Los datos viajan por HTTPS, con el método POST, a un punto de recepción en el servidor.
3. 03Comprobaciones antispam. El servidor revisa las señales de que el envío lo ha hecho una persona.
4. 04Validación en el servidor. Se vuelven a comprobar todos los campos, esta vez sin posibilidad de trampa.
5. 05Almacenamiento. El mensaje se guarda en una base de datos o en el CRM.
6. 06Notificaciones. Se avisa al equipo por correo y, si procede, se envía un acuse de recibo a la persona.
7. 07Respuesta. El navegador muestra una confirmación clara y la persona sabe qué va a pasar después.

Cada etapa tiene su razón de ser, y saltarse alguna es lo que provoca la mayoría de las pérdidas de contactos que vemos.

02Validación en dos capas: ayuda en el navegador, garantía en el servidor

En el navegador: atributos HTML que ya hacen mucho

HTML trae de serie una validación muy capaz. Con los atributos correctos, el navegador comprueba los datos, muestra el teclado adecuado en el móvil y ofrece autocompletar:

<form action="/api/contacto" method="post" novalidate>
  <label for="nombre">Nombre</label>
  <input id="nombre" name="nombre" autocomplete="name" required maxlength="80">
  <label for="email">Correo electrónico</label>
  <input id="email" name="email" type="email" autocomplete="email" required maxlength="120"
         aria-describedby="email-error">
  <p id="email-error" class="error" hidden>Escribe un correo con el formato nombre@dominio.es</p>
  <label for="telefono">Teléfono (opcional)</label>
  <input id="telefono" name="telefono" type="tel" autocomplete="tel" maxlength="20">
  <label for="mensaje">¿En qué podemos ayudarte?</label>
  <textarea id="mensaje" name="mensaje" required minlength="10" maxlength="3000"></textarea>
  <button type="submit">Enviar mensaje</button>
</form>

El atributo novalidate desactiva las burbujas de error nativas, que no se pueden diseñar, para mostrar mensajes propios con JavaScript, vinculados a cada campo con aria-describedby para que los lectores de pantalla los anuncien. La lógica de validación sigue siendo la del navegador, accesible desde la API de validación de restricciones (checkValidity() y la propiedad validity de cada campo).

En el servidor: la única validación que cuenta

Todo lo que viene del navegador se puede manipular. Un bot no rellena tu formulario; envía directamente una petición a tu servidor con lo que quiera. Por eso el servidor repite todas las comprobaciones y añade las suyas:

• →Esquema de datos. Qué campos se esperan, de qué tipo, con qué longitud máxima. Librerías como Zod (en JavaScript) o los validadores de cada framework permiten definirlo en un solo sitio y reutilizarlo en el navegador y en el servidor.
• →Normalización. Recortar espacios, pasar el correo a minúsculas, unificar el formato del teléfono.
• →Rechazo de lo inesperado. Campos que no existen en el formulario, textos de 50.000 caracteres, cabeceras manipuladas.
• →Escape al mostrar. El contenido recibido se trata siempre como texto, nunca como HTML, cuando se muestra en un panel o en un correo. Así se evita que alguien inyecte código.
• →Respuesta útil. Si algo falla, el servidor devuelve qué campo y por qué, para que la interfaz lo muestre junto a ese campo.

03Enviar y guardar sin perder un solo mensaje

Guarda primero, avisa después

La regla que más contactos salva: cada envío se guarda antes de notificarse. Si el correo de aviso falla, el mensaje sigue en la base de datos, en el CRM o, como mínimo, en un registro, y se puede recuperar. Un formulario que solo envía un correo depende de que ese correo llegue, y los correos a veces no llegan.

Correo transaccional, con remitente autorizado

Para los avisos, lo que funciona es enviar mediante un servicio de correo transaccional (Postmark, Amazon SES, Brevo, Mailgun) o por SMTP autenticado de tu proveedor de correo, con tu dominio correctamente configurado en SPF y DKIM. Es justo lo que le faltaba a la academia del principio, y lo explicamos paso a paso en correo profesional con SPF, DKIM y DMARC. Dos detalles más:

• →El aviso al equipo lleva la cabecera Reply-To con el correo de la persona, para responder con un clic.
• →El acuse de recibo a la persona es breve, con tu marca, un resumen de lo que envió y cuándo vas a responder. Envíalo solo a la dirección introducida y sin contenido promocional, para que no se convierta en una vía de spam hacia terceros.

Sin envíos duplicados

Un doble clic o una conexión lenta pueden generar dos envíos idénticos. Lo resuelven tres medidas sencillas: desactivar el botón y mostrar un estado de «Enviando…» al pulsarlo, generar un identificador único por envío que el servidor reconozca si llega repetido, y tras un envío clásico sin JavaScript, redirigir a una página de confirmación (el patrón Post/Redirect/Get) para que recargar no reenvíe el formulario.

Si además el formulario tiene que llevar los datos a un CRM, a una agenda o a otra herramienta, las técnicas de reintentos y colas que contamos en APIs e integraciones se aplican aquí tal cual.

04Antispam por capas, sin castigar a las personas

El spam en formularios lo envían sobre todo programas automáticos que recorren la web buscando formularios. La mejor defensa no es un único obstáculo grande para todo el mundo, sino varias capas pequeñas que las personas ni notan.

En nuestros proyectos solemos combinar las cuatro primeras capas, que no recogen datos de terceros, y añadimos un desafío invisible solo cuando el volumen de spam lo pide. Los captchas visuales los evitamos: son una barrera para personas con discapacidad visual o cognitiva, como recoge el W3C en su documento sobre la inaccesibilidad de los CAPTCHA, y la norma WCAG 2.2 pide alternativas a las pruebas cognitivas en los procesos de autenticación.

Así se monta un honeypot accesible, que los lectores de pantalla tampoco anuncian:

<div class="hp" aria-hidden="true">
  <label for="web">Deja este campo vacío</label>
  <input id="web" name="web" type="text" tabindex="-1" autocomplete="off">
</div>

.hp { position: absolute; left: -10000px; width: 1px; height: 1px; overflow: hidden; }

En el servidor, si el campo web llega con contenido o el formulario se envió en menos de tres segundos, se responde con un mensaje de éxito igual al normal y se descarta el envío. Así el bot no aprende qué lo ha delatado.

05RGPD: lo que pide la protección de datos en un formulario

Un formulario recoge datos personales, así que el Reglamento General de Protección de Datos se aplica desde el primer campo. Lo que funciona en la práctica:

Informar junto al botón, por capas

El artículo 13 del RGPD obliga a informar en el momento de recoger los datos. La AEPD recomienda hacerlo por capas: una primera capa breve junto al formulario y un enlace a la política de privacidad completa. La primera capa incluye:

• →Responsable: quién trata los datos (nombre de la empresa).
• →Finalidad: para qué (responder a tu consulta y enviarte el presupuesto).
• →Legitimación: la base legal (tu solicitud, o tu consentimiento si es para otra cosa).
• →Destinatarios: si se ceden a terceros o se usan proveedores.
• →Derechos: que puede acceder, rectificar y suprimir sus datos, y cómo.

Una casilla por cada consentimiento, desmarcada

Si además quieres enviar comunicaciones comerciales, necesitas un consentimiento específico: una casilla separada, desmarcada por defecto y con un texto claro. La Ley de Servicios de la Sociedad de la Información (LSSI) exige ese consentimiento previo para comunicaciones comerciales por correo. Las casillas premarcadas o los consentimientos agrupados no son válidos.

Pedir lo justo y guardarlo el tiempo justo

• →Minimización. Cada campo debe tener un motivo. Si no vas a llamar, el teléfono puede ser opcional o desaparecer.
• →Plazo de conservación. Define cuánto tiempo guardas los mensajes que no se convierten en clientes y bórralos al cumplirse. Incluye los que quedan en los buzones de correo.
• →Registro del consentimiento. Guarda la fecha, el texto aceptado y la versión de la política vigente.
• →Seguridad. HTTPS en todo el sitio, acceso restringido al panel donde se consultan los envíos y proveedores con contrato de encargo del tratamiento.
• →Datos sensibles. En clínicas o despachos, evita pedir información de salud o detalles delicados en un formulario general y no la reenvíes en claro por correo.

El banner de cookies y la analítica son otra pieza del mismo puzle, y los tratamos en RGPD y cookies en tu web.

Clave: el texto legal de un formulario también se diseña. Breve, claro y junto al botón, transmite que esa empresa cuida de los datos antes incluso de responder.

06Checklist para probar un formulario antes de publicarlo

Esta es la batería de pruebas que pasamos a cada formulario. Lleva media hora y nos ha ahorrado muchas sorpresas:

1. 01Envío correcto desde móvil y escritorio, con aviso recibido en la bandeja de entrada (no en spam) de Gmail y Outlook.
2. 02Acuse de recibo correcto, con la marca y el texto revisado.
3. 03El mensaje aparece en la base de datos o en el CRM con todos los campos.
4. 04Errores de cada campo: vacío, formato incorrecto, demasiado largo. El mensaje aparece junto al campo y el lector de pantalla lo anuncia.
5. 05Doble clic en «Enviar»: solo se crea un envío.
6. 06Envío con el honeypot relleno y envío inmediato: ambos se descartan y la persona ve el mensaje de éxito.
7. 07Varios envíos seguidos desde la misma IP: el límite actúa.
8. 08Servicio de correo caído (simulado): el mensaje queda guardado y el error, registrado.
9. 09Navegación con teclado de principio a fin, con el foco visible en cada campo.
10. 10Texto informativo de privacidad visible y enlace a la política completa.

Un formulario es, muchas veces, la primera conversación entre una empresa y su próximo cliente. Que llegue entera, rápido y bien cuidada es una forma de respeto hacia esa persona. En SIMA los construimos así dentro del desarrollo web, diseñando a la vez la experiencia y todo lo que ocurre por detrás. Si sospechas que tu formulario pierde mensajes o recibe más spam del razonable, escríbenos y lo revisamos contigo.