Mis correos llegan a spam: cómo se diagnostica y cómo se corrige
El servidor que recibe tu mensaje decide en milisegundos si va a la bandeja o a la basura, y deja escrito el motivo dentro del encabezado del propio correo. Aquí aprendes a leerlo, a comprobar SPF, DKIM y DMARC con comandos que puedes correr hoy, y a separar un fallo de autenticación de un problema de reputación.
Qué ocurre por debajo cuando un correo cae en la basura
El servidor destinatario corre tres comprobaciones antes de mirar una palabra del texto. Si la dirección IP que se conectó tiene permiso para enviar por tu dominio: eso es SPF. Si el mensaje trae una firma criptográfica válida emitida por tu dominio: eso es DKIM. Y si alguna de las dos coincide con el dominio que el usuario ve en el campo De; esa coincidencia se llama alineación y la exige DMARC. Recién después pesa la reputación: cuánta gente pulsó «correo no deseado», cuántas direcciones inexistentes intentaste, si esa IP figura en listas de bloqueo. Un fallo técnico te manda a spam de golpe, el mismo día que alguien tocó el DNS. La reputación te hunde despacio. Por eso la queja típica es «antes funcionaba y nadie cambió nada»: casi siempre sí cambió algo, hace un mes.
Árbol de diagnóstico: encabezado, DNS y por último reputación
Consigue un mensaje real que haya caído en spam
No diagnostiques con teoría. Pide al destinatario que abra el mensaje en su carpeta de basura y use «ver original». Necesitas el encabezado completo en texto, no una captura del cuerpo. Si además consigues uno tuyo que sí entró a otro proveedor, comparar ambos resuelve la mitad de los casos sin tocar nada.
Lee la línea Authentication-Results
Es la sentencia del receptor, escrita por el receptor. Busca spf=, dkim= y dmarc=. Si las tres dicen pass, el problema no es de autenticación y te ahorras un día moviendo registros que estaban bien. Mira también la primera línea Received: ahí está la IP que hizo la conexión, que muchas veces no es la que crees.
Consulta el SPF publicado, no el del panel
Corre dig +short TXT tudominio.com y lee lo que hay realmente en el DNS. Debe existir un único TXT que empiece por v=spf1; dos registros no se suman, invalidan la comprobación. Después cuenta los mecanismos que consultan DNS, porque el límite es duro y no avisa cuando lo cruzas.
Verifica DKIM: selector, publicación y tamaño de clave
La etiqueta s= de la línea DKIM-Signature te da el selector y la d= el dominio firmante. Consulta la clave pública con dig +short TXT selector._domainkey.tudominio.com. Si no devuelve nada, el selector no está publicado y la firma falla siempre. El mínimo defendible hoy es RSA de 2048 bits.
Revisa DMARC y el tipo de alineación
Consulta dig +short TXT _dmarc.tudominio.com. Importan cuatro etiquetas: p= es la política, rua= dice a dónde llegan los informes, y aspf= con adkim= definen la alineación. Por defecto ambas valen r, relajado, que acepta subdominios del mismo dominio organizativo; con s el dominio debe coincidir exactamente.
Recién ahora mira la IP y su reputación
Comprueba que la IP de la línea Received tenga registro PTR, que ese nombre resuelva de vuelta a la misma dirección y que no aparezca en listas de bloqueo. Si es compartida por miles de clientes, tu reputación depende del peor de ellos. Si es tuya y está listada, casi siempre hay una computadora infectada enviando por el puerto 25.
Cómo se lee cada veredicto del encabezado
- spf=pass: la IP está autorizada. No dice nada del dominio que ve el usuario.
- spf=fail: no está en tu lista y cierras en -all. El receptor rechaza o marca.
- spf=softfail: no está en la lista y cierras en ~all. Suma puntos de spam sin rechazar.
- spf=permerror: el registro no se puede evaluar: sintaxis rota, dos registros o demasiadas consultas DNS. DMARC lo cuenta como fallo.
- dkim=none: no hay firma. dkim=fail: hay firma pero no valida, casi siempre porque un equipo intermedio modificó el mensaje.
- dmarc=fail: o fallaron las dos comprobaciones, o pasaron por un dominio distinto al que ve el usuario.
La trampa está en la última línea. Un mensaje puede llevar spf=pass y dkim=pass y aun así salir dmarc=fail. Cuando eso pasa no toques las claves: lo que falla es la alineación.
Causas frecuentes y el arreglo que le toca a cada una
- Más de diez consultas DNS en el SPF: devuelve permerror y DMARC lo trata como fallo. Retira remitentes viejos o sustituye un include por rangos ip4.
- Dos registros TXT que empiezan por v=spf1 bajo el mismo nombre. No se suman: anulan la comprobación.
- El registro cierra en ?all o en +all: así no proteges nada. Usa ~all mientras levantas el inventario y cierra con -all.
- DKIM sin publicar, o con clave de 1024 bits heredada. Genera un selector nuevo con RSA de 2048 bits.
- DMARC estancado en p=none durante años: solo informa, no impide que nadie escriba usando tu dominio.
- Alineación rota porque un proveedor externo firma con su dominio. Se corrige delegándole un subdominio de envío.
- La IP de salida sin registro PTR. Varios receptores grandes lo exigen antes de aceptar la conexión.
- Una computadora infectada enviando por el puerto 25. Ciérralo de salida salvo para el servidor de correo.
- Campañas masivas saliendo del mismo dominio que las facturas. Sepáralas en un subdominio de mercadeo.
- Envío masivo sin baja en un clic ni buzón de quejas atendido. Se exige a partir de cinco mil mensajes diarios.
- Salto brusco de volumen tras una migración: una IP sin historial necesita subir el envío por escalones.
El límite de diez consultas DNS del SPF
El estándar limita la evaluación de SPF a diez consultas DNS y a dos consultas vacías. Cada include, a, mx, ptr, exists y redirect gasta una; ip4 e ip6 no gastan ninguna porque no preguntan nada.
La cuenta es recursiva, y ahí está el problema: un solo include de una plataforma grande puede gastar cinco o seis por dentro. Sumas el correo corporativo, la facturación, el sistema de tiquetes y una herramienta de campañas, y cruzas el límite sin haber escrito diez líneas.
Al cruzarlo no recibes un aviso, recibes permerror, que se comporta como fallo. El registro se ve razonable, el correo sale sin errores y parte de los destinatarios lo manda a la basura.
- Retira los remitentes que ya no usas: casi siempre sobran dos o tres de hace años.
- Cambia un include por los rangos ip4 concretos cuando el proveedor los publique y sean estables.
- Delega cada flujo a su subdominio; cada uno trae su propio presupuesto de diez consultas.
- Evita el mecanismo ptr: lento, poco fiable y desaconsejado por el propio estándar.
Subir de p=none a p=reject sin quedarte sin correo
DMARC solo sirve si termina en una política que rechace. Pero subirla de golpe tumba lo que no sabías que enviaba en tu nombre: la impresora que manda escaneos, el sistema de recursos humanos, el formulario del sitio.
- p=none con rua. No bloquea nada; pide informes agregados a una dirección que alguien lea. Déjalo dos o tres semanas.
- Arma el inventario con esos informes. Te dicen qué dirección envió por tu dominio y si pasó alineada.
- p=quarantine. Aplica la política a una fracción del tráfico y auméntala cuando dejen de aparecer sorpresas.
- p=reject. El mensaje que se hace pasar por tu dominio se rechaza en el servidor del destinatario y ni llega a su carpeta de basura.
Dos advertencias. Si publicas una política dura con remitentes sin autorizar, el que se queda sin correo eres tú. Y DMARC protege el dominio del campo De: no hace nada contra un dominio parecido registrado por un tercero, que es el problema de recibimos correos de phishing.
Plan de trabajo en cuatro fases
Medir sin cambiar nada
Encabezados de tres mensajes reales, registro SPF publicado, selector DKIM, registro DMARC, PTR de la dirección de salida y consulta a listas de bloqueo. Sale un documento de una página con el estado actual.
Arreglar la autenticación
Un solo registro SPF bajo el límite, DKIM firmando con clave de 2048 bits en todos los flujos y DMARC en p=none recibiendo informes. Baja el tiempo de vida de los registros antes de tocarlos, para corregir un error en minutos.
Limpiar la reputación
Cerrar el puerto 25 de salida salvo para el servidor de correo, sacar del envío las direcciones que rebotan, separar el tráfico masivo y pedir el retiro en las listas donde figures. Se recupera enviando bien durante semanas.
Subir la política y dejarlo vigilado
Quarantine primero, reject después, con los informes llegando a un buzón que alguien revisa. Un dominio en reject sin nadie mirando los informes se rompe el día que el área comercial contrate una herramienta nueva.
Reputación y contenido: lo que la autenticación no arregla
Autenticar es un requisito, no una garantía. Con SPF, DKIM y DMARC perfectos puedes seguir cayendo en la basura si tu reputación es mala.
- La tasa de quejas. Los proveedores mayoritarios publican un umbral por debajo del 0,3 por ciento de mensajes marcados como no deseados: tres quejas por cada mil correos.
- Los rebotes duros. Enviar a direcciones inexistentes es la señal más clara de una lista que nadie limpia.
- La constancia. Un dominio que envía cincuenta correos diarios y un martes manda veinte mil se comporta igual que uno secuestrado.
- El contenido. Acortadores de enlaces y correos que son una sola imagen sin texto suman en contra.
Y una decisión de arquitectura: no envíes campañas por el mismo dominio que las facturas. Si mercadeo comparte dominio con cobranza, una campaña con muchas quejas se lleva por delante los correos que la empresa no puede perder. Si tu correo vive en Microsoft 365, buena parte de esto se configura desde el propio panel: lo detallamos en Microsoft 365 para empresas y en qué plan te conviene.
Qué arreglas tú esta semana y cuándo conviene llamar
Sin ayuda y sin gastar puedes leer el encabezado de un mensaje que cayó en spam, consultar tus tres registros con dig, contar los mecanismos del SPF, retirar los remitentes que ya no usas y publicar DMARC en p=none con una dirección de informes. Nada de eso rompe el correo.
Conviene llamar cuando el dominio ya está listado, cuando la empresa envía por cuatro o cinco plataformas y nadie tiene el inventario, o cuando quieres llegar a p=reject sin quedarte incomunicado el lunes por la mañana.
Vijor Networks es una empresa familiar panameña fundada en 2009 en Ciudad de Panamá. Las personas del equipo atienden de lunes a viernes en horario de oficina.
Sigue por aquí:
Preguntas frecuentes sobre correo que llega a spam
Cambié el DNS y sigue llegando a spam. ¿Cuánto tarda en notarse?
La autenticación mejora en cuanto se propaga el cambio, entre minutos y horas según el tiempo de vida de cada registro. La reputación no funciona así: si el dominio lleva meses acumulando quejas, hacen falta varias semanas enviando bien. Verifica con un mensaje real y su encabezado.
Solo me pasa con un cliente concreto. ¿Es mi problema o el suyo?
Consigue el encabezado de un mensaje tuyo que sí entró a otro proveedor y compáralo. Si sales con dmarc=pass en todas partes y solo ese destinatario bloquea, el filtro es suyo. Si en su encabezado ves permerror o dkim=fail y en el otro no, algo en el camino está modificando el mensaje.
¿Necesito una dirección IP dedicada para enviar correo?
Casi nunca, y con volumen pequeño suele ser contraproducente: una IP nueva no tiene historial y hay que calentarla por escalones. Una compartida de un proveedor serio llega con reputación construida. La dedicada tiene sentido con volumen alto y constante.
¿Puedo poner p=reject de una vez?
Puedes, y es la forma más rápida de quedarte incomunicado. Todo remitente legítimo sin autorizar deja de llegar. Publica p=none con informes, arma el inventario y sube la política cuando lleve una semana sin sorpresas. El camino completo toma entre tres y seis semanas.
¿Qué hago si mi dominio aparece en una lista de bloqueo?
Primero encuentra la causa: una computadora infectada, un buzón con la contraseña robada o un formulario web sin protección. Si pides el retiro sin cerrarla, vuelves a la lista en horas. Con el origen resuelto, las listas serias procesan el retiro solas cuando el envío abusivo cesa.
Mi proveedor de facturación envía por mi dominio y falla DMARC.
Es el caso clásico de alineación: firma con su propio dominio, así que puede pasar SPF y DKIM y aun así fallar DMARC. La solución no es abrir el SPF, es delegarle un subdominio de envío y que firme DKIM con él. El dominio principal conserva la política dura.
Ponemos tu correo donde debe estar
Revisamos autenticación, reputación y flujos de envío, y te entregamos el orden exacto de los cambios.