Cómo pasar a un p=reject sin interrumpir el envío de correos electrónicos

¡Vaya p=reject en realidad

Cuando DMARC de un dominio está configurada en p=reject, se indica a los servidores receptores que bloqueen la entrega de cualquier mensaje que no cumpla con DMARC . Un mensaje no cumple con la alineación cuando el dominio autenticado por SPF DKIM coincide con el dominio del encabezado «De» —la dirección que ven los destinatarios al abrir un correo electrónico—.

Cómo funcionan las tres políticas:

1. p=none – solo supervisión. Se generan informes, pero no se toma ninguna medida con respecto a los mensajes que no superan la comprobación de autenticidad. Los correos electrónicos falsificados siguen entregándose a los destinatarios.
2. p=quarantine: los mensajes que no superan la comprobación de alineación se desvían a la carpeta de spam o correo no deseado, en lugar de bloquearse directamente.
3. p=reject – Los mensajes que no superan la comprobación de alineación no se entregan. Esta es la solo que impide que los correos electrónicos falsificados lleguen a los destinatarios.

Un error muy común es pensar que un p=reject interfiere con el correo electrónico legítimo. No es así, siempre que la autenticación esté configurada correctamente. Una p=rejectsolo los mensajes que no cumplen con los requisitos de alineación. Para la mayoría de las empresas, un entorno de remitentes bien configurado significa que una p=reject tendrá un impacto mínimo en la entrega.

Cuando las organizaciones están listas para pasar a un p=reject política

Actuar con demasiada precipitación —antes de que se hayan identificado y autenticado todas las fuentes de envío legítimas— provoca que se bloqueen los correos electrónicos legítimos. Para aplicar la política, deben cumplirse tres condiciones:

1. Todos los servicios de envío legítimos se identifican y se incluyen en el SPF .
2. DKIM configurado DKIM y se ha publicado una clave pública válida en el DNS para cada servicio de envío.
3. Los informes DMARC muestran una tasa de aceptación elevada y constante para el tráfico legítimo, sin fallos inexplicables.

La preparación viene determinada por reporte , no por el tiempo que lleve en vigor la política. Una empresa con un entorno de correo electrónico sencillo puede estar preparada para avanzar rápidamente. Una gran empresa con docenas de herramientas de envío repartidas por unidades de negocio, regiones y departamentos puede necesitar más tiempo. Es necesario identificar y autenticar todos los servicios de envío antes de que pueda comenzar la aplicación de la política.

Es aquí donde muchos equipos de TI de las empresas se encuentran con dificultades. Los departamentos suelen incorporar plataformas de marketing, sistemas de RR. HH. y herramientas financieras sin que el departamento de TI tenga conocimiento de ello ni se actualicen DKIM SPF DKIM .

Estos remitentes no autorizados aparecen en DMARC como fallos de autenticación. Son una de las razones más comunes por las que las organizaciones se quedan estancadas en p=none.

Cómo pasar a un p=reject de forma segura

Paso 1: Leer los informes agregados y actuar en consecuencia

Los informes DMARC contienen un desglose de todo el tráfico de correo electrónico que afirma proceder del dominio, incluyendo qué fuentes han superado o no DKIM SPF DKIM . Estos informes constituyen la herramienta principal para identificar deficiencias antes de aplicar la política.

Busca:

• Fuentes con un elevado volumen de envíos que no superan la autenticación
• Servicios de envío desconocidos o no autorizados que el departamento de TI no reconoce
• Servicios legítimos con DKIM SPF DKIM mal configurados

Los informes agregados se entregan en formato XML. Interpretar estos datos manualmente —en múltiples dominios y a escala empresarial— no resulta práctico. Los equipos de seguridad y de TI ya están desbordados. Añadir el análisis manual de archivos XML a la carga de trabajo de los equipos que gestionan entornos de correo electrónico distribuidos y múltiples dominios no es un enfoque sostenible.

Paso 2: Identificar y autenticar a todos los remitentes legítimos

Antes de aplicar la política, todos los servicios de envío legítimos deben superar la comprobación de DKIM SPF DKIM . Los dos motivos de fallo más habituales son:

SPF

Las direcciones IP o los servidores del servicio de envío no figuran en el SPF del dominio. Para solucionar esto, añade los remitentes legítimos del servicio al SPF .

Ejemplo de registro SPF :

DKIM

El servicio de envío no dispone de un par DKIM , o bien la clave pública no está publicada en el DNS. Para solucionar esto, genera un par DKIM para el servicio y publica la clave pública como un registro TXT en el DNS.

Ejemplo de registro DKIM :

