El correo no llega, rebota o va a spam

Síntoma y contexto

El correo electrónico falla de formas distintas y cada una apunta a causas diferentes. A veces un cliente escribe y el mensaje nunca llega a tu bandeja. Otras veces tú envías un presupuesto y el destinatario dice que no lo recibió, aunque en tu panel aparece como enviado. También es habitual ver rebotes inmediatos con códigos como 550, 553 o 554, o descubrir que tus correos comerciales acaban en spam sin que nadie los haya marcado manualmente.

Antes de tocar nada en el panel DNS o en el proveedor de correo, conviene clasificar el síntoma con precisión. ¿El problema afecta solo al correo que envías, solo al que recibes, o a ambos? ¿Empezó después de migrar el dominio, de cambiar de Google Workspace a otro proveedor, o de contratar un hosting nuevo? ¿Afecta a todas las direcciones del dominio o solo a una cuenta concreta como [email protected]?

En la mayoría de los casos el fallo tiene que ver con registros DNS mal configurados, con un buzón que no existe, con límites del proveedor o con reputación del dominio. Rara vez se soluciona reiniciando el ordenador del usuario. Lo que sí acelera el diagnóstico es tener claro el síntoma, la hora aproximada del cambio y el proveedor implicado: Google, Microsoft 365, Zoho, el hosting compartido, un servicio transaccional como SendGrid o Mailgun, o un servidor propio.

Causas probables

1. Registros MX incorrectos o ausentes. El dominio no indica dónde deben entregarse los mensajes entrantes. Si apuntas MX a un hosting que no gestiona correo, o dejas registros antiguos tras una migración, los mensajes rebotan o se pierden en rutas obsoletas.
2. SPF mal configurado o demasiado permisivo. El registro TXT que empieza por v=spf1 debe incluir solo los servidores autorizados para enviar en nombre del dominio. Si falta el proveedor que realmente envía, otros servidores pueden rechazar tus mensajes. Si incluye +all o demasiados mecanismos contradictorios, aumenta el riesgo de spam.
3. DKIM sin activar o clave no publicada en DNS. Muchos proveedores generan un selector DKIM que debes añadir como registro TXT. Sin DKIM, la autenticación del mensaje es más débil y la entrega empeora, sobre todo hacia Gmail, Outlook y proveedores corporativos.
4. DMARC en modo estricto sin alinear SPF y DKIM. Si publicas una política p=reject o p=quarantine antes de verificar que los envíos pasan correctamente, puedes bloquear correo legítimo sin darte cuenta.
5. Buzón inexistente o cuota llena. Un rebote 550 con texto tipo "user unknown" o "mailbox full" suele ser un problema de cuenta, no de DNS. Revisa que la dirección existe en el panel del proveedor y que no ha superado el almacenamiento.
6. Propagación DNS pendiente. Tras cambiar MX o TXT, los resolvers del mundo pueden tardar desde minutos hasta 48 horas en ver los valores nuevos. Si alguien probó demasiado pronto, puede interpretarse como fallo cuando en realidad es espera.
7. Reputación o listas de bloqueo. Si el dominio o la IP de envío apareció en listas negras por spam previo, volumen anómalo o configuración abierta de relay, los destinatarios rechazan aunque los registros DNS estén bien.
8. Redirecciones y reenvíos mal planteados. Reenviar correo de un buzón personal a otro sin mantener la autenticación, o usar direcciones alias que no coinciden con el dominio visible, puede romper la alineación que exigen SPF y DMARC.

Checklist copiable

DIAGNÓSTICO CORREO - [tu-dominio.com]
Fecha: ___________  Hora (zona): ___________

1. TIPO DE FALLO
   [ ] No recibo correo entrante
   [ ] No puedo enviar (rebote al enviar)
   [ ] Envío OK pero el destinatario no lo ve
   [ ] Todo va a spam
   [ ] Solo falla una dirección: ___________

2. PROVEEDOR DE CORREO
   [ ] Google Workspace   [ ] Microsoft 365   [ ] Zoho
   [ ] Hosting (cPanel/Plesk)   [ ] Otro: ___________

3. REGISTROS DNS (captura del panel)
   MX actuales: ___________
   SPF (TXT): ___________
   DKIM (TXT, selector): ___________
   DMARC (_dmarc TXT): ___________
   ¿Cambio DNS en últimas 48 h?  [ ] Sí  [ ] No

4. REBOTE (pegar texto literal, sin datos de terceros)
   Código SMTP: ___________
   Servidor que responde: ___________
   Mensaje: ___________

5. PRUEBAS HECHAS
   [ ] Envié de gmail.com → mi dominio (hora: ___)
   [ ] Envié de mi dominio → gmail.com (hora: ___)
   [ ] Revisé carpeta spam en ambos lados

6. LO QUE NO HE TOCADO (importante)
   [ ] No he compartido contraseñas
   [ ] No he borrado registros MX sin copia previa

Qué capturar antes de escribir

