El correo llega a spam

Síntoma y contexto

El correo "va a spam" cuando el mensaje sí llega al servidor del destinatario, pero se coloca en la carpeta de correo no deseado, promociones o cuarentena. Es distinto de un rebote: no ves un 550, no aparece "user unknown" y el servidor no rechaza la entrega de forma inmediata. El usuario puede encontrar el mensaje al buscarlo, marcarlo como seguro o moverlo a la bandeja de entrada. Esa diferencia importa porque las causas suelen estar en autenticación, reputación y contenido, no en que el buzón no exista.

Los filtros modernos miran muchas señales a la vez. Revisan si SPF autoriza la IP que envía, si DKIM firma el mensaje, si DMARC alinea el dominio visible con una autenticación válida, si la IP compartida tiene buena reputación, si el dominio es nuevo, si el volumen es coherente y si el contenido parece legítimo. No existe un único ajuste mágico. Conviene avanzar por capas y documentar cada cambio.

Esta guía se centra en entrega a spam. Si tus mensajes no llegan y recibes un código de rechazo, usa primero la guía de correo que no llega o rebota. Si el problema empezó tras migrar de proveedor, revisa también correo y Microsoft 365 tras migración. Si los registros DNS no aparecen, puede ser un problema de resolución del dominio y encaja con dominio que no resuelve.

Causas probables

1. SPF incompleto o duplicado. El dominio debe tener un solo TXT con v=spf1. Si falta el proveedor que envía, o si hay dos SPF separados, algunos destinatarios bajan la confianza del mensaje.
2. DKIM sin firma o selector mal publicado. DKIM permite comprobar que el mensaje no fue alterado y que lo firmó el proveedor autorizado. Sin DKIM, la entrega puede seguir funcionando, pero queda más débil ante Gmail, Outlook y filtros corporativos.
3. DMARC sin alineación. DMARC no solo mira si pasa SPF o DKIM. También exige que el dominio visible en From se alinee con el dominio autenticado. Reenvíos, CRMs y formularios suelen romper esa relación si se configuran con prisa.
4. Política DMARC endurecida demasiado rápido. Pasar de sin DMARC a p=quarantine o p=reject sin revisar informes puede enviar correo legítimo a spam o rechazo.
5. Reputación de IP compartida. En hosting barato o plataformas masivas, otros remitentes pueden afectar a la IP compartida. Aunque tu dominio esté limpio, la IP puede tener historial irregular.
6. Mezcla de correo humano y transaccional. Usar el buzón principal para newsletters, facturas automáticas, formularios web y conversaciones reales mezcla señales y complica la reputación.
7. Contenido con señales de riesgo. Enlaces acortados, adjuntos ejecutables, muchas imágenes, mayúsculas, asuntos agresivos o dominios enlazados sin reputación pueden empujar el mensaje a spam.
8. Dominio nuevo o volumen brusco. Un dominio recién registrado que empieza a enviar mucho correo de golpe no tiene historial. Los filtros pueden tratarlo con cautela hasta ver comportamiento estable.

Checklist copiable

DIAGNÓSTICO CORREO A SPAM - [dominio.com]
Fecha: ___________  Hora de prueba: ___________

1. SÍNTOMA
   [ ] El mensaje llega a spam
   [ ] Llega a promociones / otros
   [ ] Lo retiene cuarentena corporativa
   [ ] No hay rebote 550 ni rechazo SMTP

2. PROVEEDOR QUE ENVÍA
   [ ] Google Workspace   [ ] Microsoft 365
   [ ] Hosting / cPanel   [ ] CRM / newsletter
   [ ] Transaccional: SendGrid / Mailgun / Postmark / otro
   Remitente visible From: ___________

3. AUTENTICACIÓN
   SPF publicado: ___________
   DKIM selector: ___________
   DMARC publicado: ___________
   Resultado en cabeceras: SPF pass/fail, DKIM pass/fail, DMARC pass/fail

4. ALINEACIÓN
   Dominio From: ___________
   Dominio Return-Path: ___________
   Dominio DKIM d=: ___________

5. REPUTACIÓN Y ENVÍO
   [ ] Dominio nuevo
   [ ] IP compartida
   [ ] Volumen aumentó recientemente
   [ ] Uso buzón humano y automatizaciones juntas

6. CONTENIDO
   [ ] Adjuntos pesados
   [ ] Enlaces acortados
   [ ] Muchas imágenes
   [ ] Texto de marketing agresivo

7. NO ENVIAR
   [ ] Sin contraseñas de buzón
   [ ] Sin claves privadas DKIM
   [ ] Sin tokens de proveedor

Qué capturar antes de escribir

La prueba más útil es un correo reciente que haya llegado a spam. Guarda hora, remitente, destinatario y proveedor de destino. Si puedes, exporta o copia las cabeceras completas del mensaje desde Gmail, Outlook u otro cliente. Las cabeceras muestran resultados como spf=pass, dkim=pass y dmarc=pass, además del Return-Path y el dominio que firmó DKIM. No hace falta enviar el cuerpo del mensaje si contiene datos personales; basta con asunto, tipo de envío y cabeceras censuradas si hay información sensible.

