Políticas de cuarentena y carpeta de spam: deja de perder mensajes importantes

noviembre 5, 2025 • febrero 3, 2026 • Lectura: 29 min • Views: 7

¿Te fue útil?

La cuarentena de correo es donde los mensajes críticos para el negocio mueren en silencio. Pedidos de compra, restablecimientos de contraseña, avisos de RR. HH., retenciones legales, facturas de proveedores: cosas que sólo notas cuando llegan las consecuencias, normalmente con una invitación de calendario titulada «Charla rápida».

Si administras sistemas de producción, ya conoces el patrón: el filtro “funcionó” hasta que dejó de hacerlo. El modo de fallo no es dramático. Es silencioso. Y el silencio es el tipo de incidente más caro.

Qué es realmente la cuarentena (y qué no es)

La cuarentena no es “spam”. Es un área de retención creada por una decisión de política: este mensaje es lo bastante sospechoso como para retenerlo de la entrega, pero no lo bastante sospechoso como para eliminarlo inmediatamente. Esa distinción importa porque la cuarentena es tanto un plano de control como una función de seguridad:

Carpeta de spam normalmente vive en el buzón. El usuario puede verla. El mensaje está “entregado”, sólo redirigido a un destino de correo no deseado.
Cuarentena suele vivir fuera del buzón (pasarela de seguridad, consola de seguridad en la nube). El usuario puede no verla a menos que diseñes explícitamente un camino (resúmenes, portales de autoservicio, flujos de liberación).
Rechazo (SMTP 5xx) es un “no” firme durante la transacción SMTP. No se acepta el mensaje; confías en que el remitente reciba un rebote y corrija su configuración.
Descartar acepta y descarta. Operativamente seductor. A los auditores y a los respondedores de incidentes les disgusta. A los usuarios, más todavía.

Para la fiabilidad, la cuarentena es una cola. Como cualquier cola, necesita:

Visibilidad (qué hay dentro, por qué, cuánto tiempo)
Propiedad (quién la vacía y con qué autoridad)
SLOs (tiempo máximo para liberar falsos positivos; tasa máxima de falsos positivos por tipo de remitente)
Reglas de retropresión (qué ocurre cuando crece)

Por qué se pierden correos importantes: la mecánica real

La mayoría de las organizaciones tratan la cuarentena como un apéndice de seguridad. En realidad es un sistema distribuido con entradas desordenadas, autenticación inconsistente y una interfaz de usuario diseñada por alguien que piensa que a todo el mundo le gustan los “portales de seguridad”. Pierdes mensajes importantes porque una o más de estas mecánicas está en juego:

1) Fallos de autenticación que no son “maliciosos”, sólo descuidados

SPF, DKIM y DMARC no son opcionales si te importa la entregabilidad. Pero los flujos reales de correo corporativo incluyen CRM, sistemas de tickets, proveedores de nómina y plataformas de marketing. Esos sistemas envían en tu nombre. Algunos lo hacen bien. Otros lo hacen como un gato escribiendo en un teclado.

Cuando falla la autenticación, los filtros modernos no solo aumentan la puntuación de spam. Tratan el mensaje como de mayor riesgo de suplantación y phishing. Eso lo empuja a cuarentena aunque el contenido sea insípido y legítimo.

2) Los sistemas de reputación son herramientas toscas

Los grandes proveedores usan reputación del remitente, reputación de IP, reputación de dominio y bucles de retroalimentación de usuarios. La reputación se correlaciona con la “bondad”, pero no es idéntica. Un dominio nuevo de proveedor, una IP saliente recién rotada o una piscina de envío compartida por un SaaS pueden parecer sospechosos durante semanas.

3) Políticas sobreajustadas: alguien “arregló el phishing” ampliando la red

Las políticas de cuarentena a menudo se endurecen tras un incidente. Eso satisface emocionalmente. También es la manera de crear un fallo en cámara lenta que tarda meses en detectarse: compras dejan de ver facturas; ventas deja de ver leads; RR. HH. pierde respuestas de candidatos.

4) Fallos de experiencia de usuario: nadie revisa lo que no puede ver

Si los usuarios no reciben resúmenes de cuarentena, o si los propios resúmenes son filtrados (sí, pasa), la cuarentena se convierte en un cubo de basura invisible. El mejor filtro del mundo no puede ayudarte si retiene el correo en silencio y nadie tiene el hábito diario de revisarlo.

5) Errores de enrutamiento y conectores

El correo puede quedar en cuarentena antes de llegar a tu proveedor de buzones (pasarela), dentro del proveedor (filtro en la nube) o después de la entrega (reglas del cliente). Diagnosticar la capa equivocada desperdicia tiempo y genera el peor tipo de confianza: la confianza segura pero equivocada.