La evidencia útil para un diagnóstico remoto es concreta y no requiere acceso a tus contraseñas. Empieza por el dominio exacto afectado y el proveedor de correo que debería gestionarlo. Una captura del panel DNS con los registros MX, SPF, DKIM y DMARC visibles ahorra varias idas y vueltas. Si hay un rebote, copia el mensaje completo tal como lo devuelve el servidor: el código numérico, el host que responde y la frase de error. No hace falta incluir el cuerpo del correo original ni datos personales de clientes.

Si el problema es de entrega a spam, indica hacia qué proveedores ocurre con más frecuencia: Gmail, Outlook, empresas con filtro propio. Una prueba con una herramienta externa de comprobación de autenticación puede ayudar, pero basta con describir qué pruebas hiciste y a qué hora. Si migraste recientemente, dime desde qué proveedor venías y qué registros eliminaste o añadiste.

No envíes por el formulario contraseñas del registrador, credenciales del buzón, claves privadas DKIM completas ni exports de configuración con tokens. Con capturas censuradas del panel y el texto del rebote suele bastar para orientar el siguiente paso.

Comandos y paneles útiles

Desde una terminal puedes comprobar los registros sin entrar al panel del registrador. Sustituye tudominio.com por tu dominio real:

# Registros MX (dónde se entrega el correo entrante)
dig MX tudominio.com +short

# Registro SPF (TXT que incluye v=spf1)
dig TXT tudominio.com +short

# DMARC
dig TXT _dmarc.tudominio.com +short

# DKIM (el selector depende del proveedor, ej. google, selector1, default)
dig TXT google._domainkey.tudominio.com +short

En el panel del proveedor de correo, revisa estas secciones según corresponda:

• Google Workspace: Administración → Dominios → Autenticación de correo (SPF, DKIM, DMARC con asistente).
• Microsoft 365: Centro de administración → Configuración → Dominios → Registros DNS recomendados.
• Hosting con cPanel: Zone Editor o Editor de zona DNS para MX y TXT; Email Deliverability para SPF/DKIM.
• Registrador (Cloudflare, Namecheap, GoDaddy, etc.): Sección DNS del dominio. Si usas proxy en registros de correo, los MX no deben pasar por proxy: deben ser DNS only.

Para interpretar un rebote, fíjate en la primera línea con el código de tres dígitos. Un 550 suele indicar rechazo permanente (buzón inexistente, política del servidor). Un 451 o 452 suele ser temporal (cola llena, greylisting). El texto después del código suele decir si el problema es DNS, autenticación, política antispam o cuota.

Pasos de diagnóstico por escenario

No llega correo entrante

Comprueba primero que los MX apuntan al proveedor correcto y que no quedan registros MX antiguos con prioridad más baja que confundan a algunos servidores. Envía un correo de prueba desde una cuenta externa (Gmail, por ejemplo) y revisa si aparece rebote en el remitente. Si el remitente no recibe rebote pero tú no ves el mensaje, revisa carpetas de spam, filtros y reglas del buzón. Confirma que la dirección destino existe en el panel del proveedor.

No puedo enviar o rebota al enviar

Revisa SPF: el servidor que envía debe estar autorizado en el registro TXT. Si usas un formulario web, un CRM o un SaaS para enviar correo en nombre de tu dominio, ese servicio también debe figurar en SPF o en un subdominio dedicado. Comprueba DKIM: muchos rebotes modernos mencionan "DKIM fail" o "SPF fail" en el cuerpo del mensaje de error. Si envías desde el hosting y el SPF solo autoriza a Google, el hosting no está legitimado.

El correo se envía pero cae en spam

Verifica que DKIM y SPF pasan correctamente. Revisa si el dominio es nuevo o si nunca envió correo legítimo antes: la reputación se construye con volumen coherente y contenido normal. Evita enlaces acortados sospechosos, adjuntos pesados no solicitados y textos copiados de plantillas de marketing agresivo. Publica DMARC empezando por p=none con informes activados antes de endurecer la política.

Cuándo escalar

Puedes seguir esta guía por tu cuenta si tienes acceso al panel DNS y al proveedor de correo. Escala a revisión remota, o escribe por el formulario con la categoría de dominio y correo, cuando:

• Tras 48 horas de haber corregido MX, SPF y DKIM el fallo persiste y las pruebas con dig muestran los valores correctos.
• El rebote menciona bloqueo por reputación, RBL o política del destinatario y no sabes cómo solicitar deslistado.
• Migraste de proveedor y no tienes claro qué registros antiguos eliminar sin cortar el correo que aún funciona.
• Varias cuentas del mismo dominio fallan de formas distintas y sospechas de conflicto entre hosting, Google y un servicio transaccional.
• Necesitas configurar subdominios para envío transaccional (por ejemplo mail.tudominio.com) sin romper el correo humano del dominio raíz.
• El registrador y el proveedor de correo se culpan mutuamente y necesitas un tercero que lea la evidencia con calma.

Si el fallo es urgente (no recibes pedidos ni facturas), indícalo en el mensaje, pero evita prometer plazos que dependen de propagación DNS o de soporte de terceros. Con la checklist cumplimentada y las capturas listas, el primer intercambio por correo puede ir directo al punto sin repetir pruebas básicas.