Cómo monitorizar registros MX y el estado del servidor de correo

La infraestructura de correo electrónico es una de las partes más frágiles y menos monitorizadas de un servicio web típico. Los registros MX se modifican durante una migración de proveedor y nunca se revisan. Los registros SPF crecen hasta superar el límite de 10 consultas y fallan en silencio. Las claves DKIM rotan y la clave pública en DNS nunca se actualiza. El resultado es un fallo de entrega intermitente o total que ninguna monitorización a nivel de aplicación detectará. Esta guía cubre qué monitorizar en las capas DNS y SMTP para que los fallos salgan a la luz antes de que el cliente lo note.

Qué puede fallar con los registros MX

Un registro MX indica a los remitentes el servidor de correo que acepta mensajes para su dominio. Si los registros MX son incorrectos, no llega nada.

Los modos de fallo habituales: el registro MX se actualizó durante un cambio de proveedor pero el registro anterior no se eliminó, lo que provoca servidores en competencia. Una errata en el nombre de host MX (mailserver.example.com en lugar de mailservers.example.com) enruta silenciosamente todo a un servidor inexistente. El registro MX apunta a un nombre de host que no tiene registro A. Cada uno de estos casos produce un fallo de entrega parcial o total que una prueba desde la bandeja de entrada detectará, pero una comprobación solo de DNS no.

Los cuatro registros DNS que vale la pena monitorizar

Cuatro registros DNS cubren conjuntamente la parte de configuración de la salud del correo. Monitorice los cuatro para cada dominio desde el que envíe.

• MX: los propios servidores de correo. Alerte si el registro cambia inesperadamente o si el nombre de host resuelto no tiene registro A.
• SPF (TXT en la raíz): qué servidores están autorizados a enviar. Alerte ante cambios y ante registros que incluyan más de 10 consultas DNS anidadas (un asesino de la entregabilidad).
• DKIM (TXT en ._domainkey): la clave pública que verifica las firmas salientes. Alerte ante cambios; la falta de DKIM hace que la mayoría de los proveedores reduzcan la confianza.
• DMARC (TXT en _dmarc): la política para gestionar fallos de SPF y DKIM. Alerte ante cambios y ante políticas demasiado permisivas (p=none en producción).

Comprobaciones a nivel SMTP más allá del DNS

La monitorización a nivel DNS detecta errores de configuración. La monitorización a nivel SMTP detecta un servidor de correo correctamente configurado pero que no está en funcionamiento. Son necesarias ambas.

La comprobación: abrir una conexión TCP al servidor de correo en el puerto 25 o 587. Leer el banner SMTP (220 mail.example.com ESMTP). Cerrar la conexión correctamente. Ejecutar cada hora. La comprobación es ligera y detecta el fallo en el que el servidor se ha caído pero el DNS sigue apuntando a él. Añada verificación TLS en el puerto 587 si usa STARTTLS; la mayoría de los servidores de correo modernos lo hacen.

Monitorización de entrega de extremo a extremo

Las comprobaciones de DNS y SMTP indican que la infraestructura está operativa. Las comprobaciones de extremo a extremo indican que el correo realmente se está entregando. Dos patrones cubren los casos habituales.

• Prueba de ida y vuelta: envíe un correo de prueba desde su aplicación a un buzón que usted controle (una dirección de Gmail, una bandeja de Mailosaur, una dirección interna). Verifique que llega en pocos minutos.
• Herramienta externa: servicios como GlockApps, MXToolbox Inbox Insight y Mail-Tester puntúan la entregabilidad entre proveedores de bandeja de entrada. Vale la pena ejecutarlos mensualmente si el correo es una fuente de tráfico significativa.
• Bucle de retroalimentación del cliente: suscriba una dirección dedicada a su propia lista de marketing. Si la dirección de prueba deja de recibir su correo, los clientes también.

Detectar fallos por el límite de 10 consultas de SPF

Los registros SPF que incluyen más de 10 consultas DNS (contando todos los includes, redirects y mecanismos a/mx) son rechazados silenciosamente por los servidores de correo receptores. El modo de fallo clásico: cada nuevo SaaS al que autoriza a enviar en su nombre (Mailchimp, Customer.io, Sendgrid) se añade a sus includes de SPF. A partir del undécimo, la entregabilidad cae en silencio.

Monitorice el recuento de consultas SPF, no solo el contenido del registro. Herramientas como dmarcian y el comprobador de SPF de Postmark informan del recuento. Alerte a partir de 8 para dejarse margen. Aplane el registro (sustituya las directivas include: por sus IPs resueltas) si se acerca al límite. Mantenga la versión aplanada mediante automatización; el aplanamiento manual deriva con el tiempo.

Una pila de monitorización para la infraestructura de correo

La configuración mínima útil: un monitor MX en el dominio raíz, un monitor SPF (contenido del registro TXT + recuento de consultas), un monitor DKIM en el selector que realmente utiliza, un monitor DMARC en _dmarc y un monitor de banner SMTP en el servidor de correo principal en el puerto 587. Añada una prueba diaria de ida y vuelta de extremo a extremo a un buzón que revise efectivamente. Total: seis monitores. Cobertura total: la mayor parte de la superficie de fallos del correo. Coste mensual total en el nivel Pro: muy por debajo de lo que gasta en café.