Anulaciones de la política DMARC: Explicado
por
Tiempo de lectura: 7 min
Este artículo explica en detalle qué son las anulaciones de políticas DMARC, cómo funcionan, cuál es la diferencia entre una anulación de política DMARC y un fallo de política DMARC, y si anular registros DMARC es legítimo o no.
Puntos clave
- Las anulaciones de políticas DMARC se producen cuando un servidor de correo electrónico receptor no respeta las políticas DMARC especificadas por el remitente.
- El servidor de correo receptor puede tener sus propias políticas que pueden llevar a anular la configuración DMARC más estricta del remitente.
- La especificación DMARC anima a los receptores de correo a respetar las políticas DMARC del propietario del dominio en la medida de sus posibilidades.
- Las anulaciones están permitidas por RFC 7489, pero van en contra del espíritu de DMARC.
- Es importante que los remitentes realicen un seguimiento de las anulaciones de la política DMARC para evitar la suplantación de identidad en el correo electrónico y mantener la seguridad.
Anulaciones de la política DMARC: Explicado
La anulación de la política DMARC se produce cuando el servidor de correo electrónico receptor anula la política DMARC establecido por el remitente. Esto ocurre cuando el remitente ha especificado que quiere que su correo electrónico sea rechazado si no coincide con la política de un servidor de correo entrante, pero el servidor de correo electrónico receptor decide que no es apropiado para su propio conjunto de políticas.
Por ejemplo, si el remitente ha especificado una política estricta (como "p=rechazar todo el correo sin SPF o DKIM") y el servidor de correo electrónico receptor tiene una política relajada o poco estricta (como "aceptar todo el correo sin SPF o DKIM"). En esta situación, el servidor receptor puede anular la configuración de la política DMARC del remitente con su propia política local y entregar el mensaje en la bandeja de entrada del destinatario aunque no supere las comprobaciones DMARC.
¡Simplifique la política DMARC con PowerDMARC!
Comprensión del mecanismo de anulación de la política DMARC
DMARC se utiliza para comunicar la configuración de la política que los receptores de correo electrónico pueden utilizar para imponer a los correos electrónicos enviados desde su dominio.
Por ejemplo, puedes utilizar una política para DMARC para indicar al servidor de correo electrónico del destinatario lo que debe hacer (p=reject o p=none o p=quarantine) si falla una comprobación SPF o DKIM en los correos electrónicos enviados desde tu dominio.
Esto resume el poder de DMARC, ¿verdad?
¿Pero qué pasa si el servidor de correo receptor tiene su propio conjunto de políticas locales para tratar los correos electrónicos recibidos? ¿Acatará las políticas DMARC establecidas por el remitente o anulará las políticas del remitente con sus propias políticas locales?
Bueno...
La especificación DMARC requiere que los receptores de correo hagan un esfuerzo de buena fe para respetar las políticas DMARC publicadas por los propietarios de los dominios. Por lo tanto, si una prueba de la cabecera SPF, DKIM y From del remitente falla en un mensaje, esto debería desencadenar lo que se especifica en la política DMARC del remitente (p) como cuarentena, rechazo o NONE.
Supongamos que la situación es la siguiente:
➜ Su dominio (mipersonaldominio.org) tiene la política DMARC (p=ninguna).
➜ El servidor de correo electrónico gestionado por el destinatario (sudominio.org) rechaza todo el correo que no supera una comprobación SPF. Esto significa que si un correo electrónico enviado a (sudominio.org) falla la comprobación SPF, será rechazado. ¿Correcto?
Pero...
¿Qué ocurrirá si un correo electrónico de su dominio (mi-persona-dominio.org) con la política DMARC p=none se recibe en somedomain.org y falla la comprobación SPF?
En este caso, dependerá del servidor de correo receptor (cómo esté configurado) estar de acuerdo con la política DMARC establecida por el remitente O rechazar el correo electrónico anulando la política del remitente con reglas definidas en su política local de p=reject en caso de fallo de comprobación SPF.
Microsoft 365 es un ejemplo en tiempo real de esto, ya que envía todos los correos electrónicos p=rechazados a la carpeta de basura/spam del usuario en lugar de rechazarlos. Esto se debe a que O365 considera que está bien que el destinatario tome la decisión final sobre la disposición final.
Los cinco valores de las anulaciones de la política DMARC
reenviado - Es probable que el correo electrónico haya sido reenviado, basándose en algoritmos locales que identifican patrones de reenvío. Es de esperar que la autenticación falle.
política_local - la política local del receptor de correo exime al correo electrónico de ser sometido a la acción solicitada por su propietario de dominio. Por ejemplo, cuando la política solicitada está configurada como "rechazar" pero la comprobación ARC ha sido aprobada, un receptor de correo puede anular esa decisión y elegir no rechazar un correo electrónico.
| ¿Qué es el ARC?
ARC significa Cadena de recepción autenticada (ARC). Con ARC, los protocolos DKIM y SPF de un correo electrónico ya no se romperán por el reenvío o las listas de correo. Esto se debe a que ARC preserva los resultados de la autenticación del correo electrónico a través de routers, intermediarios y otros sistemas ("saltos") que pueden modificar un mensaje al pasar de un nodo de Internet a otro. Por lo tanto, si hubiera una cadena ARC, el servidor de correo receptor, que de otro modo descartaría los mensajes, podría optar por evaluar los resultados de las pruebas y hacer una excepción, permitiendo que los mensajes legítimos de estos flujos de correo indirectos lleguen a sus destinos. |
lista_de_correo - El correo electrónico fue enviado desde una lista de correo, por lo que el programa de filtrado decidió que probablemente no era legítimo.
sampled_out - El mensaje no se aplicó a la política porque su configuración "pct" estaba establecida en el registro DMARC.
reenviador_de_confianza - El fallo fue anticipado por pruebas que vinculaban el correo electrónico a una lista mantenida localmente de reenviadores de confianza.
otros - Algunas políticas contenían excepciones que no estaban contempladas en las otras entradas de la lista.
Anulación de la política DMARC: ¿Está permitido?
La sección 6 del RFC 7489 establece que los servidores de correo deben respetar y tratar los mensajes de acuerdo con la política del remitente. Aunque las anulaciones van en contra del espíritu de DMARC, los proveedores de correo se reservan el derecho de anular cualquier política del remitente. Así que sí, está permitido que el servidor receptor anule la política DMARC con su política local.
Esto significa que un servidor de correo electrónico podría entregar un mensaje falsificado aunque la política que debía seguir dijera lo contrario.
¿Debe enviar informes de anulación de políticas DMARC?
Las anulaciones de la política DMARC tienen lugar principalmente cuando:
- la heurística del receptor identifica un mensaje que no ha sido autentificado pero que podría haber sido enviado por una fuente autorizada.
- un proveedor de buzones tiene un mensaje que ha fallado el DMARC debido a reenvío de correo electrónico pero están lo suficientemente seguros de su legitimidad, pueden anular la política y entregarlo de todos modos.
Aunque las anulaciones de la política DMARC están permitidas, las secciones 6 y 7.2 del RFC 7489 establecen que cuando un receptor decide desviarse de la política publicada por el propietario del dominio, debe informar de este hecho así como de sus razones para hacerlo (utilizando el formato de informe de retroalimentación agregada) al propietario del dominio.
¿Cómo se permite la anulación de la política DMARC?
DMARC se compone de dos partes:
Política DMARC - La establece la organización remitente (en el DNS público de la organización remitente junto con SPF y DKIM) y define cómo debe tratar la parte receptora los mensajes que no cumplan sus políticas.
Verificación DMARC - La utiliza la organización receptora (en la puerta de enlace de seguridad del correo electrónico de la organización receptora) y comprueba cada mensaje recibido de una organización concreta en relación con las políticas que figuran en los registros DMARC de esa empresa. Sin embargo, la capacidad de anular la aplicación de la política DMARC de una organización remitente también es válida para las organizaciones receptoras.
Configuración de una política política DMARC es una "PETICIÓN, NO UNA OBLIGACIÓN": esencialmente significa que usted está "solicitando a los servidores de correo que indiquen cómo deben tratar los mensajes de correo electrónico enviados desde su dominio o que suplantan su identidad.
Sin embargo, los receptores de correo electrónico no están obligados a seguir un conjunto estricto de directrices al procesar los correos electrónicos entrantes. Pueden desarrollar sus políticas respecto a los mensajes que aceptan o rechazan y aplicar esas normas en consecuencia.
Por ejemplo, si el receptor del correo electrónico considera que el mensaje es válido. Así, si un correo electrónico no supera una comprobación DMARC, el receptor puede seguir aplicando su política local y entregarlo en las bandejas de entrada. Además, las políticas del receptor de correo electrónico pueden anular la política del propietario de un dominio.
¿Cómo puede una organización receptora anular mi política DMARC?
Otras organizaciones pueden anular la configuración de su política DMARC mediante sus propias herramientas de verificación DMARC y decidir su propio conjunto de políticas sobre cómo actuar ante los mensajes entrantes. Dependiendo del sistema, un usuario con privilegios de administrador puede anular todos los dominios o solo algunos.
Hay que tener en cuenta que las políticas DMARC son establecidas por el propietario del dominio, y cada política se aplica sólo a los dominios de esa organización. Por tanto, una política DMARC no puede afectar a las direcciones de otras organizaciones ni a sus mensajes.
Fallo de la política DMARC frente a anulación de la política DMARC: ¿Cuál es la diferencia?
Fallo DMARC es cuando un servidor de correo no implementa correctamente DMARC, lo que lleva a un fallo de verificación SPF y DKIM en el extremo del receptor. La incapacidad de verificar su legitimidad puede hacer que las bandejas de entrada le marquen como spam o rechacen sus mensajes. En este caso, el servidor de correo receptor respeta la política del remitente y no anula dicha política con su política local.
Las anulaciones de la política DMARC se producen cuando el servidor de correo receptor no respeta la política del remitente. En su lugar, anula la política DMARC del remitente con su política local. Esto significa que si el mensaje del remitente tiene una política estricta de p=reject sin verificación SPF o DKIM, el correo receptor anulará la política y seguirá entregando el mensaje en la bandeja de entrada de todos modos.
Lleve un control adecuado de las anulaciones de la política DMARC con PowerDMARC
Estar al día de las anulaciones de la política DMARC es una parte fundamental para prevenir la suplantación de identidad y el correo electrónico. Sin embargo, la mayoría de las organizaciones no tienen el tiempo ni los recursos para hacer un seguimiento de sus anulaciones de la política DMARC.
No puede detener las anulaciones de la política DMARC, pero puede hacer un seguimiento de ellas con nuestro servicio DMARC. Le proporcionaremos informes completos de qué organizaciones anulan su modo de política y qué tipo de mensajes de qué y qué correos electrónicos se permitieron en el extremo del receptor. Esto ayudará al remitente a realizar un seguimiento y tomar las medidas necesarias si se detecta suplantación de identidad o spoofing.
Regístrese en nuestro prueba gratuita de DMARC y pruébelo usted mismo.
Experto en seguridad de dominios y correo electrónico de PowerDMARC
Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.
Últimos mensajes de Yunes Tarada (ver todos)
- Reglas de envío de correo masivo para Google, Yahoo, Microsoft y Apple iCloud Mail - 14 de abril de 2025
- Email Salting Attacks: Cómo el texto oculto burla la seguridad - 26 de febrero de 2025
- Aplanamiento del FPS: ¿Qué es y por qué lo necesitas? - 26 de febrero de 2025
