Revisión semanal de entregabilidad: qué comprobar en cada dominio de cliente

Lunes por la mañana, y once dominios tienen su nombre pegado: el propio y otros diez que pertenecen a clientes que asumen que el correo es un problema resuelto. Nada está en llamas. Ese es el problema. Nada les avisa de que un contratista editó una zona DNS el jueves, o de que la IP compartida detrás del boletín de un cliente terminó en una lista de bloqueo durante el fin de semana.

La revisión semanal es como la mayoría de las agencias resuelve eso. Funciona hasta cierto punto, y dónde queda ese punto importa tanto como las comprobaciones.

Las cuatro señales que de verdad se mueven

La entregabilidad tiene una superficie enorme y una lista corta de cosas que cambian de una semana a otra sin que nadie lo decida:

1. Registros de autenticación. La gente edita el DNS. Se agrega un proveedor y el registro SPF termina partido en dos. La plataforma de envío rota una clave y el selector nuevo nunca se publica.
2. Estado en las listas de bloqueo. Muchas veces no tiene nada que ver con el remitente. Una IP compartida hereda el error de un vecino, o una dirección antigua de alguna lista resulta ser una trampa de spam.
3. La mezcla de fuentes en DMARC. Una fuente de envío nueva que aparece en los reportes es o una herramienta de la que nadie habló o alguien suplantando el dominio.
4. Reputación del lado del proveedor. Llega con retraso y se mueve despacio, pero es la única vista que Gmail ofrece de cómo trata realmente el dominio.

Todo lo demás, o no se mueve a un ritmo semanal (higiene de lista, plantillas, práctica de envío) o se mueve tan despacio que una revisión semanal es el instrumento equivocado. Limiten la revisión a esas cuatro cosas por dominio y a nada más.

Señal 1: los registros de autenticación, contra una línea base conocida

Así se ve un conjunto de registros sano cuando se consulta directamente:

dig +short TXT example.com
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; fo=1"

Tres formas de fallo cubren casi todo lo que aparece en la práctica. Dos respuestas TXT separadas que empiezan ambas con v=spf1, lo cual es inválido según RFC 7208 y hace fallar la verificación completa en lugar de unir las dos. Una respuesta vacía en un selector DKIM, que significa que la clave se rotó o que su publicación nunca se terminó. Y un registro _dmarc ausente en un dominio que lo tuvo el mes pasado, normalmente porque la zona se reconstruyó en un host de DNS nuevo.

Vale la pena revisar algo más que la existencia: el conteo de consultas del SPF. Un proveedor puede agregar un include: dentro de su propio registro y empujar un dominio más allá del límite de diez consultas sin que nadie toque su DNS. El SPF flattener muestra el árbol completo cuando un registro está cerca del límite, y el chequeo de salud del correo devuelve un veredicto por dominio en lugar de tres respuestas en bruto.

La trampa que ninguna disciplina corrige: una consulta dice qué contiene el registro ahora mismo, y la revisión solo significa algo contra una línea base guardada. Mantener esa línea base al día para once dominios, a mano, es la parte que en silencio deja de hacerse hacia el tercer mes. LitInboxes vuelve a ejecutar estas verificaciones cada seis horas por dominio y guarda cada resultado, así que la comparación ya está hecha y cada cambio lleva la fecha en que ocurrió. En cualquier caso, la revisión necesita un antes, no solo un después.

Señal 2: las cuatro listas de bloqueo que ameritan acción

El estado en una lista de bloqueo es una respuesta DNS. Para las zonas basadas en IP, los octetos de la IP de envío se invierten y se agrega la zona al final:

dig +short 24.100.51.198.zen.spamhaus.org
127.0.0.4

Cualquier respuesta 127.0.0.x es una inclusión en la lista, y el último octeto identifica qué conjunto de datos atrapó la IP. Sin respuesta significa limpio. La que confunde a la gente es 127.255.255.254, que no es una inclusión: es Spamhaus rechazando una consulta que llegó por un resolutor público grande como 8.8.8.8 o 1.1.1.1. Su DNSBL usage FAQ documenta los códigos.

