Usar DMARC para validar el correo electrónico
Sugerencia
¿Sabía que puede probar las características de Microsoft 365 Defender para Office 365 Plan 2 de forma gratuita? Use la prueba de Defender para Office 365 de 90 días en el centro de pruebas del portal de Microsoft Defender. Obtenga información sobre quién puede registrarse y los términos de prueba aquí.
La autenticación, los informes y la conformidad de mensajes basados en dominio (DMARC) funcionan con el marco de directivas de remitente (SPF) y DomainKeys Identified Mail (DKIM) para autenticar a los remitentes de correo.
DMARC garantiza que los sistemas de correo electrónico de destino confían en los mensajes enviados desde su dominio. El uso de DMARC con SPF y DKIM ofrece a las organizaciones más protección contra la suplantación de identidad y el correo electrónico de suplantación de identidad. DMARC permite a los sistemas que reciben los correos decidir qué hacer con los mensajes de su dominio que no superan las comprobaciones SPF o DKIM.
Sugerencia
Visite el catálogo de la Asociación de seguridad inteligente de Microsoft (MISA) para ver los proveedores que ofrecen informes DMARC para Microsoft 365.
Sugerencia
¿Has visto nuestras guías paso a paso? Configuración 1-2-3s y sin lujos, para administradores con prisa. Visite los pasos para habilitar DMARC Reporting for Microsoft Online Email Routing Addresses (MOERA) and parked Domains (DmARC Reporting for Microsoft Online Email Routing Addresses (MOERA) and parked Domains (DmARC Reporting for Microsoft Online Email Routing Addresses (MOERA) and parked Domains (DmARC Reporting for Microsoft Online Email Routing Addresses (MO
¿Cómo se coordinan SPF y DMARC para proteger el correo electrónico en Microsoft 365?
Un mensaje de correo electrónico puede contener varias direcciones de remitentes que se usan para distintos propósitos. Por ejemplo, observe las siguientes direcciones:
Dirección "Correo de": identifica al remitente e indica dónde enviar notificaciones de devolución si se produce algún problema con la entrega del mensaje (por ejemplo, avisos de no entrega). Dirección Correo de aparece en la parte del sobre de un mensaje de correo electrónico y no se muestra en la aplicación de correo electrónico y, a veces, se denomina dirección 5321.MailFrom o dirección de ruta de acceso inversa.
Dirección «De»: es la dirección que se muestra como dirección De en el cliente de correo de la aplicación. Dirección De identifica al autor del correo electrónico. Es decir, el buzón de la persona o el sistema responsables de escribir el mensaje. Dirección De también recibe el nombre de dirección 5322.From.
SPF usa un registro TXT de DNS para enumerar las direcciones IP de envío autorizadas para un dominio determinado. Normalmente, solo se realizan comprobaciones de SPF en la dirección 5321.MailFrom. La dirección 5322.From no se autentica cuando se usa SPF por sí mismo, lo que permite un escenario en el que un usuario obtiene un mensaje que ha superado las comprobaciones de SPF pero tiene una dirección de remitente 5322.From suplantada. Por ejemplo, veamos esta transcripción de SMTP:
S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .
En esta transcripción, las direcciones del remitente son las siguientes:
Correo desde la dirección (5321.MailFrom): phish@phishing.contoso.com
Desde la dirección (5322.From): security@woodgrovebank.com
Si configuró SPF, el servidor receptor realiza una comprobación con la dirección phish@phishing.contoso.comMail from . Si el mensaje procede de un origen válido para el dominio phishing.contoso.com, entonces pasa la comprobación de SPF. Dado que el cliente de correo electrónico solo muestra la dirección Desde, el usuario ve que este mensaje procede de security@woodgrovebank.com. Usando solo SPF, la validez de woodgrovebank.com nunca se autentica.
Cuando se usa DMARC, el servidor receptor también realiza una comprobación en la dirección From. En el ejemplo anterior, si no hay un registro TXT de DMARC para woodgrovebank.com, la comprobación de la dirección De produce un error.
¿Qué es un registro TXT de DMARC?
Al igual que los registros DNS para SPF, el registro para DMARC es un registro de texto (TXT) de DNS que ayuda a evitar la suplantación de identidad. Los registros TXT de DMARC se publican en DNS. Los registros TXT de DMARC validan el origen de los mensajes de correo electrónico contrastando la dirección IP del autor de un correo electrónico con el supuesto propietario del dominio de envío. El registro TXT de DMARC identifica los servidores de correo electrónico saliente autorizados. Así, los sistemas de correo electrónico de destino comprueban que los mensajes que reciben proceden de servidores de correo electrónico saliente autorizados.
El registro TXT de DMARC de Microsoft es algo así:
_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"
Para ver más proveedores que ofrecen informes DMARC para Microsoft 365, visite el catálogo de MISA.
Configurar DMARC para el correo entrante
No hay que hacer nada para configurar DMARC para el correo que se recibe en Microsoft 365. Ya está todo hecho. Si quiere saber lo que ocurre con el correo que no pasa las comprobaciones de DMARC, vea Cómo controla Microsoft 365 el correo electrónico entrante que no supera las comprobaciones de DMARC.
Configurar DMARC para el correo saliente de Microsoft 365
Si usa Microsoft 365 pero no usa un dominio personalizado (usa onmicrosoft.com), SPF ya está configurado para usted y Microsoft 365 genera automáticamente una firma DKIM para su correo saliente (para obtener más información acerca de esta firma, consulte Comportamiento predeterminado para DKIM y Microsoft 365). Para configurar DMARC para su organización, debe formar el registro TXT de DMARC para el dominio onmicrosoft.com y publicarlo en DNS a través de Office 365 Admin Dominios> de configuración > del Centro > haga clic en onmicrosoft.com dominio > Agregar registro.
Si tiene un dominio personalizado o usa servidores de Exchange locales junto con Microsoft 365, debe configurar manualmente DMARC para el correo saliente. La implementación de DMARC para el dominio personalizado incluye estos pasos:
Paso 1: Identificar orígenes válidos de correo para el dominio
Si ya ha configurado SPF, ya ha realizado este ejercicio. Hay algunas consideraciones adicionales para DMARC. Al identificar orígenes de correo para su dominio, responda a estas dos preguntas:
¿Qué direcciones IP envían mensajes desde mi dominio?
En los correos electrónicos enviados por parte de terceros en mi nombre, ¿coincidirán los dominios 5321.MailFrom y 5322.From?
Paso 2: Configurar SPF para el dominio
Ahora que tiene una lista de todos los remitentes válidos, puede seguir los pasos para Configurar SPF para evitar la suplantación de identidad.
Por ejemplo, suponiendo que contoso.com envía correos desde Exchange Online, un servidor Exchange local cuya dirección IP fuera 192.168.0.1 y una aplicación web cuya dirección IP fuera 192.168.100.100, el registro TXT de SPF tendría este aspecto:
contoso.com IN TXT " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"
Como práctica recomendada, asegúrese de que el registro TXT de SPF tenga en cuenta a los remitentes externos.
Paso 3: Configurar DKIM para el dominio personalizado
Cuando haya configurado SPF, deberá configurar DKIM. DKIM le permite agregar una firma digital a los mensajes de correo electrónico en el encabezado del mensaje. Si no configura DKIM pero permite a Microsoft 365 usar la configuración predeterminada de DKIM en el dominio, DMARC puede dar errores. Este error puede producirse porque la configuración predeterminada de DKIM usa el dominio de onmicrosoft.com original como la dirección 5321.MailFrom, no el dominio personalizado. Esto provoca una discrepancia entre las direcciones 5321.MailFrom y 5322.From en todos los correos electrónicos enviados desde su dominio.
Si hay remitentes externos que envían correo en su nombre y el correo que envían tiene direcciones 5322.From y 5321.MailFrom que no coinciden, se producirá un error de DMARC en este correo electrónico. Para evitar esto, tendrá que configurar DKIM para el dominio, en concreto con ese remitente externo. Esto permite a Microsoft 365 autenticar el correo electrónico desde el servicio de esta tercera parte. Sin embargo, también permite a otros usuarios, por ejemplo, Yahoo, Gmail y Comcast, comprobar la validez del correo electrónico que les envía la tercera parte como si lo hubiera enviado usted. Esto es beneficioso porque permite a los clientes generar relaciones de confianza con el dominio independientemente del sitio donde se encuentre su buzón y, al mismo tiempo, Microsoft 365 no marca un mensaje como correo no deseado por suplantación de identidad, ya que pasa las comprobaciones de autenticación para el dominio.
Para ver las instrucciones sobre cómo configurar DKIM para el dominio, incluyendo cómo configurar DKIM para remitentes externos para que puedan suplantar la identidad de su dominio, consulte Usar DKIM para validar el correo electrónico saliente enviado desde el dominio personalizado.
Paso 4: Formular el registro TXT de DMARC para el dominio
Aunque existen otras opciones de sintaxis que no se mencionan aquí, estas son las opciones de sintaxis más usadas en Microsoft 365. Formule el registro TXT de DMARC para el dominio con el siguiente formato:
_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100"
Donde:
domain es el dominio que quiere proteger. De forma predeterminada, el registro protege el correo del dominio y todos los subdominios. Por ejemplo, si especifica _dmarc.contoso.com, DMARC protege correo del dominio y todos los subdominios, como housewares.contoso.com o plumbing.contoso.com.
TTL siempre debe ser el equivalente a una hora. La unidad usada para el TTL, ya sean las horas (1 hora), los minutos (60 minutos) o los segundos (3600 segundos), variará en función del registrador del dominio.
pct=100 indica que esta regla debe usarse para el 100 % del correo electrónico.
policy especifica qué directiva quiere que el servidor de recepción siga si se produce un error en DMARC. Puede establecer la directiva en none, quarantine o reject.
Para obtener información sobre las opciones que se usan, familiarícese con los conceptos en Procedimientos recomendados para la implementación de DMARC en Microsoft 365.
Ejemplos:
Directiva establecida en none
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none"Directiva establecida en quarantine
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=quarantine"Directiva establecida en reject
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=reject"
Una vez que formule el registro, debe actualizarlo en el registrador del dominio.
CORREO DMARC
Precaución
Es posible que los correos no se envíen diariamente.
En este registro TXT de DMARC de ejemplo: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1", puede ver la dirección rua . Esta dirección se usa para enviar "comentarios agregados" para el análisis, que se usa para generar un informe.
Sugerencia
Visite el catálogo de MISA para ver más proveedores de terceros que ofrecen informes DMARC para Microsoft 365. Vea Domain-based Message Authentication, Reporting, and Conformance (DMARC) de IETF.org para obtener más información sobre las direcciones "rua" de DMARC.
Procedimientos recomendados para la implementación de DMARC en Microsoft 365
DMARC se puede implementar gradualmente sin que esto afecte al resto del flujo de correo. Cree e implemente un plan de implementación que siga estos pasos. Realice cada uno de estos pasos primero con un subdominio, luego con otros subdominios y, finalmente, con el dominio de nivel superior de la organización antes de continuar con el paso siguiente.
Supervisar el impacto de implementar DMARC
Comience con un registro en modo de supervisión simple para un subdominio o dominio que solicita que los receptores DMARC le envíen estadísticas sobre los mensajes que usan ese dominio. Un registro en modo de supervisión es un registro TXT de DMARC con la directiva establecida en none (p=none). Muchas empresas publican un registro TXT de DMARC con p=none porque no saben cuánto correo electrónico pueden perder al publicar una directiva de DMARC más restrictiva.
Puede hacer esto incluso antes de implementar SPF o DKIM en la infraestructura de mensajería. Sin embargo, no podrá poner en cuarentena ni rechazar eficazmente el correo mediante DMARC hasta que no implemente también SPF y DKIM. Al introducir SPF y DKIM, los informes generados a través de DMARC proporcionarán los números y orígenes de mensajes que pasan estas comprobaciones, frente a los que no. Se puede ver fácilmente qué cantidad del tráfico legítimo está cubierto o no por ellos, así como solucionar los problemas. También empezará a ver cuántos mensajes fraudulentos se envían y desde dónde se envían.
Solicitar que los sistemas de correo externos pongan en cuarentena el correo que no supera las comprobaciones de DMARC
Cuando cree que todo el tráfico legítimo o la mayor parte está protegido por SPF y DKIM, y sabe cuál es el impacto de implementar DMARC, puede implementar una directiva de cuarentena. Una directiva de cuarentena es un registro TXT de DMARC con una directiva establecida en quarantine (p=quarantine). Al hacer esto, pedimos a los receptores DMARC que pongan los mensajes de su dominio que no superen las pruebas de DMARC en el equivalente local a una carpeta de correo no deseado, en lugar de en las bandejas de entrada de los clientes.
Solicitar que los sistemas de correo externos no aceptan mensajes que no superen las pruebas de DMARC
El último paso es implementar una directiva de rechazo. Una directiva de rechazo es un registro TXT de DMARC con una directiva establecida en reject (p=reject). Al hacerlo, pedimos a los receptores DMARC que no acepten los mensajes que no pasan las comprobaciones de DMARC.
¿Cómo configuro DMARC para un subdominio?
DMARC se implementa mediante la publicación de una directiva como un registro TXT en DNS y es jerárquica (por ejemplo, una directiva publicada para contoso.com se aplicará a sub.domain.contoso.com a menos que se defina explícitamente una directiva diferente para el subdominio). Esto es útil para que las organizaciones puedan especificar un número más reducido de registros de DMARC de alto nivel para un mayor alcance. Se debe prestar especial atención a la configuración de registros de DMARC de subdominios explícitos en los que no quiera que los subdominios hereden el registro de DMARC del dominio de nivel superior.
Asimismo, con el valor
sp=reject, puede agregar una directiva de tipo comodín para DMARC cuando los subdominios no puedan enviar correos electrónicos. Por ejemplo:_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
Rechazo de DMARC
DMARC p=reject es una directiva establecida en el registro TXT de DMARC por los propietarios de dominio para notificar a los proveedores de servicios que rechacen el correo electrónico que produce un error en DMARC.
Se produjo porque cuando OReject se establece como valor predeterminado, el correo electrónico rechazado se envió a la cuarentena en Enterprise y a la carpeta Junk Email en Consumer (debido a la falta de cuarentena en Consumer). Sin embargo, con DMARC p=reject, se rechaza el correo electrónico.
La configuración se puede realizar en el portal de Microsoft Defender o mediante los cmdlets New-AntiPhishPolicy o Set-AntiPhishPolicy de Exchange Online PowerShell. Para más información, consulte los siguientes artículos:
- Protección contra suplantación de identidad y directivas DMARC del remitente
- Configuración de directivas contra phishing en EOP
- Configuración de directivas contra phishing en Microsoft Defender para Office 365
Cómo controla Microsoft 365 el correo electrónico saliente que no supera las comprobaciones de DMARC
Si un mensaje sale de Microsoft 365 y no supera las comprobaciones de DMARC, y ha establecido la directiva en p=quarantine o p=reject, el mensaje se enruta a través del Grupo de entrega de alto riesgo para mensajes salientes. No hay ninguna invalidación para el correo saliente.
Si publica una directiva de rechazo de DMARC (p=reject), ningún otro cliente de Microsoft 365 podrá suplantar la identidad de su dominio porque los mensajes no podrán pasar las comprobaciones de SPF o DKIM para el dominio al retransmitir un mensaje saliente a través del servicio. Sin embargo, si publica una directiva de rechazo de DMARC, pero no dispone de todo el correo electrónico autenticado a través de Microsoft 365, una parte del correo entrante se puede marcar como correo no deseado (como se describe más arriba) o se rechazará si no publica SPF e intenta retransmitirlo para que salga a través del servicio. Esto sucede, por ejemplo, si se olvida de incluir algunas de las direcciones IP para servidores y aplicaciones que envían correo en nombre de su dominio al formular el registro TXT de DMARC.
Cómo controla Microsoft 365 el correo electrónico entrante que no supera las comprobaciones de DMARC
Si la directiva DMARC del dominio de envío es p=reject, Exchange Online Protection (EOP) rechaza el mensaje de forma predeterminada. Puede configurar directivas contra suplantación de identidad para respetar o no las p=quarantine directivas DMARC del remitente y p=reject especificar acciones independientes para p=quarantine y p=reject. Para obtener más información, consulte Protección contra suplantación de identidad y directivas DMARC de remitente.
Cuando las directivas contra suplantación de identidad están configuradas para no respetar p=quarantine o p=reject en directivas DMARC, los mensajes que producen un error en DMARC se marcan como correo no deseado y no se rechazan. Los usuarios todavía pueden obtener estos mensajes en su bandeja de entrada a través de estos métodos:
- Los usuarios agregan a los remitentes seguros de manera individual mediante el cliente de correo electrónico
- Los administradores pueden usar la Información de la inteligencia contra la suplantación de identidad o la Lista de bloqueados y permitidos de espacio empresarial para permitir los mensajes del remitente al que le han suplantado la identidad.
- Los administradores crean una regla de flujo de correo (también conocida como regla de transporte) de Exchange para todos los usuarios que permite los mensajes de esos remitentes concretos.
- Los administradores crean una regla de flujo de correo de Exchange para todos los usuarios para el correo electrónico rechazado que produce un error en la directiva DMARC de la organización.
Para obtener más información, consulte Crear listas de remitentes seguros.
Cómo Microsoft 365 utiliza la cadena de recepción autenticada (ARC)
Todos los buzones hospedados en Microsoft 365 ahora tendrán la ventaja de ARC con una mejor entrega de mensajes y la protección mejorada contra la suplantación de identidad. ARC preserva los resultados de la autenticación de correo electrónico de todos los intermediarios participantes, o saltos, cuando un correo electrónico se enruta desde el servidor de origen hasta el buzón del destinatario. Antes de ARC, las modificaciones realizadas por intermediarios en el enrutamiento del correo electrónico, tales como las reglas de reenvío o las firmas automáticas, podían causar errores de DMARC al momento en que el correo electrónico llegaba al buzón del destinatario. Con ARC, la conservación criptográfica de los resultados de la autenticación permite a Microsoft 365 comprobar la autenticidad del remitente de un correo electrónico.
Actualmente, Microsoft 365 usa ARC para comprobar los resultados de la autenticación cuando Microsoft es el que proporciona el sello ARC, pero, en el futuro, tiene previsto proporcionar soporte a terceros que proporcionan el sello ARS.
Solución de problemas en la implementación de DMARC
Si ha configurado los registros MX de su dominio donde EOP no es la primera entrada, los errores de DMARC no se aplicarán en su dominio.
Si usted es cliente y el registro MX principal del dominio no apunta a EOP, no obtendrá las ventajas de DMARC. Por ejemplo, DMARC no funcionará si apunta el registro MX al servidor de correo local y luego enruta el correo electrónico a EOP usando un conector. En este escenario, el dominio receptor es uno de los dominios aceptados, pero EOP no es el MX principal. Por ejemplo, si contoso.com apunta su MX a sí mismo y usa EOP como registro MX secundario, el registro MX de contoso.com será así:
contoso.com 3600 IN MX 0 mail.contoso.com
contoso.com 3600 IN MX 10 contoso-com.mail.protection.outlook.com
Todo el correo electrónico o la mayor parte se enrutará primero a mail.contoso.com, ya que es el MX principal, y luego el correo se enrutará a EOP. En algunos casos, ni siquiera podría marcar EOP como registro MX y solo podría enlazar conectores para enrutar el correo electrónico. EOP no tiene por qué ser la primera entrada para que se realice la validación de DMARC. Solo garantiza la validación para asegurarse de que todos los servidores locales o que no sean de O365 realizarán comprobaciones DMARC. Es posible aplicar DMARC a un dominio del cliente (no a un servidor) cuando configura el registro TXT de DMARC, pero el servidor receptor es el que realmente hace la exigencia. Si configura EOP como servidor de recepción, EOP realiza la exigencia de DMARC.
Más información
¿Quiere más información sobre DMARC? Estos recursos lo pueden ayudar.
Los Encabezados de mensajes de correo no deseado incluyen la sintaxis y los campos de encabezado que usa Microsoft 365 para efectuar comprobaciones de DMARC.
Siga la Serie de aprendizaje de DMARC de M3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
Use la lista de comprobación que verá en dmarcian.
Vaya directamente al origen en DMARC.org.
Vea también
Configurar SPF en Microsoft 365 para ayudar a evitar la suplantación de identidad