Mejores prácticas de DMARC: de la configuración a la aplicación

Mejores prácticas de DMARC: la lista de verificación completa

Consolida los fundamentos antes de tocar la política

SPF y DKIM deben estar correctamente configurados en todas las fuentes de envío legítimas antes de aplicar la política de DMARC. Configurar correctamente ambos es la primera de varias mejores prácticas de DMARC que determinan si la aplicación tiene éxito o se estanca. Aplicar una política de cuarentena o rechazo antes de que ambos estén configurados puede provocar que se pongan en cuarentena o se bloqueen correos electrónicos legítimos.

Configuración de SPF

Una configuración correcta de SPF significa que la IP de envío figura en el registro SPF del dominio, y que el dominio de Ruta de retorno coincide con el dominio “De” que ve el destinatario. Una restricción fundamental: SPF tiene un límite de 10 consultas DNS. Superar este límite provoca fallos de SPF, independientemente de si la IP de envío está autorizada. El aplanamiento de SPF resuelve esto convirtiendo includes en referencias IP directas.

Configuración de DKIM

Una configuración correcta de DKIM significa que hay una firma criptográfica válida y que el dominio de firma coincide con el dominio “De”. Si falta la firma o los dominios no coinciden, DKIM falla, y DMARC pierde una de sus dos señales de autenticación.

Alineación de DMARC

DMARC solo reconoce los resultados de SPF y DKIM cuando sus dominios autenticados coinciden con el dominio “De”. Configurar la alineación relajada (la opción predeterminada) es una práctica DMARC recomendada: permite que un subdominio coincida con el dominio “De”.

DMARC se supera cuando SPF o DKIM coincide con el dominio “De”. Una implementación que depende únicamente de SPF o DKIM es más vulnerable a la desviación de la configuración. Configura ambos.

Configura tu política en p=none y configura los informes

p=none es el punto de partida correcto y una práctica DMARC fundamental. Genera reportes sin afectar el envío de correo electrónico, lo que da a los administradores visibilidad de todas las fuentes que envían correo en nombre del dominio.

Pasar a p=quarantine o p=reject sin completar este paso es la causa más común de interrupciones del correo electrónico relacionadas con DMARC.

Configura ambos tipos de informes desde el principio:

1. Reportes agregados – Los reportes agregados resumen los resultados de autenticación de todo el tráfico, normalmente cada 24 horas. Es la herramienta principal para mapear la infraestructura y hacer seguimiento de la preparación para la aplicación de la política.
2. Reportes forenses – Los reportes forenses se generan cuando un correo electrónico no supera DMARC. Úsalos para investigar fallos concretos e identificar remitentes no autorizados. Ten en cuenta que la compatibilidad es irregular: Gmail y varios otros proveedores importantes no envían reportes RUF.

Ejemplo de registro:

Trata la aplicación de la política como un proceso

Pasar de p=none a la aplicación total es un proceso por fases. La progresión gradual de la política es una de las mejores prácticas de DMARC más importantes: avanzar demasiado rápido es la causa más común de interrupciones del correo electrónico relacionadas con DMARC. Cada fase requiere la confirmación, a partir de los datos de los reportes, de que los correos electrónicos legítimos se están validando.

Las tres fases son:

1. Supervisión (p=none) – Los correos electrónicos se entregan con normalidad y se generan informes. Identifica todas las fuentes de envío y confirma que SPF y DKIM se superan correctamente. No avances hasta que los datos de los informes estén limpios.
2. Cuarentena (p=quarantine) – Los mensajes que no superan la validación se entregan a las carpetas de spam o correo no deseado. Usa esta fase para detectar fuentes que se pasaron por alto durante la supervisión. Revisa detenidamente los informes forenses antes de continuar.
3. Rechazar (p=reject) – Los servidores receptores bloquean los mensajes que no superan la validación. Este es el objetivo y la protección más eficaz contra la suplantación de dominio.

p=reject impide la suplantación directa de dominio. No elimina todo el phishing: los atacantes pueden usar dominios similares o cuentas comprometidas. Trátalo como una capa crítica, no como una solución completa.

Establecer una periodicidad de revisión es una práctica DMARC recomendada que es fácil pasar por alto una vez que la aplicación de la política está implementada. Las nuevas herramientas, plataformas e integraciones de terceros introducen fuentes que quizá no estén cubiertas por la autenticación existente.

• Mensualmente: Revisa los datos de los reportes agregados en busca de nuevos fallos o fuentes de envío no reconocidas.
• Trimestralmente: Audita la autenticación en todos los dominios y subdominios.
• Anualmente: Reevalúa la fase de la política y la cobertura en toda la cartera de dominios.

Extiende la protección a todos los dominios

El dominio principal rara vez es la única superficie de ataque. Extender la protección más allá del dominio principal es una práctica DMARC recomendada que se pasa por alto con frecuencia: los subdominios y los dominios aparcados son igual de vulnerables a la suplantación de identidad. La reputación de la marca depende de proteger todos los dominios.

Subdominios que envían correo electrónico

Audita todos los subdominios que envían correo electrónico antes de aplicar la política. Usa la etiqueta sp= para establecer una política de subdominio explícita, independiente del dominio de la organización. Esto permite que el dominio principal pase a p=quarantine mientras se siguen confirmando las fuentes de los subdominios.

Subdominios que no envían correo y dominios aparcados

Estos no necesitan enviar correo electrónico, y no deberían poder hacerlo. Publica un registro DMARC configurado en p=reject y un registro SPF que bloquee todos los envíos. Es un paso sencillo que cierra una brecha que se explota con frecuencia.

Gestiona la escala a medida que aumenta la complejidad

Seguir las mejores prácticas de DMARC no termina en la aplicación. A medida que las carteras de dominios crecen y la infraestructura de envío se vuelve más distribuida, el volumen de datos de los reportes y el número de fuentes que hay que supervisar superan lo que cualquier equipo puede gestionar manualmente.

El punto débil suele ser la visibilidad. Se añaden fuentes sin que el departamento de TI lo sepa, se pasan por alto subdominios y la aplicación de la política se estanca porque nadie puede confirmar qué sigue fallando y por qué. Los equipos de seguridad y TI, ya sobrecargados, necesitan herramientas que reduzcan la investigación manual.

La Plataforma de gestión de DMARC de Sendmarc

DMARC es más que un registro DNS. Una implementación eficaz requiere visibilidad de todas las fuentes de envío, un camino planificado hacia la aplicación de la política y supervisión continua.

La Plataforma de gestión de DMARC de Sendmarc ofrece a los equipos de seguridad y de TI las herramientas para implementar las mejores prácticas de DMARC y pasar de la supervisión a la aplicación sin interrumpir las operaciones.

Sendmarc ofrece:

• Visibilidad unificada de las configuraciones de SPF, DKIM y DMARC en todos los dominios
• Análisis automatizado de los datos de reportes agregados y forenses
• Aplicación guiada con supervisión continua de todas las fuentes de envío
• Registros de auditoría para respaldar los informes de cumplimiento normativo y gobernanza
• Optimización continua más allá de la configuración inicial

Descubre cómo la Plataforma de gestión de DMARC de Sendmarc le brinda a tu equipo la visibilidad y el control necesarios para alcanzar p=reject – y mantenerlo.