Una idea parafraseada de Werner Vogels (CTO de Amazon), a menudo repetida en círculos de operaciones: “Todo falla todo el tiempo; la resiliencia viene de diseñar pensando en el fallo.” Aplícalo al correo. La cuarentena es un modo de fallo. Diseña alrededor de ello.

Datos interesantes y breve historia del spam y la cuarentena

Dato 1: Uno de los mensajes masivos no solicitados más citados en Internet fue el email de marketing de ARPANET en 1978. La gente se quejó de inmediato. Algunas tradiciones son eternas.
Dato 2: El término “spam” para mensajes no solicitados se popularizó en los primeros años de Internet, y el problema creció con la automatización barata de envíos mucho antes de la “IA”.
Dato 3: El filtrado temprano de spam se basaba principalmente en palabras clave y era frágil; los sistemas modernos se apoyan en reputación, autenticación y señales de comportamiento.
Dato 4: SPF apareció a principios de los 2000 para intentar verificar hosts de envío. Redujo algunas falsificaciones, pero no valida por sí solo la identidad visible “From”.
Dato 5: DKIM introdujo firmas criptográficas a la identidad del correo. Es elegante en concepto, operacionalmente molesto en rotación y alineación.
Dato 6: DMARC vinculó SPF/DKIM al dominio visible “From” e introdujo la política (none/quarantine/reject). También introdujo un nuevo pasatiempo: leer informes agregados y darse cuenta de cuántos sistemas envían correo que olvidaste que existían.
Dato 7: “Cuarentena” como clase de política formal surgió con las pasarelas de seguridad empresariales y productos de seguridad de correo en la nube que querían controles más fuertes que “enviar a spam”.
Dato 8: Los bucles de retroalimentación (acciones de usuario “marcar como spam/no es spam”) cambian materialmente el filtrado. La formación de usuarios no es una habilidad blanda; es parte de tu canal de detección.
Dato 9: El correo electrónico es intencionalmente permisivo y compatible con versiones anteriores. Muchos fallos provienen de esa misma característica: el ecosistema tolera la mala configuración hasta que una política estricta deja de tolerarla.

Diseño de políticas: qué permitir, qué poner en cuarentena, qué rechazar

Si quieres dejar de perder mensajes importantes, necesitas una postura de política explícita. No “lo que venga por defecto”. Las políticas por defecto están diseñadas para el cliente medio. Tú no eres el cliente medio. Tienes proveedores, reguladores y personas que hacen clic en cosas.

Empieza con tres carriles, no con un gran cubo

Piense en carriles con controles y rutas de escalado distintas:

Remitentes empresariales conocidos y buenos: tus propios dominios, proveedores SaaS principales, socios críticos. Objetivo: entregar con fiabilidad; detectar compromiso mediante señales de anomalía, no cuarentenas toscas.
Desconocidos pero plausibles: proveedores nuevos, leads entrantes, candidatos, contactos aleatorios pero legítimos. Objetivo: minimizar falsos positivos; la cuarentena debe ser revisable y rápida de liberar.
Conocidos malos / alto riesgo: suplantación obvia, malware, fallos DMARC con política estricta, geografía imposible + patrones de phishing por credenciales. Objetivo: rechazar o poner en cuarentena sin auto-liberación.

Elige “reject” más a menudo de lo que piensas—para suplantación

Para dominios que controlas, DMARC con p=reject es la medida anti-suplantación más limpia. Reduce la cantidad de basura que tus usuarios deben evaluar. También fuerza a tu propio ecosistema de correo saliente a comportarse.

Pero no lo hagas a ciegas. Haz un inventario de tus remitentes primero (plataformas de marketing, sistemas de facturación, alertas). Si cambias a reject mientras la mitad de tus sistemas fallan en la alineación DKIM, crearás un fallo auto-infligido con una buena historia de seguridad y terribles resultados de negocio.

La cuarentena es apropiada cuando los humanos deben decidir

La cuarentena es para casos ambiguos donde quieres preservar el mensaje para revisión, análisis forense y liberación controlada. Los errores ocurren cuando la cuarentena se convierte en el método predeterminado de descarte.

La carpeta de spam es para ruido de bajo riesgo y alto volumen

La entrega a la carpeta de correo no deseado aún permite a los usuarios buscar y recuperar mensajes. Eso es una característica de fiabilidad. Para clasificaciones de spam de baja confianza (tipo boletín, marketing descuidado, correo masivo no malicioso), la carpeta de spam suele ser mejor que la cuarentena porque es recuperable.

Construye listas blancas como construirías reglas de firewall: con alcance, revisión y caducidad

La lista blanca es necesaria. También es la forma de blanquear por accidente a atacantes que comprometan a un proveedor.

Prefiere listas blancas por identidad autenticada (dominio de firma DKIM) sobre el dominio “From” visible.
Si debes listar por IP, documenta quién posee ese rango de IP y cómo serás notificado de cambios.
Añade fechas de expiración y ciclos de revisión. Las excepciones permanentes son como el riesgo que se convierte en política.