Incluye capturas del panel DNS con SPF, DKIM y DMARC visibles. Para DKIM, no envíes claves privadas. El registro TXT público sí puede verse en DNS, pero las claves privadas o archivos de configuración del proveedor no deben compartirse. Si usas una herramienta transaccional, indica si envías desde el dominio raíz, desde un subdominio como mail.tudominio.com, o desde un dominio del proveedor.

Comandos y paneles útiles

Comprueba DNS desde terminal sustituyendo el dominio y selector:

# SPF
dig TXT tudominio.com +short

# DMARC
dig TXT _dmarc.tudominio.com +short

# DKIM, el selector puede ser google, selector1, default, k1 u otro
dig TXT selector1._domainkey.tudominio.com +short

# MX, para confirmar el proveedor de buzón
dig MX tudominio.com +short

Paneles donde mirar:

• Google Workspace: Apps -> Google Workspace -> Gmail -> Autenticar correo. Activa DKIM y revisa SPF recomendado.
• Microsoft 365: Centro de administración -> Dominios y Defender -> Email authentication para DKIM y DMARC.
• Cloudflare o registrador DNS: Zona DNS con TXT de SPF, DKIM y DMARC. Evita crear varios SPF.
• Proveedor transaccional: Domain authentication, tracking domain, bounce domain y estado de verificación.
• Cliente de correo: Opción "Mostrar original" o "Ver fuente del mensaje" para leer cabeceras completas.

Un DMARC prudente suele empezar en observación y subir de forma gradual:

# Observación inicial
v=DMARC1; p=none; rua=mailto:[email protected]

# Después de revisar alineación y fuentes legítimas
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

# Política estricta solo cuando todo el correo legítimo pasa
v=DMARC1; p=reject; rua=mailto:[email protected]

Pasos de diagnóstico por escenario

SPF pasa pero DMARC falla

Mira el dominio del Return-Path. SPF puede pasar para el dominio técnico del proveedor y, aun así, no alinear con el dominio visible en From. En ese caso DMARC falla porque el destinatario ve un dominio, pero la autenticación pertenece a otro. Solución habitual: autenticar el dominio propio en el proveedor, usar un subdominio dedicado o activar un bounce domain personalizado.

DKIM no aparece en cabeceras

No basta con publicar un TXT. El proveedor debe firmar cada mensaje saliente con ese selector. Revisa que DKIM está activado en el panel y que el selector publicado coincide exactamente. En Microsoft 365 y Google Workspace suele haber un paso de activación después de añadir DNS. Si el selector responde pero la cabecera no incluye DKIM-Signature, el correo está saliendo por otro sistema.

La IP compartida tiene mala reputación

Si envías desde hosting compartido o desde un proveedor con muchos remitentes en la misma IP, puedes heredar señales de otros usuarios. Cambiar de IP no arregla contenido malo ni autenticación rota, pero una IP dedicada o un proveedor transaccional serio puede ayudar cuando el volumen y el caso lo justifican. Para correo humano de bajo volumen, suele ser mejor usar Google Workspace, Microsoft 365 o un proveedor de buzón fiable y mantener envíos masivos separados.

Formulario web o tienda envía como si fuera el cliente

Muchos formularios intentan poner en From el email que escribió el usuario. Eso rompe DMARC si el dominio del usuario no autorizó tu servidor. La práctica segura es enviar desde una dirección de tu dominio, por ejemplo [email protected], y poner el email del usuario en Reply-To. Si el formulario dejó de entregar, consulta también la guía de formulario que no envía si existe en tu flujo de diagnóstico.

Quieres endurecer DMARC sin cortar correo legítimo

Empieza con p=none para recibir informes y ver qué fuentes envían en tu nombre. Corrige SPF, DKIM y alineación para cada fuente legítima: buzón, CRM, facturación, ecommerce y transaccional. Después sube a quarantine con pct=25 o similar, observa resultados, y solo más tarde considera reject. Si cambias a política estricta sin inventario, puedes mandar a spam o rechazar notificaciones reales.

Cuándo escalar

Escala o escribe por el formulario con categoría Dominio, DNS o correo cuando SPF, DKIM y DMARC parecen correctos pero Gmail u Outlook siguen clasificando el mensaje como spam, cuando no sabes qué fuente rompe la alineación, o cuando mezclas correo de buzón, CRM y transaccional en el mismo dominio. También conviene revisión si tienes que subir DMARC de p=none a una política más estricta y no quieres cortar facturas, formularios o avisos automáticos.

Envía dominio, proveedor, cabeceras del mensaje de prueba, capturas DNS y una lista de servicios que envían correo. No envíes contraseñas, tokens ni claves privadas. Relacionado: correo no llega o rebota, correo Office 365 migración, dominio no resuelve.