## Por favor habilite JavaScript para visualizar este sitio.

# MDaemon Servidor de Correo 26.0

- Reducir Zoom
- Texto más grande | Texto más pequeño
- Ocultar Encabezado de Página
- Mostrar Testo Expandido
- Versión Imprimible
- Guardar URL permanente

DMARC | Desplazar Previo Inicio Siguiente Más

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 garantizar que el dominio que se encuentra en el encabezado FROM: de un mensaje no ha sido falsificado, el servidor remitente debe tener permiso para enviar mensajes en nombre de ese dominio. Esto puede plantear un problema único para las listas de correo, porque es habitual que las listas distribuyan mensajes en nombre de los Miembros de la lista desde dominios ajenos y, sin embargo, dejen el encabezado FROM: sin modificar. Esto significa que cuando un servidor receptor intenta utilizar la verificación DMARC en uno de estos mensajes, el mensaje habrá sido enviado por un servidor que no está oficialmente afiliado al dominio del encabezado From:. Si el dominio DMARC utiliza una política DMARC restrictiva, el mensaje puede ser puesto en cuarentena o incluso rechazado por el servidor receptor. En algunos casos, esto también podría provocar que el destinatario fuera eliminado de la lista de miembros. Para evitar este problema, cuando MDaemon detecta que un mensaje para una lista procede 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. Como alternativa, puede configurar MDaemon para que rechace cualquier mensaje para una lista cuando proceda de un dominio con una política restrictiva. Esta última opción haría imposible que un usuario de un dominio con una política restrictiva enviara un mensaje a la lista. La opción para reemplazar el encabezado FROM: se encuentra en la pantalla de Encabezados del editor de listas de correo, y la opción para rechazar mensajes se encuentra en su pantalla de Ajustes. Nota: El Servidor SMTP buscará la política DMARC del remitente cuando sea necesario para estas opciones de listas de correo relacionadas con DMARC, incluso si la conexión está exenta del procesamiento DMARC.

### 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: mailto:user@example.com — 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: mailto:user@example.com — 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:

Verificación DMARC

Reporteo DMARC

Ajustes DMARC

Listas de Distribución » Ajustes

Listas de Distribución » Encabezados

MDaemon v26.0.0 - abril 2026. Derechos Registrados © 1996-2026. Todos los derechos reservados. MDaemon Technologies, Ltd.