Broma 1: La cuarentena es como un cajón de trastos: todo entra, nada sale, y de alguna forma aún no encuentras el destornillador.

Gobernanza: quién puede liberar qué y cómo probarlo

La cuarentena es un límite de privilegios. Trátala como acceso a producción.

Define roles de liberación con claridad

Autoliberación por el usuario para spam de bajo riesgo y categorías masivas. Bueno para escalar, malo para phishing dirigido si no tienes cuidado.
Liberación por mesa de ayuda para mensajes críticos de negocio donde el usuario está bloqueado pero el riesgo es bajo. Requiere formación y registros.
Liberación solo por seguridad para suplantación, malware, phishing por credenciales y fallos DMARC. Nunca se debe pedir a los usuarios que “decidan” en esos casos.

Exige códigos de motivo y retención

Cuando se libera un mensaje, quieres:

Quién lo liberó
Por qué (código de motivo)
Qué clasificador disparó la cuarentena
Qué evidencia apoyó la liberación (autenticación pasada, sandbox limpio, remitente verificado)
Duración de retención tanto para artefactos en cuarentena como liberados

Los resúmenes no son opcionales

Un resumen diario de cuarentena para usuarios (o al menos para equipos con alta dependencia externa como Ventas, Compras, RR. HH.) es un seguro barato. Pero debe ser:

En horario consistente
No filtrado en sí mismo
Accionable (flujos de liberación/solicitud que funcionen en móvil)
Auditable (quién solicitó la liberación)

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando alguien dice: “No recibí el correo”, no empieces cambiando umbrales de filtro. Así es como conviertes un mensaje faltante en una nueva clase de incidentes.

Primero: Identifica la capa donde desapareció el mensaje

¿El remitente realmente lo envió? Pide marca de tiempo, destinatario, asunto y, idealmente, el Message-ID del remitente.
Revisa el rastro de mensajes del proveedor (Microsoft 365 / Google Workspace) para eventos de entrega/cuarentena.
Revisa los logs de tu pasarela si la tienes (Proofpoint, Mimecast, Postfix/Amavis on‑prem, etc.).

Segundo: Confirma autenticación y alineación

Inspecciona cabeceras de un mensaje similar que llegó (o desde la vista previa de cuarentena).
Verifica SPF pass/fail y qué IP se evaluó.
Verifica validez de la firma DKIM y el dominio de firma.
Verifica resultado de alineación DMARC y acción de política.

Tercero: Decide si es política, reputación o contenido

Si falla la autenticación: corrige la configuración del remitente, no lo parchees con listas blancas.
Si la autenticación pasa pero aún está en cuarentena: examina reputación, reportes de usuarios y disparadores de contenido (URLs, adjuntos, macros).
Si es un único destinatario: revisa reglas de buzón, filtros del cliente o listas de remitentes seguras específicas del usuario.

Tareas prácticas: comandos, salidas, decisiones (12+)

El objetivo de las tareas no es “coleccionar logs”. Es tomar una decisión y actuar. Abajo hay comprobaciones concretas que puedes ejecutar en infraestructura de correo Linux, además de pasos de DNS e inspección de mensajes que aplican aunque uses proveedores en la nube.

Task 1: Confirmar que el registro SPF del dominio existe y no está claramente roto

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.mailvendor.example -all"

Qué significa la salida: El dominio publica SPF. Autoriza un rango IPv4 específico y un include de proveedor, y termina con -all (fallo estricto).

Decisión: Si la IP del remitente no está en ese rango o include, SPF fallará. Corrige el registro SPF o envía desde un sistema autorizado. No listes en blanco el fallo.

Task 2: Verificar si SPF excede límites de búsquedas DNS (un fallo silencioso común)

cr0x@server:~$ python3 - <<'PY'
import dns.resolver, re
domain="example.com"
txts=[]
for r in dns.resolver.resolve(domain,"TXT"):
    s="".join([b.decode() for b in r.strings])
    if s.startswith("v=spf1"):
        txts.append(s)
spf=txts[0]
includes=re.findall(r'include:([^\s]+)', spf)
print("SPF:", spf)
print("Includes:", includes)
print("Note: SPF has a 10 DNS-lookup limit (includes, a, mx, ptr, exists, redirect).")
PY
SPF: v=spf1 ip4:203.0.113.0/24 include:_spf.mailvendor.example -all
Includes: ['_spf.mailvendor.example']
Note: SPF has a 10 DNS-lookup limit (includes, a, mx, ptr, exists, redirect).

Qué significa la salida: Esta comprobación sencilla muestra includes; los registros complejos a menudo encadenan includes y superan el límite de búsquedas.

Decisión: Si tu SPF es una muñeca rusa de includes, aplánalo o usa subdominios por remitente. El “permerror” de SPF a menudo se correlaciona con cuarentena.

