Correo desde su sitio web y formularios

Módulo 7: Newsletters y correo desde su sitio web · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Después de esta lección sabrá configurar el correo de su sitio web (formularios de contacto, confirmaciones de pedido, avisos de WordPress) para que llegue correctamente, no genere problemas con DMARC y no permita que abusen de su paquete.

Conceptos clave: PHP mail(), SMTP con inicio de sesión, remitente de sobre (envelope sender), From frente a Reply-To, nunca usar la dirección del visitante como From, plugin SMTP, correo transaccional, spam de formularios, captcha, honeypot, límite de envío, entrega local cuando el MX apunta a otro sitio

Su sitio web también es un programa de correo

Su sitio web envía más correo del que imagina. Un formulario de contacto le envía cada mensaje a usted. Una tienda online envía confirmaciones de pedido, facturas y avisos de envío. WordPress envía correo cuando hay un nuevo comentario, una actualización o un restablecimiento de contraseña. Para el destinatario, es simplemente correo de su dominio, y se comprueba con el mismo rigor que el correo de su buzón: SPF, DKIM, DMARC, reputación.

Sin embargo, el correo del sitio web falla con más frecuencia que el correo normal. Esto suele deberse a una de tres cosas: la forma de envío, la dirección del remitente o el abuso del formulario.

Forma 1: PHP mail()

La forma más sencilla para que un sitio web envíe correo es la función PHP mail(). El sitio web entrega entonces el correo directamente al programa de correo del servidor web, sin iniciar sesión. Suele funcionar, pero tiene inconvenientes:

• El remitente de sobre (Return-Path) suele convertirse en la cuenta del sistema de su paquete, como usuario@server.hosting.example, y no su propia dirección. El SPF se comprueba entonces para el dominio del servidor, y por tanto no está alineado con el dominio de su From (lección 7.1).
• Que se añada o no una firma DKIM de su dominio depende del servidor. En algunos servidores sí, en otros no.
• No ve ningún resultado. Si el correo no llega o recibe un bounce, este va a la cuenta del sistema, que nadie revisa.
• Sin límite por formulario. Si se abusa del formulario, el servidor envía correo en su nombre hasta alcanzar el límite de su paquete.

Forma 2: SMTP con inicio de sesión (mejor)

Haga que su sitio web envíe correo de la misma forma que su programa de correo: iniciando sesión en el servidor de correo saliente con un buzón real, mediante el puerto 587 (STARTTLS) o 465 (SSL/TLS), con la dirección de correo completa como nombre de usuario (lecciones 1.4 y 2.1). De este modo:

• el remitente de sobre es su propia dirección y el correo se firma como el correo normal de su dominio;
• los bounces llegan a un buzón que usted puede leer;
• el correo enviado aparece, si así lo desea, en la carpeta Enviado;
• puede establecer un límite de envío propio para cada buzón.

En WordPress, esto se hace con un plugin SMTP. Este sustituye la función de correo estándar de WordPress por el envío mediante SMTP. Se introducen los mismos datos que en un programa de correo: servidor, puerto, seguridad, nombre de usuario y contraseña. Para ello, cree preferiblemente un buzón aparte, por ejemplo website@example.com. Si algún día roban la contraseña, su propio buzón queda a salvo, y puede ver de un vistazo qué correo procede del sitio web.

Para un sitio PHP propio existen bibliotecas que envían correo mediante SMTP, como PHPMailer. Guarde la contraseña en un archivo de configuración fuera de la carpeta web, no en el código de una página.

En WebOké, los datos para SMTP están en el manual de DirectAdmin 8.1, con el nombre del servidor de su paquete; en otros proveedores se encuentran en el manual o en el correo de bienvenida, y funciona de la misma manera.

¿Mucho correo transaccional? Use un servicio

Si envía cientos de confirmaciones de pedido al día, merece la pena contratar un servicio transaccional: un servicio de envío para correo automático. Este cuenta con buena reputación y muestra qué ocurrió con cada correo. Vincula el dominio de la misma manera que con un servicio de newsletters (DKIM mediante CNAME, lección 7.1). Mantenga separados el correo transaccional y las newsletters: una campaña fallida no debe afectar al correo de confirmación de sus pedidos.

La regla de oro: la dirección del visitante nunca es el remitente

En un formulario de contacto resulta tentador hacer que el correo se envíe "de parte" del visitante. Así podría hacer clic directamente en Responder en su programa de correo. Esto se vería así:

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Pero su servidor no tiene ningún permiso para enviar correo en nombre de example.net. Suponga que example.net tiene una política DMARC p=reject. El servidor receptor (el suyo, o el de Gmail si redirige su correo) ve un correo con From example.net que no procede del SPF ni del DKIM de example.net, y lo rechaza. Muchos dominios de correo grandes tienen una política estricta: en una comprobación realizada el 8 de noviembre de 2026, dominios como yahoo.com, aol.com, ziggo.nl y kpnmail.nl tenían una política DMARC p=reject, y icloud.com, gmx.de y web.de tenían p=quarantine. Un visitante con una dirección de ese tipo rellena su formulario, y usted nunca recibe el mensaje, o lo recibe en su carpeta de spam. Los dominios con p=none (como en ese momento gmail.com y hotmail.com) pueden endurecer su política en cualquier momento, y Google indica expresamente en sus directrices que no se deben imitar direcciones de Gmail como From. Así que nunca dé por hecho que todo saldrá bien.