Las zonas basadas en dominio llevan el nombre de host en lugar de una IP invertida:

dig +short example.com.dbl.spamhaus.org

Cuatro listas corresponden de forma confiable a daño real en la bandeja de entrada: Spamhaus ZEN y DBL, Barracuda y SpamCop. Revisen la IP de envío y el dominio por separado, porque los incluyen en listas por razones distintas y normalmente solo uno de los dos es el que ustedes pueden corregir. El verificador de listas de bloqueo ejecuta el conjunto amplio sobre un solo dominio cuando hace falta una respuesta rápida.

El costo manual aquí es aritmética. Dos consultas por lista, por cuatro listas, por once dominios, son ochenta y ocho consultas un lunes, y cada una describe solo este momento. Una inclusión que llega el martes y aparece seis días después tuvo una semana completa de envíos para hacer daño. LitInboxes consulta ocho zonas de alta señal según un cronograma y alerta sobre la transición, no sobre el estado. Si la revisión sigue siendo manual, anoten la fecha de cada pasada limpia, para que una inclusión posterior al menos quede acotada a una semana.

Señal 3: el delta de fuentes de correo en DMARC, no los reportes

Nadie lee los reportes agregados de DMARC completos. Un reporte RUA en bruto es XML con un bloque de registro por fuente, y la parte que lleva información se ve así:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
</record>

Tres preguntas por fuente, y solo tres: quién falló, si es suyo y si es nuevo. Un reenviador conocido que falla SPF todas las semanas es ruido, porque el reenvío rompe SPF por diseño y la alineación de DMARC a través de DKIM es lo que sobrevive al reenvío. Una fuente que nadie reconoce, enviando 400 mensajes bajo el dominio From de un cliente, es la razón para abrir los reportes.

Dos de esas tres preguntas se responden por comparación, no por lectura. “¿Es nuevo?” necesita la lista de fuentes de la semana pasada para el mismo dominio, así que la revisión depende de un registro que alguien guardó. LitInboxes ingiere los reportes y destaca las fuentes que cambiaron, que es contabilidad que conviene entregarle a algo que no olvida. En cualquier caso, persigan lo que es nuevo o está por encima de aproximadamente el uno por ciento del volumen y dejen el resto en paz.

Señal 4: la reputación y el número que tiene un umbral

Google Postmaster Tools es gratuito y es el único lugar donde Gmail dice algo. Importan dos números: la reputación del dominio y la tasa de spam contra el techo del 0.3% de las directrices para remitentes de Google, especificada para remitentes masivos desde febrero de 2024. Por debajo de unos pocos miles de mensajes al día los gráficos quedan con huecos, así que un solo día malo a volumen bajo es una tormenta pasajera, no el clima.

La versión manual es un inicio de sesión en el navegador por cliente, por semana, sin nada que vigile en el medio y sin alerta cuando una línea cruza el umbral. La reputación se mueve despacio en ambas direcciones, así que la señal es la tendencia a lo largo de las semanas, no el valor del lunes, y una tendencia necesita historial que una mirada semanal no crea. Anoten por escrito el estado de reputación de cada dominio, porque el valor de ese número vive en su valor anterior.

El orden de prioridad cuando una se pone en rojo

Dos señales se ponen en rojo a la vez con la frecuencia suficiente para que el orden importe. Trabajen de arriba hacia abajo y deténganse en la primera causa encontrada:

1. Un registro de autenticación roto. Reparen el DNS y después compruébenlo con un mensaje nuevo, porque un registro corregido no hace nada por el correo ya enviado. Lean la línea Authentication-Results del mensaje nuevo en el analizador de encabezados antes de darlo por resuelto.
2. Una inclusión en una lista de bloqueo de la IP de envío o del dominio. Salgan de la lista por el proceso gratuito de la propia lista y después busquen la causa, en ese orden. Nunca paguen por la eliminación express.
3. Tasa de spam por encima del 0.3%. Detengan el siguiente envío. Miren la última campaña y el segmento al que fue, no la plantilla.
4. Una fuente nueva que falla en DMARC. Identifiquen la fuente antes de tocar la política. Endurecer a p=reject mientras un proveedor legítimo está desalineado rompe correo real.
5. Reputación a la baja con todo lo demás limpio. Eso es interacción, que es un problema de lista y no un problema de DNS. El orden de diagnóstico completo está aquí.