Task 3: Verificar que existe el registro selector DKIM

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Qué significa la salida: La clave pública DKIM existe para el selector s1.

Decisión: Si falta DKIM para el selector usado por tu remitente, las firmas fallarán y aumentará el riesgo de cuarentena. Corrige al remitente o publica el registro correcto.

Task 4: Comprobar la política DMARC y las direcciones de reporte

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-afrf@example.com; adkim=s; aspf=s"

Qué significa la salida: DMARC está configurado en quarantine y usa alineación estricta para DKIM y SPF.

Decisión: La alineación estricta rompe más remitentes terceros. Si pierdes correo legítimo enviado “como tú”, configura al proveedor correctamente o relaja la alineación cuando esté justificado.

Task 5: Inspeccionar la cabecera de un mensaje en cuarentena para resultados de autenticación

cr0x@server:~$ grep -iE 'Authentication-Results|Received-SPF|DKIM-Signature|From:' -n quarantined.eml | head
12:From: "Accounts Payable" <ap@example.com>
45:Received-SPF: fail (example.com: domain of ap@example.com does not designate 198.51.100.25 as permitted sender) receiver=mx1.local;
78:Authentication-Results: mx1.local; spf=fail smtp.mailfrom=ap@example.com; dkim=none; dmarc=fail (p=quarantine) header.from=example.com

Qué significa la salida: SPF falló, DKIM está ausente, DMARC falló. Esto no es “el filtro portándose mal”. Es el remitente sin probar su identidad.

Decisión: Trátalo como suplantación hasta verificarlo fuera de banda. Si es un proveedor real, haz que arreglen su configuración de envío. Si es interno, arregla tus propios sistemas salientes.

Task 6: En Postfix, busca logs por destinatario y periodo

cr0x@server:~$ sudo grep -E "to=<user@example.com>|user@example.com" /var/log/mail.log | tail -n 5
Jan 04 10:11:32 mx1 postfix/smtpd[21102]: connect from mail.sender.tld[198.51.100.25]
Jan 04 10:11:33 mx1 postfix/cleanup[21110]: 9A1B02C3D1: message-id=<20260104101132.12345@mail.sender.tld>
Jan 04 10:11:33 mx1 postfix/qmgr[1033]: 9A1B02C3D1: from=<ap@example.com>, size=48219, nrcpt=1 (queue active)
Jan 04 10:11:34 mx1 postfix/smtp[21112]: 9A1B02C3D1: to=<user@example.com>, relay=filter.local[127.0.0.1]:10024, delay=1.2, delays=0.2/0.01/0.3/0.7, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5F7E9D0A12)
Jan 04 10:11:35 mx1 postfix/qmgr[1033]: 9A1B02C3D1: removed

Qué significa la salida: Postfix aceptó el mensaje y lo pasó a un filtro de contenido (común con Amavis/SpamAssassin). El “queued as …” indica el ID del siguiente salto.

Decisión: La desaparición probablemente ocurrió en la etapa de filtro/cuarentena, no en la recepción SMTP. Ahora sigue el segundo ID de cola en los logs del filtro.

Task 7: En Amavis, averigua si el mensaje fue puesto en cuarentena

cr0x@server:~$ sudo grep -R "5F7E9D0A12" /var/log/amavis/amavis.log | tail -n 3
Jan 04 10:11:34 mx1 amavis[3091]: (03091-12) Passed CLEAN, but quarantined by policy, MESSAGE-ID: <20260104101132.12345@mail.sender.tld>
Jan 04 10:11:34 mx1 amavis[3091]: (03091-12) quarantine: local:spam-20260104-101134-03091-12
Jan 04 10:11:34 mx1 amavis[3091]: (03091-12) Tests: DKIM_NONE,SPF_FAIL,DMARC_FAIL score=6.3 tagged_above=-9999 required=5.0

Qué significa la salida: El mensaje fue clasificado y puesto en cuarentena por política y puntuación. Se registra la ubicación de la cuarentena.

Decisión: Valida si la política es correcta: ¿era esto una factura real o una suplantación? Si es real, arregla la autenticación; no subas el umbral globalmente.

Task 8: Comprueba la cola de correo por retropresión (a veces la cuarentena es simplemente “correo atascado”)

cr0x@server:~$ mailq | head -n 15
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A12BC34D56*    9210 Thu Jan  4 10:05:12  ap@example.com
                                         user@example.com

B98FE76A10*   48219 Thu Jan  4 10:06:01  noreply@vendor.tld
                                         user2@example.com
-- 2 Kbytes in 2 Requests.

Qué significa la salida: Asteriscos indican entradas de cola activas aún no entregadas. Si las colas se acumulan, los mensajes pueden llegar tarde y percibirse como “perdidos”, o el remitente puede agotar el tiempo.

Decisión: Si la cola crece, trátalo como un incidente de disponibilidad: revisa la salud del filtro downstream, DNS y límites de tasa. No confundas “retrasado” con “en cuarentena”.

