Domain-based Message Authentication, Reporting & Conformance (DMARC) es una especificación diseñada para ayudar a reducir el abuso en el envío de mensajes de correo, tal como el Spam entrante y mensajes de phishing que simulan tener otros orígenes falsificando el encabezado From: del mensaje. DMARC hace posible a los propietarios de dominios utilizar el DNS (Domain Name System) para informar a los servidores receptores sobre su política DMARC, que consiste en la manera en que requieren que esos servidores manejen los mensajes que pretender ser enviados de sus dominios pero que no pueden ser autentificados como provenientes de ellos. Esta política, que se obtiene del servidor receptor vía consultas DNS al procesar el mensaje entrante, puede establecer que el servidor deberá poner en cuarentena o rechazar mensajes que no se cumplan con la política, o no ejecutar acción alguna (i.e. dejar que el mensaje proceda normalmente). Adicionalmente a la política, el registro DMARC en el DNS también puede contener peticiones al servidor para enviar reportes DMARC a algunos, describiendo el número de mensajes entrantes que pretendieron ser de su dominio y si pasaron o fallaron la autentificación, incluyendo detalles sobre los fallos. Las funcionalidades de reporteo de DMARC pueden ser útiles para determinar la efectividad de sus procedimientos de autentificación de correo y qué tan frecuentemente se utilizar su nombre de dominio para enviar mensajes falsificados.
Bajo la sección Autentificación de Remitente en el diálogo Ajustes de Seguridad, existen tres pantallas para configurar las funcionalidades DMARC de MDaemon, la verificación y reporteo: Verificación DMARC, Reporteo DMARC y Ajustes DMARC.
Verificación DMARC
Como parte del proceso de verificación DMARC, MDaemon ejecuta una consulta DNS DMARC en el dominio encontrado en el encabezado From: de cada mensaje entrante. Esto se realiza para determinar si el dominio utiliza DMARC o no y si es así, para recuperar su registro DMARC DNS, que contiene su política y otra información relativa a DMARC. Adicionalmente, DMARC utiliza SPF y DKIM para validar cada mensaje y requiere que pase por lo menos esas pruebas a fin de pasar la verificación DMARC. Si el mensaje pasa entonces procederá normalmente por el resto de los procesos de entrega y filtrado de MDaemon. Sin embargo, si falla, el destino del mensaje estará determinado por una combinación de la política DMARC del dominio y de la manera en que tenga configurado MDaemon para manejar esos mensajes.
Si el mensaje falla la verificación DMARC y el dominio DMARC tiene una política de "p=none" entonces no se ejecutará ninguna acción punitiva y continuará normalmente el procesamiento del mensaje. Alternativamente, cuando el dominio DMARC tiene una política restrictiva "p=quarantine" o "p=reject," MDaemon opcionalmente puede filtrar automáticamente el mensaje a la carpeta de Correo Basura del usuario destinatario. También puede decidir hacer que MDaemon rechace completamente el mensaje fallido cuando el dominio utiliza la política "p=reject". Adicionalmente, para mensajes fallidos con políticas restrictivas, MDaemon insertará un encabezado "X-MDDMARC-Fail-policy: quarantine" o "X-MDDMARC-Fail-policy: reject", dependiendo de la política. Esto le permite utilizar el Filtro de Contenido para ejecutar alguna acción basada en la presencia de esos encabezados, tal como enviar el mensaje a una carpeta específica para mayor escrutinio.
La Verificación DMARC se encuentra habilitada por omisión y es recomendada para la mayoría de las configuraciones de MDaemon.
Reporteo DMARC
Cuando MDaemon consulta un DNS buscando un registro DMARC, el registro puede contener etiquetas indicando que el propietario del dominio desea recibir reportes agregados o de falla respecto a los mensajes que pretenden provenir de su dominio. Las opciones en la pantalla Reporteo DMARC son para definir si usted está dispuesto o no a enviar los tipos de reporte requeridos y para especificar los metadatos que deben contener esos reportes. Los reportes agregados se envían diariamente a medianoche UTC y los reportes de falla se envían por mensaje, ya que cada incidente detona el reporte. Los reportes se envían siempre como archivos adjuntos de tipo XML y hay varias herramientas disponibles en línea para facilitar a los destinatarios la visualización de estos.
Por omisión, MDaemon no envía reportes agregados o de falla. Si está dispuesto a enviar cualquiera de los dos tipos de reporte, habilite la opción correspondiente en la pantalla Reporteo DMARC.
Ajustes DMARC
La pantalla Ajustes DMARC contiene varias opciones para incluir cierta información en los reportes DKIM, registros de bitácora DNS DMARC y para actualizar el archivo de Sufijo Público utilizado por MDaemon por DMARC.
Verificación DMARC y Listas de Distribución
Dado que el propósito de DMARC es asegurar que el dominio identificado en el encabezado From: de un mensaje, no haya sido falsificado, el servidor remitente debe tener permitido enviar mensajes en nombre de ese dominio. Esto puede convertirse en un problema único para listas de distribución, porque es común que las listas distribuyan mensajes en nombre de miembros de la lista provenientes de dominios externos dejando sin modificar el encabezado From:. Esto significa que cuando un servidor receptor intente utilizar la verificación DMARC en uno de esos mensajes, el mensaje habrá sido enviado por un servidor que no está afiliado oficialmente con el dominio del encabezado From:. Si sucede que el dominio DMARC está utilizando una política restrictiva, esto podría hacer que el mensaje entre en cuarentena o sea rechazado por el servidor receptor. En algunos casos esto podría generar que el destinatario sea eliminado de la membresía de la lista. Para darle la vuelta a este problema, cuando MDaemon encuentra que están llegando mensajes para una lista provenientes de un dominio con una política DMARC restrictiva, MDaemon reemplazará el encabezado From: del mensaje con la dirección de la lista de correo. Alternativamente, usted puede configurar MDaemon para rechazar la aceptación de cualquier mensaje para una lista cuando provenga de un dominio con una política restrictiva. Esta última opción podría hacer imposible para un usuario de un dominio con una política restrictiva que envíe mensajes a la lista. La opción para reemplazar el encabezado From: se localiza en la pantalla Encabezados del editor de listas de distribución. La opción para rechazar mensajes se localiza en la pantalla Ajustes.
Utilizando DMARC para sus dominios MDaemon
Si desea utilizar DMARC para uno de sus propios dominios, lo que significa que desea que lo servidores receptores de correo que soportan DMARC puedan utilizar DMARC para verificar los mensajes que pretender provenir de usted, entonces primero debe asegurarse de que ha creado registros SPF y DKIM en su DNS, correctamente formateados para ese dominio; debe tener por lo menos una de esas opciones funcionando correctamente para utilizar DMARC. Si utiliza DKIM, también debe configurar las opciones Firmas DKIM en MDaemon para firmar los mensajes del dominio. Adicionalmente, debe crear un registro DNS DMARC para el dominio. Al consultar el DNS buscando este registro TXT especialmente formateado, el servidor receptor puede determinar su política DMARC y varios parámetros opcionales tales como: el modo de autentificación que usted utiliza, si desea o no recibir reportes agregados, la dirección de correo la que se deben enviar los reportes y otros.
Una vez que ha configurado correctamente DMARC y ha empezado a recibir reportes XML DMARC, existe una variedad de herramientas en línea disponibles para leer esos reportes y diagnosticar cualquier problema potencial. Para su conveniencia, también se tiene una herramienta de Reporteo DMARC colocada para usted en la carpeta \MDaemon\App\. Vea el archivo DMARCReporterReadMe.txt para instrucciones sobre su uso.
Definir un registro de recursos DMARC TXT
A continuación, se presenta una descripción general de los componentes más básicos utilizados comúnmente para construir un registro DMARC. Para información más detallada o para información sobre configuraciones más avanzadas, vea: www.dmarc.org.
Campo Propietario (Owner)
El campo Propietario (Owner) (también llamado "Name" o "left-hand") siempre debe ser _dmarc, o puede tomar la forma _dmarc.domain.name si desea especificar el dominio o subdominio al que aplica el registro.
Ejemplo:
Registro DMARC para el dominio example.com
_dmarc IN TXT "v=DMARC1;p=none"
Este registro aplicaría a mensajes provenientes de user@example.com o cualquier subdominio de example.com, como user@support.example.com, user@mail.support.example.com, y demás.
_dmarc.support.example.com IN TXT "v=DMARC1;p=none"
Este registro solo aplicaría a mensajes provenientes de user@support.example.com, no a mensajes provenientes, por ejemplo, de user@example.com.
_dmarc.support IN TXT "v=DMARC1;p=none"
Este registro aplicaría a mensajes provenientes de: user@support.example.com, user@a.support.example.com, user@a.b.support.example.com y demás.
Etiquetas y Valores del Registro DMARC
Etiquetas Requeridas
Etiqueta (Tag) |
Valor |
Notas |
v= |
DMARC1 |
Esta es la etiqueta Version, que debe ser la primera etiqueta en la porción especifica de texto del registro DMARC. Aunque otros valores de etiquetas DMARC no son sensibles a mayúsculas, el valor de la etiqueta v= debe contener en mayúsculas el valor: DMARC1. Ejemplo: _dmarc IN TXT "v=DMARC1;p=none" |
p= |
none quarantine reject |
Esta es la etiqueta Política, que debe ser la segunda etiqueta en el registro DMARC, después de la etiqueta v=. p=none significa que el servidor receptor no deberá ejecutar ninguna acción basado en los resultados de la consulta DMARC. Los mensajes que fallen esta verificación DMARC no deberán entrar en cuarentena o ser rechazados basados en esa falla. Pueden ser puestos en cuarentena o rechazados por otras razones, como por fallar las pruebas del filtro de Spam u otras verificaciones de seguridad no relacionadas con DMARC. Utilizar p=none en ocasiones se denomina "monitorear" o "modo monitoreo" porque puede utilizarlo con la etiqueta rua= para recibir reportes agregados de dominios receptores sobre sus mensajes, pero esos mensajes no serán penalizados por los dominios por no pasar la verificación DMARC. Esta es la política que debe utilizar hasta que haya probado a fondo su implementación DMARC y esté seguro de que está listo para avanzar hacia la política más restrictiva p=quarantine. p=quarantine es la política a utilizar cuando desea que otros servidores de correo traten un mensaje como sospechoso cuando su encabezado From: dice que proviene de usted, pero el mensaje falla la verificación DMARC. Dependiendo de la política local del servidor, esto podría significar que se sujete el mensaje a escrutinio adicional, colocándole en la carpeta de correo basura del destinatario, enrutándolo a un servidor diferente o ejecutando alguna otra acción. p=reject indica que desea que el servidor receptor rechace cualquier mensaje que falle la verificación DMARC. Algunos servidores, sin embargo, pueden aceptar estos mensajes pero ponerlos en cuarentena o sujetarlos a escrutinio adicional. Esta es la política más restrictiva y en general no debe ser utilizada a menos que esté completamente seguro de sus políticas de correo y los tipos de mensajes o servicios que desea permitir que utilicen sus cuentas. Por ejemplo, si desea permitir a sus usuarios unirse a listas de distribución de terceros, utilizar servicios de reenvío, utilizar funcionalidades "share this" en sitios web o similares, entonces al utilizar p=reject con certeza hará que se rechacen algunos mensajes legítimos. Esto podría causar también que algunos usuarios sean bloqueados o eliminados automáticamente de ciertas listas de correo. Ejemplo: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:dmarc-report@example.net" |
Etiquetas Opcionales
Todas las etiquetas listadas abajo son opcionales. Cuando no se utiliza ninguna de ellas en un registro, se asumen los valores por omisión.
Etiqueta (Tag) |
Valor |
Notas |
sp= |
none quarantine reject — Default: Si no se utiliza sp= , la etiqueta p= aplica al dominio y subdominios. |
Esta etiqueta es para especificar que se utilice una política para subdominios del domino al que aplica el registro DMARC. Por ejemplo, si esta etiqueta se utiliza en un registro que tiene alcance sobre example.com, entonces la política definida en la etiqueta p= aplicará a los mensajes provenientes de example.com y la política definida en la etiqueta sp= aplicará a los mensajes provenientes de subdominios de example.com, tales como mail.example.com. Si se omite del registro esta etiqueta, aplicará la etiqueta p= al dominio y subdominios. Ejemplo: _dmarc IN TXT "v=DMARC1;p=quarantine;sp=reject" |
rua= |
Listas separadas por coma de direcciones de correo a las que se deben enviar reportes DMARC agregados. Las direcciones deben registrarse como URIs con la forma: — Default: none Si no se utiliza esta etiqueta, no se enviarán reportes agregados. |
Esta etiqueta indica que desea recibir reportes agregados DMARC de los servidores que reciben mensajes que pretenden provenir en su encabezado From: de un remitente de su dominio. Especifique una o más direcciones de correo tipo URIs de la forma: mailto:user@example.com, separando múltiples URIs con comas. Ejemplo: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:user01@example.com,mailto:user02@example.com" Ordinariamente estas direcciones se encontrarán en el dominio cubierto por este registro. Si desea enviar reportes a una dirección en algún otro dominio, entonces la zona DNS de ese dominio debe contener también un registro DMARC especial indicando que aceptará reportes DMARC del dominio. Registro ejemplo en example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:non-local-user@example.net" Registro requerido en example.net: example.com._report._dmarc TXT "v=DMARC1" |
ruf= |
Listas separadas por comas de direcciones de correo a las que se deben enviar los reportes de falla DMARC. Las direcciones deben ser registradas como URIs en la forma: — Default: none Si no se utiliza esta etiqueta, no se enviarán reportes de falla. |
Esta etiqueta indica que desea recibir reportes de falla de servidores que reciben mensajes que pretenden provenir de un remitente de su dominio de acuerdo con lo indicado en el encabezado From:, cuando las condiciones especificadas en la etiqueta fo= se han cumplido. Por omisión, cuando no se especifica etiqueta fo=, los reportes de falla se envían cando el mensaje falla todas las verificaciones DMARC, (i.e. falla tanto SPF como DKIM). Especifique una o más direcciones de correo como URIs de la forma: mailto:user@example.com, separando múltiples URIs con comas. Ejemplo: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc-failures@example.com" Ordinariamente estas direcciones se encontrarán en un dominio cubierto por este registro. Si desea enviar reportes a una dirección en algún otro dominio, entonces el archivo de zona DNS de ese dominio también debe contener un registro DMARC especial indicando que aceptará reportes DMARC para el dominio. Registro ejemplo en example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:non-local-user@example.net" Registro requerido en example.net: example.com._report._dmarc TXT "v=DMARC1" |
Para información más detallada sobre la especificación DMARC, ver: www.dmarc.org.
Ver:
Listas de Distribución » Ajustes
Listas de Distribución » Encabezados
