Por qué los correos transaccionales de tu app acaban en spam (y cómo solucionarlo)

Por qué la entrega de correo transaccional es otra historia

Hay una distinción crítica entre correos de marketing y correos transaccionales que muchos desarrolladores pasan por alto cuando empiezan a tomarse en serio la entregabilidad. Los correos de marketing — boletines, campañas promocionales, anuncios — se envían a suscriptores que dieron su consentimiento. Toleran retrasos ocasionales e incluso alguna caída puntual en la carpeta de spam. Si un boletín acaba en spam para el 2 % de tu lista, es una lástima, pero tu negocio sigue funcionando.

Los correos transaccionales son algo completamente distinto. Enlaces de verificación, restablecimientos de contraseña, confirmaciones de compra, códigos de doble factor, alertas de seguridad de la cuenta: llegan en momentos críticos del recorrido del usuario. Un restablecimiento de contraseña que acaba en spam significa que tu usuario está bloqueado fuera de su cuenta y probablemente abrirá un ticket de soporte o, peor aún, no volverá nunca. Un correo de verificación en spam significa que un usuario nuevo no puede completar el registro y que tu embudo de adquisición tiene una fuga silenciosa e invisible.

Y aun así, los correos transaccionales se configuran a menudo con menos cuidado que las campañas de marketing. Muchos desarrolladores usan el código de envío que trae su framework en lugar de construir con cuidado el sistema de correo de verificación, lo apuntan a un servidor SMTP compartido, lo despliegan, lo prueban una vez con su propia bandeja — que tiene umbrales de spam muy permisivos — y siguen adelante. Los problemas solo salen a la luz cuando usuarios reales en Gmail, Outlook o Yahoo informan de correos que no llegan. A esas alturas, el fallo lleva semanas produciéndose en silencio en producción.

SPF: los cimientos de la autenticación de correo

Sender Policy Framework (SPF) es un registro DNS TXT en tu dominio de envío que indica al mundo qué servidores de correo están autorizados a enviar en tu nombre. Cuando Gmail recibe un correo supuestamente enviado desde [email protected], hace una consulta DNS del registro SPF de tu dominio. Si la dirección IP del servidor que realmente envió el correo aparece en tu registro SPF, el correo pasa SPF. Si no existe ningún registro SPF — o el servidor emisor no está incluido — el correo se trata con desconfianza antes incluso de que empiece cualquier evaluación de contenido.

Configurar SPF es sencillo una vez que sabes qué hacer. Añade un registro TXT al DNS de tu dominio. El valor depende de tu proveedor de envío. Con SendGrid: v=spf1 include:sendgrid.net ~all. Con AWS SES: v=spf1 include:amazonses.com ~all. Con Mailgun: v=spf1 include:mailgun.org ~all. La documentación de tu proveedor te dará el valor include exacto. El sufijo ~all es un "soft fail": los correos de servidores no listados se marcan pero no se rechazan de plano. Cuando tengas la certeza de que tu registro SPF está completo y correcto, puedes pasar a -all (hard fail), que indica a los servidores receptores que rechacen por completo el correo no autorizado.

Un error frecuente: el límite de 10 consultas DNS. Los registros SPF que encadenan varias directivas include: pueden superar ese límite, haciendo que SPF falle aunque todos tus servidores estén técnicamente listados. Usa MXToolbox para revisar tu registro SPF: señala con claridad los problemas de número de consultas. La relación entre SPF, DKIM y DMARC está muy bien explicada en la documentación de SendGrid sobre autenticación de correo.

DKIM: prueba criptográfica de que tu correo no fue manipulado

DomainKeys Identified Mail (DKIM) añade una firma criptográfica a cada correo que envías. La firma se genera con una clave privada que custodia tu proveedor de envío, y los servidores receptores la verifican contra una clave pública que tú publicas como registro DNS TXT. Si la firma cuadra, quedan demostradas dos cosas: el correo salió realmente de tu infraestructura de envío y el contenido no se modificó entre el envío y la recepción.

Sin DKIM configurado, resulta mucho más fácil para actores maliciosos suplantar tu dominio: enviar correos que parecen venir de [email protected] pero que en realidad los envió otra persona. Así funcionan las campañas de phishing. Los filtros antispam también lo saben, y por eso un correo sin firma DKIM válida procedente de un dominio que debería tenerla se trata con un nivel de sospecha elevado. Spamhaus y otros servicios de reputación incorporan el historial de firmado DKIM en las puntuaciones de reputación de dominio.

DKIM se configura a través de tu proveedor de envío. El proveedor genera un par de claves, conserva la clave privada en su infraestructura y te entrega una clave pública para añadirla a tu DNS como registro TXT. Una vez publicado y propagado ese registro, cada correo que envíen en tu nombre llevará automáticamente una firma DKIM válida. La mayoría de los grandes proveedores — SendGrid, Mailgun, Amazon SES, Postmark — te guían por este proceso durante la configuración inicial. Si te lo saltaste, vuelve atrás y configúralo ahora.

DMARC: la capa de política que lo une todo