Task 9: Validar salud de resolución DNS (los filtros dependen constantemente del DNS)

cr0x@server:~$ resolvectl query _dmarc.example.com
_dmarc.example.com: 192.0.2.53         -- link: eth0
                     (TXT) "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com"

Qué significa la salida: DNS es resolvible desde el host de correo. Si esto falla intermitentemente, las comprobaciones SPF/DKIM/DMARC pueden degradarse a tempfail/permerror y cambiar las decisiones de filtrado.

Decisión: Si el DNS es inestable, arréglalo antes de ajustar umbrales de spam. Si no, estarás ajustando el filtro para compensar errores de infraestructura.

Task 10: Confirmar TLS y presentación de certificado desde tu MX entrante (diagnóstico desde lado remitente)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx.example.com:25 -servername mx.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx.example.com
Verification: OK

Qué significa la salida: Tu MX ofrece STARTTLS y presenta un certificado válido. Una mala postura TLS puede reducir la reputación y hacer que algunos remitentes te traten con sospecha.

Decisión: Si la verificación falla o falta STARTTLS donde se espera, arregla TLS. No es la causa principal de cuarentena, pero contribuye silenciosamente a la fricción de entregabilidad.

Task 11: Usar SpamAssassin para ver por qué el contenido puntuó alto

cr0x@server:~$ spamassassin -t < quarantined.eml | head -n 25
SpamAssassin version 3.4.6
X-Spam-Flag: YES
X-Spam-Score: 6.3
X-Spam-Level: ******
X-Spam-Status: Yes, score=6.3 required=5.0 tests=DKIM_NONE,DMARC_FAIL,SPF_FAIL,URIBL_BLOCKED
        DKIM_NONE           0.1  Message has no DKIM signature
        SPF_FAIL            3.5  SPF check failed
        DMARC_FAIL          2.0  DMARC check failed
        URIBL_BLOCKED       0.0  URIBL: query blocked (maybe missing DNS)

Qué significa la salida: Las fallas de autenticación dominan la puntuación. Observa también URIBL_BLOCKED, a menudo debido a DNS o restricciones de política; puede sesgar la clasificación.

Decisión: Arregla la autenticación primero. Si URIBL está bloqueado por tu política DNS, ajusta la configuración de URIBL para que no genere ruido en la puntuación.

Task 12: Verificar problemas de SRS/reenvío (fuente común de falsos positivos)

cr0x@server:~$ grep -i "SRS0" -n quarantined.eml | head
102:Return-Path: <SRS0=HhZx=AB=example.com=ap@example.com@forwarder.tld>

Qué significa la salida: El mensaje pasó por un reenviador usando SRS (Sender Rewriting Scheme). Si el reenviador no usa SRS, SPF a menudo fallará, aumentando la probabilidad de cuarentena.

Decisión: Si hay reenvío, prefiere remitentes alineados con DKIM/DMARC y asegúrate de que los reenviadores soporten SRS. De lo contrario, espera cuarentenas relacionadas con SPF.

Task 13: Revisar reglas locales de buzón que imitan “cuarentena” (la trampa del lado usuario)

cr0x@server:~$ doveadm sieve list -u user@example.com
1. "move-suspicious-to-archive"
2. "auto-forward"

Qué significa la salida: El usuario tiene reglas Sieve. Una regla podría estar moviendo el correo fuera de la Bandeja de entrada, haciendo que parezca “perdido”.

Decisión: Si es específico del usuario, corrige la regla o forma al usuario. No toques la política global de spam por un fallo de ordenación local.

Task 14: Medir volumen y tendencia de la cuarentena (porque “se siente peor” no es una métrica)

cr0x@server:~$ sudo awk '/quarantine:/{count++} END{print "quarantined_messages_today="count}' /var/log/amavis/amavis.log
quarantined_messages_today=184

Qué significa la salida: Tienes un recuento diario. Combínalo con el total de entrada para obtener una tasa de cuarentena y detectar cambios bruscos tras ediciones de política.

Decisión: Si el volumen de cuarentena se dispara tras un cambio, revierte o estrecha la regla. Si sube sin cambios, sospecha de variaciones de reputación o fallos de DNS/autenticación.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición errónea

La empresa había desplegado una nueva pasarela de seguridad de correo brillante. Venía con una política de cuarentena por defecto que parecía “razonable” y un panel que lucía “verde”. La suposición: si un mensaje fue puesto en cuarentena, el destinatario previsto lo sabría y podría auto-liberarlo. Esa suposición fue falsa en tres formas diferentes.

Primero, los resúmenes de cuarentena estaban deshabilitados porque alguien temía que “capacitaran a los usuarios para hacer clic en enlaces”. Segundo, la auto-liberación solo estaba permitida para un pequeño grupo de usuarios de TI. Tercero, la mesa de ayuda no tenía permiso para liberar mensajes; seguridad sí, pero seguridad no tenía función de triage operativa.

