Todas las webs envían mensajes: confirmaciones de pedidos, cambios de contraseña, formularios de contacto o recordatorios de reservas. El correo transaccional es esa parte que nadie planifica, pero de la que todos dependen. Normalmente, quien crea la web lo configura una vez y nadie vuelve a revisarlo.
Hasta que los clientes dejan de recibir sus confirmaciones y alguien descubre que llevan ocho meses en la carpeta de spam. En esta guía explicamos por qué sucede en cualquier plataforma y cómo evitarlo.
Por qué el correo transaccional falla sin avisar
La configuración predeterminada de muchas plataformas envía los mensajes directamente desde el servidor web mediante la función de correo del lenguaje de programación. Durante las pruebas parece funcionar, porque consultas tu propia bandeja de entrada y tu proveedor confía en tus mensajes.
En producción falla por un motivo ajeno al código. El servidor web carece de reputación como remitente, comparte su dirección IP con otros servicios del alojamiento y envía un mensaje que dice proceder de tu dominio desde un servidor que el dominio nunca autorizó. Los proveedores de destino identifican ese patrón como una posible suplantación, porque casi siempre lo es. Precisamente por eso, las directrices de Google para remitentes exigen autenticar el correo.
Desde tu lado, el fallo no deja señales. La web indica que el mensaje se ha enviado, los registros no muestran errores y nada avisa de que el proveedor de destino lo ha guardado como spam. El correo transaccional de una web es especialmente malo informando de sus propios fallos, por eso el problema suele descubrirse meses después mediante la queja de un cliente.
El mismo problema en todas las plataformas
No es un problema exclusivo de WordPress, aunque suele llevarse las críticas por ser la plataforma más utilizada. El mecanismo es el mismo en todas.
WordPress utiliza de forma predeterminada la función de correo de PHP, es decir, envía directamente desde el servidor con todos los inconvenientes anteriores. La solución habitual consiste en sustituirla mediante un complemento SMTP.
Shopify, Wix y Squarespace envían sus propios mensajes transaccionales desde una infraestructura que, por lo general, está bien mantenida. Sin embargo, no siempre permiten enviar desde tu dominio con una autenticación correcta si no lo configuras. El resultado es un mensaje que afirma proceder de tu empresa, pero cuya procedencia no se puede verificar.
Webflow, Ghost y las aplicaciones a medida funcionan de distintas maneras, aunque el patrón se repite: la opción de envío predeterminada rara vez está autenticada para tu dominio.
La solución común consiste en encaminar el correo transaccional mediante una conexión SMTP autenticada y utilizar un dominio cuyos registros DNS autoricen a esa conexión para enviar.
Una solución en tres partes
Se necesitan tres elementos. Con solo dos, los mensajes pueden seguir acabando en spam.
Una cuenta SMTP desde la que enviar. En lugar de enviar directamente, la web se autentica en un servidor de correo y le entrega el mensaje. Todas las plataformas lo permiten, ya sea de forma nativa o mediante un complemento.
Registros DNS que autoricen el envío. Hace falta un registro SPF que identifique al servidor remitente y una firma DKIM que permita verificar cada mensaje. Sin ellos, incluso un envío autenticado parecerá no autorizado al destinatario. Nuestras guías sobre SPF y DKIM explican cómo configurar ambos registros.
Una dirección remitente que exista. Enviar desde noreply@tudominio.com cuando ese buzón no existe supone una señal negativa, aunque pequeña, y hace que las respuestas desaparezcan. Aquí puedes crear el buzón sin aumentar el coste, ya que el precio no se calcula por usuario.
Separa estos mensajes de la correspondencia habitual
A partir de cierto volumen, conviene asignar al correo transaccional de la web su propia ruta de envío.
El correo automático y el escrito por personas se comportan de forma diferente y los proveedores también los evalúan de manera distinta. Una ráfaga de quinientos cambios de contraseña tras un incidente de seguridad no se parece en nada a la correspondencia de una persona. Si ambos tipos salen por la misma ruta, la reputación del tráfico automático se convierte también en la reputación del correo del equipo.
Los perfiles SMTP por dominio facilitan la separación: dirige el dominio que utiliza la aplicación por una ruta y el dominio desde el que escribe el equipo por otra. Así, un problema en uno de los lados no afecta al otro. La configuración de SMTP personalizado por dominio explica el procedimiento.
Algunas empresas van más lejos y utilizan un subdominio independiente para todo el correo automático. De este modo aíslan por completo la reputación, a cambio de una dirección De algo menos elegante. La conveniencia depende del volumen.
Cuándo conviene un proveedor transaccional
Hay que marcar con claridad el límite: a gran escala, los servicios dedicados al correo transaccional existen por buenas razones.
Si envías decenas de miles de mensajes diarios, necesitas eventos de entrega por mensaje, llamadas webhook para los rebotes, gestión de plantillas y estadísticas detalladas. Esas funciones son el propósito central de estos productos y ningún alojamiento de correo generalista las ofrece al mismo nivel.
Nuestros límites diarios están pensados para la correspondencia, no para las campañas: desde 1.000 mensajes por buzón y día en Starter hasta 2.500 en Agency. El correo transaccional de una tienda pequeña o de un sistema de reservas cabe sin dificultad. Una plataforma de gran volumen no. En ese caso, la arquitectura adecuada es conectar un proveedor transaccional mediante un perfil SMTP personalizado. Así mantienes separados el alojamiento del correo y los envíos masivos sin contratar dos proveedores para los buzones.
Comprueba que realmente funciona
Como estos fallos no generan avisos, el hábito más valioso consiste en verificar la entrega en lugar de darla por sentada.
Genera un mensaje real: haz un pedido de prueba o solicita un cambio de contraseña. Envíalo a direcciones de dos proveedores importantes distintos. Abre los encabezados y confirma que SPF y DKIM se han validado y que DMARC muestra alineación. Si los tres resultados son correctos, la configuración está realmente terminada.
Repite la comprobación cada trimestre y siempre que alguien modifique el DNS o cambie el alojamiento. El correo transaccional no suele romperse durante su configuración inicial, sino cuando cambia algún elemento relacionado y nadie piensa en volver a probar las confirmaciones de pedidos después de trasladar los servidores de nombres.
Si los mensajes llegan, pero terminan en spam, las estadísticas de entrega del dominio y los informes DMARC suelen señalar la causa mucho antes que cualquier intento de modificar el contenido a ciegas.
