Un cliente abre un ticket: “Mis correos van a spam.” Sin cabeceras, sin mensaje de rebote, sin un ejemplo. Solo una afirmación — y sobre la que no puedes actuar, porque “spam” no es un estado que tu servidor reporte. El correo salió sin problema. Algo del lado que recibe decidió mandarlo a la basura.
Así que antes de tocar nada, convierte la queja vaga en las únicas dos preguntas que de verdad deciden si Gmail y Outlook confían en este servidor:
- ¿La IP que envía está en alguna lista negra que consulten los grandes proveedores? — reputación.
- ¿SPF, DKIM y DMARC resuelven de verdad, tal y como los ve el mundo ahora mismo? — autenticación.
Casi todo ticket de “mi correo va a spam” se reduce a una de esas dos. Lo demás — el cliente de correo, el asunto, la hora del día — es ruido hasta que las hayas descartado.
Por qué no es un “problema del servidor de correo”
El instinto es entrar a la máquina y hurgar en Exim o Postfix. Pero la cola está vacía y los logs dicen 250 OK: tu servidor entregó. El rechazo ocurrió en el borde del que recibe, milisegundos después, basándose en dos señales que calculó antes de leer una sola palabra del mensaje: ¿esta IP tiene reputación, y este dominio demuestra que autorizó el correo? Reiniciar el MTA no cambia ninguna.
La vía manual: Email → Entregabilidad
Abre el servidor, ve a Email y cambia a la pestaña Entregabilidad. Dos tarjetas responden las dos preguntas — sin dig, sin un comprobador externo, sin SSH.
Tarjeta 1 — reputación
La tarjeta de arriba barre la IP contra las listas negras que los grandes proveedores de correo consultan de verdad — Spamhaus, Barracuda, SpamCop — y muestra el veredicto por lista, con un enlace Solicitar exclusión en cuanto alguna vuelve como Listada.
Aquí el servidor está limpio en todas las listas grandes y solo lo marca UCEPROTECT L1. Esa importa menos de lo que parece: UCEPROTECT lista rangos /24 enteros por un solo vecino ruidoso, y la mayoría de los grandes receptores la ignoran. Pide la exclusión, claro — pero no esperes que sea la causa. La reputación está bien.
Tarjeta 2 — autenticación (el sospechoso de siempre)
La segunda tarjeta resuelve SPF, DKIM y DMARC de cada dominio alojado tal y como el DNS público los devuelve ahora mismo — no lo que el editor de zona del panel cree haber publicado. Esa distinción es justo el punto: un registro puede existir en el editor y aun así no resolver, por un typo, la zona equivocada o un override del registrador. Esta tarjeta muestra lo que los receptores realmente ven, que es la única versión que cuenta.
Y ahí está la prueba del delito:
acmeshop.com— SPF y DKIM pasan, pero falta DMARC. Sin DMARC, Gmail y Outlook no tienen una política en la que apoyarse y bajan el correo en silencio.acme-store.net— el SPF dice+all(autoriza a todo internet a enviar como este dominio — peor que no tener SPF) y el DMARC esp=none(publicado, pero sin aplicar nada).acmeblog.com— los tres en verde. Así se ve un dominio sano, y por eso este no está en spam.
El arreglo
Ahora el ticket sí es accionable:
- Publica un registro DMARC para
acmeshop.com— empieza enp=nonepara observar, luego pasa aquarantine. - Reemplaza el
+alldeacme-store.netpor una listainclude:real de quién tiene permitido enviar de verdad, y endurece el DMARC más allá dep=none.
Vuelve a abrir la pestaña cuando el DNS propague y los chips pasan a OK — confirmación de que el mundo que recibe ahora ve lo que pretendías, no una suposición esperanzada.
Dos tarjetas, un par de minutos
Esa es la vía manual de principio a fin: dos tarjetas convierten una queja sobre la que no podías actuar en una causa con nombre y un arreglo concreto, sin memorizar una sola invocación de dig ni fiarte de un registro solo porque el editor de zona lo muestra.
El AI Assistant hará este mismo pase de leer-y-explicar por ti — y, detrás de un gate de aprobación, escribirá los registros que faltan él mismo. Pero la pestaña de Entregabilidad es la verdad sobre la que razona, y el día que un cliente te escribe por el spam, son las dos preguntas más rápidas que puedes responder.