La falla se descubrió cuando Cuentas por Pagar no recibió una actualización de datos bancarios de un proveedor (la legítima, no la fraudulenta). La factura posterior se retrasó y el proveedor pausó envíos. Compras culpó a Cuentas por Pagar, Cuentas por Pagar culpó al proveedor, el proveedor culpó a “su correo” y TI fue llamado al final porque el correo siempre funciona hasta que no.

Cuando finalmente lo rastrearon, el mensaje había sido puesto en cuarentena por fallo DMARC. El proveedor usaba una plataforma de facturación de terceros que enviaba correo desde el dominio del proveedor sin alineación DKIM. No era malicioso. Simplemente estaba mal configurado.

La solución no fue “bajar el umbral”. La solución fue gobernanza y visibilidad: habilitar resúmenes para equipos con alta dependencia, añadir una vía de liberación por mesa de ayuda con salvaguardas y exigir a los proveedores autenticar correctamente. La pieza que faltaba no era tecnología. Era propiedad.

Mini-historia 2: La optimización que salió mal

Un equipo de seguridad quería menos incidentes de phishing y respuesta más rápida. Introdujeron una regla de “auto-cuarentena para cualquier cosa que mencione transferencia bancaria”. Fue presentada como una victoria rápida: detener Business Email Compromise capturando el cebo obvio.

El primer día el tablero lucía genial. Los números de cuarentena aumentaron. Los reportes de phishing bajaron. El equipo celebró el movimiento del KPI. Una semana después, finanzas escaló: los correos de remesas de proveedores llegaban tarde o no llegaban, y los ciclos de pago se desordenaron.

La política tuvo un patrón clásico de retroceso: una regla de contenido de alta sensibilidad aplicada a un dominio de negocio de alto valor. No sólo capturó estafas. Capturó flujos legítimos de finanzas, especialmente mensajes de fin de trimestre con instrucciones reales de transferencia.

El equipo había optimizado para un solo métrico (reportes de phishing) y degradado accidentalmente otro SLO (disponibilidad de mensajes críticos para finanzas). Revirtieron la regla de contenido y la reemplazaron por un control más estrecho: aplicar DMARC reject en sus propios dominios, añadir verificación de proveedores para cambios de cuenta bancaria y cuarentenar sólo cuando la autenticación o la reputación de URL fuera sospechosa—no cuando un mensaje osara contener la palabra “transferencia”.

Broma 2: Nada dice “éxito de seguridad” como bloquear la nómina un viernes por la tarde.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa SaaS mediana tenía una costumbre que en papel parecía poco emocionante: una revisión semanal de “triage de cuarentena” entre seguridad, mesa de ayuda y los equipos que reciben correo externo de alto valor (Operaciones de Ventas, RR. HH., Cuentas por Pagar). Treinta minutos. Mismo orden del día siempre.

Revisaban una pequeña muestra de mensajes en cuarentena: principales remitentes, principales motivos y cualquier liberación que pareciera arriesgada. También seguían una métrica simple: tiempo de liberación para falsos positivos que afectan a ingresos o nómina. No buscaban la perfección. Buscaban repetibilidad.

Un mes, incorporaron una nueva plataforma de reclutamiento. En días, las respuestas de candidatos comenzaron a caer en cuarentena. La reunión de triage lo detectó rápido porque RR. HH. lo marcó como “alto impacto”, y la muestra de cuarentena mostró fallos DKIM consistentes.

La solución fue limpia: el proveedor tenía DKIM habilitado pero firmaba con un dominio distinto al visible en From, rompiendo la alineación DMARC en modo estricto. El proveedor actualizó su configuración; la empresa añadió una excepción temporal y acotada (permitir dominio de firma DKIM para ese remitente) con fecha de caducidad.

Sin drama, sin sala de guerra, sin escalado ejecutivo. Lo aburrido funciona. La empresa trató la cuarentena como una cola de producción con monitorización y revisión, no como una caja misteriosa.

Errores comunes: síntomas → causa raíz → solución