Cada servicio de envío requiere su propio par DKIM . Un mismo dominio que envíe mensajes a través de cinco plataformas necesita cinco pares de claves, cada uno de los cuales debe generarse, configurarse en el servicio de envío y publicarse en el DNS.

A nivel empresarial, coordinar estos cambios en el DNS entre los distintos departamentos, sin interrumpir las operaciones ni provocar largos procesos de aprobación internos, es uno de los retos operativos más habituales en DMARC .

Paso 3: Avanzar a un p=quarantine Política

Una vez que reporte confirmen que todos los remitentes legítimos superan la autenticación de forma sistemática, actualice la política a p=quarantine. En esta fase, los mensajes que no superan la autenticación se envían a las carpetas de spam o correo no deseado de los destinatarios, en lugar de bloquearse por completo. Esto proporciona un margen de tiempo adicional para identificar cualquier remitente legítimo que se haya pasado por alto durante la fase de revisión anterior.

Siga supervisando los informes agregados durante esta fase. Si empiezan a aparecer correos electrónicos legítimos en las carpetas de spam o correo no deseado, identifique las fuentes de envío y resuelva los errores de autenticación antes de continuar.

Paso 4: Avanzar a un p=reject .

Cuando reporte confirmen una tasa de aprobación consistentemente alta en todas las fuentes de envío legítimas, pasa a un p=reject . Los servidores receptores bloquearán la entrega de cualquier mensaje que no cumpla con DMARC .

Mantener un p=reject tras su aplicación

Alcanzar p=reject no es el final del proceso. Los entornos de correo electrónico cambian continuamente. Los departamentos añaden nuevas herramientas de envío, DKIM caducan, SPF acumulan entradas y las empresas lanzan nuevos dominios mediante adquisiciones o expansión regional, a menudo sin configurar la autenticación.

Sin una supervisión continua, la aplicación de las normas lograda mediante una progresión estructurada de políticas se ve mermada. Cualquier nueva herramienta de envío debe añadirse a SPF ; de lo contrario, la autenticación fallará. DKIM caducada romperá la alineación.

Mantener un p=reject requiere:

• Supervisión continua de los informes DMARC en todos los dominios
• Avisos cuando aparecen remitentes nuevos o no autorizados en reporte
• SPF se actualiza a medida que se añaden o eliminan servicios de envío
• Validación continua DKIM y rotación de claves
• Gestión de políticas para cada nuevo dominio añadido

Las empresas que configuran un p=reject y dejan de realizar el seguimiento no están protegidas contra la deriva operativa que, con el tiempo, interrumpe la autenticación. Configurar DMARC una tarea puntual. Mantenerlo en una cartera de dominios en crecimiento y constante cambio es una operación continua.

Cómo gestiona Sendmarc la progresión hacia un p=reject Política

Avanzar un dominio desde p=none a p=reject es factible. Hacerlo en múltiples dominios —mientras se coordina con equipos de TI distribuidos, se gestionan SPF en múltiples remitentes, se rotan DKIM , se supervisan informes agregados y se identifican herramientas de envío no autorizadas— supone una carga operativa que la mayoría de los equipos no pueden soportar sin herramientas específicas.

Sendmarc ofrece los reporte, la visibilidad y la gestión de políticas necesarios para alcanzar y mantener un p=reject en todos los dominios sin aumentar la carga de trabajo de los equipos de TI y seguridad, que ya están al límite.

Sendmarc ofrece:

• DMARC : el estadoDMARC y reporte agregados son visibles en todos los dominios, lo que sustituye el procesamiento manual de XML por reporte que permiten tomar medidas
• SPF : SPF se gestionan y optimizan a medida que cambia la infraestructura de envío, lo que evita los errores de autenticación provocados por el exceso de registros
• DKIM : Se realiza un seguimiento de DKIM en todas las plataformas de envío, y la gestión de los selectores y la rotación de claves se lleva a cabo de forma integral
• Identificación de remitentes no autorizados: a partir de reporte agregados reporte se detectan los servicios de envío desconocidos o no autorizados, lo que proporciona a los equipos de TI una visión completa de todas las fuentes que envían correos electrónicos en nombre de la organización
• Supervisión continua: Las alertas y reporte una vez que se ha alcanzado el cumplimiento, lo que proporciona la supervisión constante necesaria para mantener un p=reject a medida que evolucionan los entornos de correo electrónico

Esta es la diferencia entre una configuración puntual y una aplicación continua. Las empresas que necesitan una optimización continua más allá de la configuración inicial —y no un enfoque del tipo «configúralo y olvídalo»— necesitan una plataforma que supervise, avise y gestione las políticas en toda la cartera de dominios.

Descubre cómo Sendmarc gestiona la evolución DMARC a escala empresarial.