La forma correcta:

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

El remitente es su propia dirección, de modo que SPF, DKIM y DMARC son correctos. La dirección del visitante aparece en Reply-To. Si hace clic en Responder, su respuesta va a Pieter. En la mayoría de los plugins de formularios encontrará esto en la configuración del correo: ponga en Remitente (From) una dirección fija de su propio dominio, y en Reply-To el campo en el que el visitante introduce su dirección.

Proteger los formularios contra el abuso

Un formulario sin protección, tarde o temprano, será encontrado por bots. En el mejor de los casos, usted recibirá spam. En el peor, lo utilizarán para enviar spam a terceros: si su formulario envía una confirmación "a la dirección que introduce el visitante", un bot puede introducir ahí cualquier dirección del mundo, con texto propio en el mensaje. En ese caso, su dominio envía spam, con todas las consecuencias que eso tiene para su reputación (lección 5.2).

Protección por capas:

• Captcha o una verificación invisible (como reCAPTCHA o Turnstile) detiene a la mayoría de los bots.
• Honeypot: un campo oculto que las personas no ven pero que los bots sí rellenan. ¿Se rellena? Entonces el mensaje no se envía.
• Nada de texto libre en una confirmación al visitante, o directamente ninguna confirmación a la dirección indicada. Un simple aviso "Gracias, hemos recibido su mensaje" en la página es suficiente.
• Un límite de envío por buzón para el buzón del sitio web, inferior al de su paquete.
• Actualizar el software. Los plugins antiguos son una vía conocida de abuso.

¿Nota que su paquete envía de repente mucho correo, o recibe un aviso de que se ha alcanzado el límite diario mientras usted apenas envía correo? Cambie entonces de inmediato las contraseñas y averigüe qué formulario o script está enviando el correo (lección 3.4).

El correo está en otro sitio, el sitio web aquí

Un error frecuente: su sitio web está con un proveedor y su correo con otro (por ejemplo, Microsoft 365 o Google Workspace). Su MX apunta a ese otro proveedor. Pero el servidor web sigue pensando que él mismo gestiona el correo de su dominio, porque el dominio también está dado de alta en su propio paquete. El correo del formulario a info@example.com se entrega entonces de forma local, en un buzón del servidor web que nadie consulta, o bien da un error como 550 ... mailbox unavailable.

La solución consiste en indicar en el panel del servidor web que el correo se gestiona en otro lugar. En DirectAdmin de WebOké, esto corresponde a la casilla "Usar este servidor para gestionar mis correos electrónicos" en Registros MX (desactivarla). Otros paneles tienen opciones similares, como "enrutamiento de correo: externo" en cPanel. Aún mejor: haga que el sitio web envíe correo mediante SMTP con un buzón del proveedor donde realmente está su correo.

Resumen

• El correo del sitio web se comprueba con el mismo rigor que el correo normal. Haga que el sitio envíe correo mediante SMTP con inicio de sesión, no mediante mail().
• Use un buzón aparte para el sitio web, con su propio límite de envío.
• La dirección del visitante pertenece a Reply-To, nunca a From. De lo contrario, falla DMARC, y en los dominios con p=reject (como yahoo.com, ziggo.nl, kpnmail.nl) el correo se rechaza.
• Proteja los formularios con captcha, honeypot y sin confirmaciones de texto libre a las direcciones indicadas.
• Si su correo está con otro proveedor, desactive la entrega local en el servidor web o envíe correo mediante SMTP con ese proveedor.

Cuestionario

Ejercicio

Ejercicio O7.3: Revisar el correo del sitio web. Rellene un formulario en su propio sitio web con una dirección de Gmail u Outlook.com como remitente y examine las cabeceras del mensaje que le llega. Responda a la lista de comprobación: ¿qué dirección aparece en From?, ¿está la dirección del visitante en Reply-To?, ¿qué indican spf=, dkim= y dmarc= en Authentication-Results?, ¿envía su sitio mediante SMTP o mediante mail()?, y ¿tiene el formulario un captcha o un honeypot? Si no tiene un sitio web propio, responda a las preguntas tomando como referencia el ejemplo de esta lección. A continuación recibirá la respuesta modelo.

Para saber más

Los pasos de estos artículos son válidos para los paneles de WebOké; en otros proveedores funciona de forma similar.

• Un formulario de contacto en su sitio web: cómo hacer que los campos se envíen por correo electrónico y evitar el spam
• ¿Cómo consigo el remitente correcto con mail() en PHP? SMTP
• No se puede enviar correo desde PHP: los registros MX apuntan a otro lugar
• Límite para el envío de correo electrónico
• Límite diario de correo alcanzado
• Manual de DirectAdmin 8.1: Todos los ajustes de un vistazo: servidores, puertos y seguridad
• Manual de DirectAdmin 5.10: E-mail con Microsoft 365 o Google Workspace, sitio web en WebOké