Lo que una revisión semanal deja fuera a propósito

La revisión se mantiene corta por lo que no está en ella. Las plantillas que no cambiaron no necesitan volver a puntuarse. La cola larga de listas de bloqueo menores no amerita actuar, porque una inclusión ahí rara vez cambia la ubicación real y varios de esos operadores cobran por eliminarlos. La tasa de apertura ya no es una señal de entregabilidad confiable, por razones cubiertas en el artículo sobre la regla de píxeles de la CNIL. Las pruebas de ubicación con semillas van después de un cambio, o una vez al mes, no todas las semanas.

Agregar algo a la revisión significa quitar otra cosa de ella.

Dónde se rompe el modelo semanal

Una revisión cada siete días significa que el peor retraso de detección es de seis días. Una clave DKIM que deja de publicarse el martes envía correo sin firma hasta el lunes siguiente, y en once dominios esa exposición se multiplica. Ejecutar las verificaciones con más cuidado no cambia nada, porque el límite es el intervalo, no el método.

Tres respuestas, en orden creciente de cuánto aguantan:

• Acorten el intervalo. Dos veces por semana reduce la exposición a la mitad y duplica el trabajo. Escala mal a partir de tres o cuatro dominios.
• Reduzcan el alcance. Revisen registros de autenticación y listas de bloqueo cada semana, reputación cada mes. Más barato, y acepta un punto ciego a propósito.
• Dejen de revisar contra el reloj. Hagan que las verificaciones corran continuamente y lean solo lo que cambió. Esto es lo que hace LitInboxes: vuelve a ejecutar las verificaciones de DNS en cada dominio cada seis horas, guarda el historial con fechas que convierte “algo se rompió en julio” en “el registro SPF perdió el include de SendGrid el 16 de julio”, vigila las listas de bloqueo y las señales de reputación, y envía el cambio por correo, Slack, Discord o un webhook. El lunes se convierte en leer un changelog en lugar de ejecutar ochenta y ocho consultas.

Las herramientas gratuitas enlazadas arriba responden la pregunta de hoy para un dominio. El monitoreo continuo responde la pregunta del próximo martes para todos ellos, que es un trabajo distinto. Hay un recorrido aquí si quieren verlo sin registrarse en nada.

La revisión, en orden

Por dominio:

1. Confirmen exactamente una respuesta v=spf1, que coincida con el registro esperado y esté dentro del límite de diez consultas.
2. Confirmen una clave DKIM no vacía para cada selector en uso.
3. Confirmen que la política DMARC y la dirección rua son las que se configuraron.
4. Revisen ZEN, DBL, Barracuda y SpamCop, para la IP de envío y el dominio por separado.
5. Compahren las fuentes de envío DMARC de esta semana con las de la semana pasada, y persigan solo lo que es nuevo o grande.
6. Lean la reputación del dominio y la tasa de spam en Postmaster Tools contra la línea del 0.3%.
7. Anoten una línea con fecha por dominio, incluso cuando no pasó nada, especialmente cuando no pasó nada.
8. Si algo está en rojo, sigan el orden de prioridad de arriba y deténganse en la primera causa.

Los pasos 1 al 6 son la revisión. El paso 7 es lo que hace posible la revisión de la próxima semana, y es el paso que primero se salta. Cualquier cosa que ejecute estas verificaciones entre lunes y lunes escribe el paso 7 por ustedes, que es la mayor parte del argumento contra hacer esto a mano en cuanto el número de dominios llega a dos dígitos.

Los mismos ocho pasos están disponibles como una hoja imprimible de una página, con una casilla por punto y el orden de prioridad incluido, con el tamaño justo para pegarla junto al monitor e ir marcando cliente por cliente. El formulario de abajo la envía.