DMARC (Domain-based Message Authentication, Reporting and Conformance) se apoya en SPF y DKIM definiendo qué deben hacer los servidores receptores cuando un correo no supera esas comprobaciones. También introduce el concepto de "alineación": exige que el dominio de la cabecera From coincida realmente con el dominio que pasó SPF o DKIM. Esto impide que un atacante supere la comprobación SPF con un dominio mientras suplanta otro en la dirección From visible.

El enfoque correcto con DMARC es empezar poco a poco. Comienza con una política de solo monitorización: v=DMARC1; p=none; rua=mailto:[email protected]. El p=none indica a los servidores receptores que no tomen medidas ante los fallos, solo que te envíen informes. Esos informes agregados te dirán qué servidores están enviando correo en tu nombre y si pasan SPF y DKIM. Revísalos durante unas semanas antes de cambiar la política.

Cuando tengas la certeza de que todo el tráfico legítimo pasa, cambia a p=quarantine (los correos que fallan van a la carpeta de spam) y finalmente a p=reject (los correos que fallan se rechazan directamente). Esta progresión protege la reputación de tu dominio frente a la suplantación y, al mismo tiempo, te da margen para detectar fuentes de envío legítimas que hubieras olvidado. Una política DMARC con p=reject combinada con SPF y DKIM válidos hace casi imposible que un atacante suplante tu dominio de forma eficaz.

Reputación de IP: por qué importa tu servidor de envío

Incluso con SPF, DKIM y DMARC perfectos, tus correos pueden ir a spam si la dirección IP desde la que se envían tiene mala reputación. Los servidores receptores mantienen — o consultan servicios de terceros que mantienen — listas de bloqueo y puntuaciones de reputación de las IP emisoras. Una IP con historial de spam, o que aparece en las listas de bloqueo de servicios como Spamhaus, verá sus correos salientes tratados con desconfianza por muy bien configurada que esté tu autenticación.

Si usas una dirección IP compartida de un hosting compartido o de un servicio SMTP barato, tu reputación queda ligada a la de todos los demás que usan esa misma IP. Un único spammer en el mismo grupo compartido puede hundir la entregabilidad de todos los remitentes de esa IP. Este es uno de los argumentos más sólidos para usar un proveedor dedicado de correo transaccional — SendGrid, Amazon SES, Postmark, Mailgun — en lugar de enviar directamente desde el servidor de tu aplicación o a través de un SMTP compartido.

Con una IP de envío nueva también tendrás que "calentarla" de forma gradual. Un pico repentino de volumen desde una IP recién estrenada parece comportamiento de spam para los servidores receptores. Empieza con volúmenes bajos y ve aumentando a lo largo de días o semanas. La mayoría de los proveedores dedicados gestionan el calentamiento de IP automáticamente si estás en un grupo de envío compartido, o te facilitan calendarios de calentamiento si usas una IP dedicada.

Contenido y asunto: qué dispara los filtros

Más allá de la autenticación y la reputación de IP, los filtros antispam también evalúan el contenido del propio correo. Ciertos patrones activan de forma fiable la clasificación como spam. Las palabras gatillo en el asunto — "GRATIS", "GARANTIZADO", "ACTÚA YA", signos de exclamación excesivos, TODO EN MAYÚSCULAS — son las obvias que casi todos los desarrolladores evitan. Menos evidente: asuntos demasiado vagos ("Mensaje importante para ti"), demasiado urgentes ("Tu cuenta será cerrada") o demasiado promocionales para lo que debería ser un correo transaccional.

La proporción entre texto e imágenes también cuenta. Un correo compuesto principalmente por imágenes con muy poco texto es un patrón clásico de spam: quienes envían correo masivo usan imágenes para ocultar palabras clave a los filtros basados en texto. Los correos transaccionales deben ser fundamentalmente de texto, con pocas imágenes. El HTML mal formado — etiquetas sin cerrar, atributos incorrectos — es otra señal de alarma. Envía siempre una alternativa en texto plano junto a la versión HTML. Los filtros antispam ven los correos solo en HTML con mayor desconfianza, y los sistemas de correo corporativos suelen eliminar el HTML por completo.

Probar la entrega de tus correos — de la forma correcta

El método de prueba más rápido y práctico para la entrega de correo es este: envía un correo de prueba a una bandeja de correo temporal recién creada y revisa tanto la bandeja de entrada como la carpeta de spam. Esto te da información inmediata e inequívoca sobre si tu correo llega a la bandeja o se filtra. A diferencia de probar con tu propia cuenta de Gmail — que puede tenerte en lista blanca como remitente habitual — una dirección temporal nueva no tiene ningún historial con tu dominio, lo que simula con mucha más fidelidad el primer contacto de un usuario nuevo.

Deberías comprobar que el correo de verificación llega de verdad cada vez que cambies algo que pueda afectar a la entrega: cambiar de proveedor de correo, modificar sustancialmente tu plantilla HTML, cambiar el dominio de envío, añadir un nuevo subdominio de envío o despliegue en un entorno nuevo (staging, producción). Cuesta dos minutos y te da evidencia concluyente. La alternativa — esperar a que los usuarios reporten problemas — significa que tus fallos de entregabilidad llevan ya un tiempo indeterminado produciéndose en silencio.