Síntoma: “Los correos de un proveedor siempre van a cuarentena, pero sólo para algunos destinatarios.”: Causa raíz: Listas de remitentes seguros a nivel de usuario, reglas de buzón o políticas de amenaza por usuario que difieren (especialmente con licencias/roles mixtos). A veces el proveedor es enrutado por caminos entrantes diferentes (MX regional, grupos de política de pasarela distintos).; Solución: Compara eventos de rastro de mensajes entre destinatarios; revisa reglas de usuario; normaliza políticas por usuario para equipos de alto valor; evita configuraciones “copito de nieve” sin ticket.
Síntoma: “Todo empezó a ir a cuarentena después de activar DMARC quarantine/reject.”: Causa raíz: Activaste la política antes de inventariar todos tus remitentes legítimos. Terceros envían como tu dominio pero fallan la alineación.; Solución: Audita fuentes salientes, configura DKIM para cada una, usa subdominios dedicados para proveedores y luego mueve DMARC de none → quarantine → reject gradualmente.
Síntoma: “Los usuarios juran que revisaron spam/basura y no está allí.”: Causa raíz: Está en cuarentena fuera del buzón, o fue rechazado en tiempo SMTP. Los usuarios no pueden ver ninguna de las dos cosas.; Solución: Establece un ingreso estándar: remitente, destinatario, hora, Message-ID. Usa rastro de mensajes/logs de pasarela. Proporciona un portal de autoservicio de cuarentena o un flujo rápido de liberación por mesa de ayuda.
Síntoma: “Los correos resumen de cuarentena no llegan.”: Causa raíz: El remitente del resumen está siendo filtrado, o DMARC falla para el dominio del resumen, o el resumen es bloqueado por una regla interna que lo trata como correo masivo.; Solución: Asegura que los mensajes de resumen se autentiquen (SPF/DKIM/DMARC). Lista en blanco al remitente del resumen por identidad autenticada. Monitoriza la entrega de resúmenes por separado.
Síntoma: “Un correo reenviado siempre queda en cuarentena.”: Causa raíz: SPF se rompe en el reenvío a menos que se use SRS; la alineación DMARC puede fallar; pueden faltar cabeceras ARC o no ser confiables.; Solución: Prefiere remitentes alineados con DKIM; asegúrate de que los reenviadores implementen SRS; evalúa soporte ARC en tu stack de filtrado; reduce la dependencia de reenvíos ingenuos para flujos críticos.
Síntoma: “Listamos en blanco el dominio pero aún así a veces lo pone en cuarentena.”: Causa raíz: Listaste por el dominio visible From, pero la infraestructura de envío real varía (múltiples pools SaaS, diferentes dominios DKIM, remitentes de sobre distintos). O la regla se evalúa después de otros bloqueos.; Solución: Lista en blanco por dominio de firma DKIM o por un atributo autenticado estable. Verifica el orden y precedencia de reglas. Mantén las excepciones acotadas y probadas.
Síntoma: “Tras un cambio de DNS, los falsos positivos explotaron.”: Causa raíz: Se rompieron includes de SPF, faltó selector DKIM, registro DMARC malformado o resolutores fallando intermitentemente. Los filtros interpretan fallos de autenticación como riesgo.; Solución: Añade controles para cambios DNS: preflight checks, reducción de TTL por etapas, verificación post‑cambio (consultas SPF/DKIM/DMARC) y monitorización de tasas de fallo de autenticación.

Listas de verificación / plan paso a paso

Checklist A: Construir una política de cuarentena que no se coma el negocio

Clasifica el correo entrante por criticidad de negocio: finanzas, RR. HH., legal, ventas, soporte. Pon responsables sobre papel.
Define carriles: conocido-bueno, desconocido-pero-plausible, conocido-malo/alto-riesgo.
Decide acciones por carril: entregar a bandeja, entregar a carpeta spam, poner en cuarentena, rechazar.
Establece TTLs de cuarentena: cuánto tiempo mantienes elementos antes de borrarlos. Asegúrate de que coincida con tus necesidades de investigación.
Establece roles de liberación: usuario/mesa de ayuda/seguridad; añade códigos de motivo y registro.
Habilita resúmenes para equipos con alta dependencia; asegura la entregabilidad de los resúmenes.
Implementa gestión de excepciones: listas blancas acotadas, fechas de caducidad, cadencia de revisión.
Métricas: tasa de cuarentena, tasa de falsos positivos, tiempo de liberación para equipos críticos, principales motivos de cuarentena.

Checklist B: Paso a paso cuando un correo crítico está “perdido”

Recopila hechos mínimos: dirección del remitente, destinatario, hora aproximada, asunto y cualquier Message-ID que el remitente pueda aportar.
Determina la capa: rastro de mensajes (proveedor), logs de pasarela, reglas de buzón.
Encuentra la disposición: entregado, enviado a basura, en cuarentena, rechazado, diferido.
Si fue rechazado: obtén el código de respuesta SMTP y corrige autenticación o enrutamiento del remitente.
Si está en cuarentena: identifica el clasificador (SPF/DKIM/DMARC, URL, adjunto, regla de contenido).
Toma la decisión segura: si falla la autenticación y se parece a suplantación de negocio, no liberes a ciegas.
Remedia la causa raíz: ajusta DNS/autenticación para remitentes legítimos; endurece controles para los maliciosos; documenta cualquier excepción.
Cierra el ciclo: notifica al usuario, registra la razón y añade el evento al triage semanal si se repite.

Checklist C: Reglas de excepción que no te perseguirán