Además de la comprobación de bandeja de entrada y spam, usa el verificador de salud de correo de MXToolbox para revisar el estado general de tu dominio: SPF, DKIM, DMARC, presencia en listas negras y configuración de registros MX, todo en un mismo sitio. Convierte esto en parte de tu lista de comprobación previa al lanzamiento para cada aplicación o dominio de envío nuevo. Consulta también las directrices de OWASP sobre buenas prácticas de correo relacionadas con la seguridad.

Tasa de rebote y quejas de spam: las métricas que importan

Dos métricas tienen un efecto desproporcionado en la entregabilidad a largo plazo: la tasa de rebote y la tasa de quejas de spam. Una tasa de rebote superior al 2 % le dice a los servidores receptores y a tu proveedor de envío que estás enviando a muchas direcciones inválidas o inexistentes, un patrón asociado a listas compradas y a operaciones de spam. Aunque hagas todo lo demás bien, una tasa de rebote alta te causará problemas de entrega. Elimina los rebotes duros de tu lista de envío de inmediato y de forma permanente.

Una tasa de quejas superior al 0,1 % (una queja por cada mil correos enviados) es el umbral en el que la mayoría de los proveedores empiezan a restringir tu cuenta. Las Postmaster Tools de Gmail informan de la tasa de quejas directamente si las tienes configuradas. Vigila estas métricas desde el panel de tu proveedor de envío. Si la tasa de quejas sube, investiga por qué: ¿estás enviando a usuarios que no dieron su consentimiento explícito? ¿Envías con demasiada frecuencia? ¿Hay un desajuste entre lo que los usuarios esperaban y lo que reciben?

Lista de comprobación completa de entregabilidad

• Registro SPF: registro DNS TXT en tu dominio de envío con todos los servidores autorizados. Compruébalo con MXToolbox.
• DKIM: firmado criptográfico configurado a través de tu proveedor de envío, clave pública publicada en DNS.
• DMARC: empieza con monitorización p=none, avanza a p=quarantine y luego a p=reject tras revisar los informes agregados.
• Proveedor de envío dedicado: usa SendGrid, SES, Postmark o Mailgun, no el servidor de tu aplicación ni un SMTP compartido.
• Asuntos limpios: concretos, relevantes, sin palabras gatillo, sin puntuación ni mayúsculas excesivas.
• HTML + texto plano: incluye siempre ambos. Nunca envíes correos solo en HTML.
• Sin acortadores de URL: usa URL completas y directas en el cuerpo del correo y en los enlaces de verificación.
• Enlace de baja: inclúyelo incluso en correo transaccional cuando proceda; algunos proveedores lo exigen.
• Dirección postal: obligatoria según CAN-SPAM y normativas similares en muchas jurisdicciones.
• Gestión de rebotes duros: elimínalos de inmediato; nunca reintentes un rebote duro.
• Seguimiento de quejas: configura Gmail Postmaster Tools y vigila la tasa de quejas en el panel.
• Prueba de bandeja de entrada: envía correos de prueba a bandejas temporales nuevas antes de cada despliegue y tras cualquier cambio de plantilla o configuración.
• Chequeo de salud con MXToolbox: inclúyelo en tu lista previa al lanzamiento para cada dominio y entorno nuevo.

Cuándo usar un servicio dedicado de correo transaccional

Si tu aplicación envía cualquier correo que el usuario necesite recibir para poder usarla — enlaces de verificación, restablecimientos de contraseña y los recibos que cierran un recorrido completo de registro y pago — deberías usar un proveedor dedicado de correo transaccional desde el primer día. El coste es bajo (a menudo gratuito hasta decenas de miles de correos al mes), la fiabilidad es enormemente mejor que un SMTP casero, y la infraestructura de entregabilidad — grupos de IP compartidas con reputación gestionada, firmado DKIM automático, tratamiento de rebotes y quejas — la mantienen equipos cuyo único trabajo es conseguir que el correo llegue a la bandeja de entrada.

El error casero más habitual es ejecutar un servidor de correo en la misma IP que la aplicación web, o usar el SMTP incluido de un hosting barato. Esas IP acaban rutinariamente en listas de bloqueo de servicios como Spamhaus, porque el entorno de hosting se comparte con actores maliciosos. Migrar a un proveedor transaccional dedicado suele ser una tarde de trabajo y tiene un impacto positivo inmediato en la entregabilidad. Es una de las mejoras de infraestructura con mayor retorno que puede hacer un equipo pequeño. Los equipos que se preocupan por la privacidad también deberían revisar las recomendaciones de la Electronic Frontier Foundation sobre el tratamiento responsable de los datos de usuario cuando hay correo implicado. Además, comprobar direcciones contra bases de datos de filtraciones conocidas mediante Have I Been Pwned puede complementar tu prevención del fraude cuando se crean cuentas nuevas.