Prefiere atributos autenticados (DKIM d=, remitente de sobre validado por SPF) sobre nombres mostrados o dominios From.
Acota por grupo de destinatarios cuando sea posible (equipo de finanzas) en lugar de “dejar pasar todo” globalmente.
Pon una fecha de caducidad en el título del ticket. Sí, literalmente en el título.
Añade un paso de validación: después del cambio de regla, envía un mensaje de prueba y confirma la disposición.
Revisa excepciones mensualmente. Elimina las obsoletas. Si nunca eliminas excepciones, no las estás gestionando — las estás coleccionando.

Preguntas frecuentes

1) ¿Deberíamos enviar los mensajes en cuarentena a la carpeta de spam del usuario en su lugar?

A veces. Para correo masivo de bajo riesgo y spam sospechoso, la entrega a la carpeta spam mejora la recuperabilidad. Para phishing/malware/suplantación de alto riesgo, mantiene la cuarentena fuera del buzón y restringe la liberación.

2) ¿Es razonable listar en blanco el dominio de un proveedor como solución?

Sólo como medida temporal, y preferiblemente basada en identidad autenticada (dominio de firma DKIM) en lugar del From visible. A largo plazo, haz que el proveedor arregle SPF/DKIM/DMARC. Si no, estás confiando en el campo más fácil de falsificar.

3) ¿Por qué pasan mensajes ayer y hoy están en cuarentena sin cambio de política?

Cambios de reputación, cambios de contenido (nuevos enlaces/adjuntos) o deriva en autenticación (IP rotada, clave DKIM expirada, propagación DNS) pueden cambiar la puntuación. También importan los bucles de retroalimentación: si usuarios marcaron mensajes similares como spam, los clasificadores se adaptan.

4) ¿Cuál es la diferencia entre “quarantine” y “reject” en DMARC?

DMARC p=quarantine indica que el correo que falla debe tratarse como sospechoso (a menudo entregado a spam o puesto en cuarentena). p=reject pide a los receptores rechazarlo en tiempo SMTP. Reject reduce la exposición de usuarios a la suplantación pero requiere que tus remitentes legítimos estén alineados.

5) ¿Podemos confiar en que los usuarios liberen sus propios mensajes en cuarentena?

Para categorías de bajo riesgo, sí, con formación y buena interfaz. Para suplantación y phishing por credenciales, no. Los usuarios no son un control de seguridad; son carga de trabajo con calendarios.

6) ¿Por qué los mensajes reenviados son castigados?

El reenvío cambia la IP de envío, lo que rompe SPF a menos que el reenviador use SRS. DKIM puede sobrevivir al reenvío, pero algunos reenviadores modifican el contenido y rompen las firmas. La alineación DMARC falla y los filtros se muestran sospechosos.

7) ¿Cuánto tiempo debemos retener el correo en cuarentena?

Lo suficiente para soportar investigaciones y recuperación por parte del usuario, y lo suficientemente corto para limitar riesgo y almacenamiento. Muchas organizaciones eligen 15–30 días para la cuarentena general y más tiempo para retenciones solo de seguridad durante una investigación. Elige un número, documéntalo y hazlo localizable.

8) ¿Qué métricas me indican que “estamos perdiendo mensajes importantes”?

Sigue tiempo de liberación para equipos de alto impacto, cuarentenas repetidas para los mismos remitentes legítimos y la proporción de cuarentena/entrantes. Combínalas con tickets de usuarios por “correo perdido”. Si los tickets se disparan tras un cambio de política, ese es tu canario.

9) ¿Podemos eliminar la cuarentena por completo?

Puedes reducir la dependencia de la cuarentena aplicando autenticación fuerte, usando reject para suplantación clara y entregando borderline bulk a carpetas spam. Pero existe ambigüedad. La cuarentena es útil—cuando es visible y gobernada.

10) ¿Cuál es la primera mejora más segura si partimos del caos?

Habilita resúmenes de cuarentena (o un informe diario) para los equipos que dependen del correo externo y define un proceso de liberación por mesa de ayuda con registro. Eso reduce inmediatamente la pérdida silenciosa mientras arreglas autenticación y ajustes de política.

Conclusión: próximos pasos que realmente reducen pérdidas

Si quieres dejar de perder mensajes importantes, deja de tratar la cuarentena como un sumidero mágico de seguridad y empieza a tratarla como una cola de producción con propietarios, métricas y un flujo de liberación.

Hoy: Enciende la visibilidad (resúmenes/acceso al portal) y define quién puede liberar qué.
Esta semana: Construye un flujo rápido de diagnóstico: rastro de mensajes → logs de pasarela → resultados de cabeceras de autenticación → decisión de política. Hazlo un runbook, no conocimiento tribal.
Este mes: Arregla autenticación y alineación para tus dominios y tus principales remitentes terceros. Reduce excepciones obligando a los remitentes a comportarse.
Continuo: Ejecuta un triage semanal de cuarentena con propietarios de negocio. Es aburrido. Mantenlo aburrido. Lo aburrido es fiable.