Lección 1 - Introduction To Exchange Online Protection

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 38

Introducción de la lección

Los inquilinos de Office 365 con buzones alojados en Exchange Online confían en el servicio
Exchange Online Protection (EOP) para enrutar el correo entrante y saliente. Pero, además de
enrutar el correo electrónico, EOP también es fundamental para proteger a las organizaciones del
phishing, la suplantación de identidad, el spam y el malware. EOP proporciona seguridad de correo
electrónico a través de una combinación de técnicas que incluyen IP y reputación del remitente,
heurística, filtrado de correo no deseado, filtrado de malware, aprendizaje automático y filtrado
para suplantación de identidad y suplantación de identidad.

Juntos, EOP y Office 365 ATP proporcionan una solución completa para proteger a los usuarios
contra las amenazas cibernéticas que se originan en el correo electrónico. Si bien la mayor parte
de este módulo se enfoca en los beneficios y la implementación de Office 365 ATP, tiene sentido
comenzar por revisar las capacidades de EOP.

En esta lección, revisaremos cómo fluye el correo a través de EOP y las tecnologías que utiliza para
bloquear el correo no deseado, el correo electrónico masivo y el malware antes de que llegue a los
buzones de los usuarios. También discutiremos cómo EOP protege a las organizaciones contra el
phishing y la suplantación de identidad, incluidas las técnicas que los administradores pueden
implementar para proporcionar mayor protección.

Después de esta lección, podrá:

 Describa la canalización antimalware a medida que Exchange Online Protection analiza el


correo electrónico.

 Enumere varios mecanismos utilizados para filtrar el spam y el malware.

 Describa tres soluciones que los administradores pueden implementar para proporcionar
protección adicional contra el phishing y la suplantación de identidad.

 Describa los beneficios de la función Spoof Intelligence en el Centro de seguridad y


cumplimiento.
La canalización antimalware en Office 365

Las organizaciones que han alojado buzones en Exchange Online confían en Exchange Online
Protection para enrutar el correo entrante y saliente. Cuando una organización se une a Office
365, un administrador agregará registros MX y TXT específicos de Office 365 a su nombre de
dominio en DNS. El registro MX garantiza que el correo electrónico enviado al dominio del
inquilino llegue a los buzones alojados en Exchange Online a través del servicio EOP. El registro
TXT es un registro del Marco de protección del remitente (SPF), que es un tipo especial de registro
TXT en DNS que identifica a un host como un remitente válido para su dominio.

Antes de que el correo ingrese a la red de Office 365 y sea procesado por EOP, las técnicas como IP
y reputación del remitente, combinadas con la heurística, capturan una cantidad considerable de
correo no deseado y correo masivo en el primer punto de entrada en Office 365. Una vez que el
correo pasa por la primera entrada En Office 365, es escaneado por múltiples escáneres antivirus
basados en firmas. Esto por sí solo es efectivo para atrapar hasta el 80% del malware básico que
ingresa a la red. Pero los archivos adjuntos maliciosos que se modifican o liberan en gran medida
con muchas variantes diferentes que salen al mismo tiempo todavía pueden pasar.

A continuación, EOP escanea archivos individuales usando una técnica llamada bloqueo de
reputación. Con el bloqueo de reputación, EOP compara los archivos adjuntos con los resultados
de los análisis que se realizaron previamente en todo Office 365. Luego, verifica si hay archivos
específicos, o fragmentos de archivos, que previamente se identificaron como maliciosos que
parecen coincidir con algo en Un mensaje entrante.

La agrupación heurística se utiliza para identificar el correo como sospechoso simplemente en


función de un análisis de los patrones de entrega. Cuando esto ocurre, se envía una muestra de un
clúster a un entorno de entorno limitado de hipervisor donde se abre el archivo para su posterior
análisis. Este análisis incluye:

 Comprobación de anomalías como cambios en la memoria, el registro o el cifrado del


disco duro

 Comprobación de cambios en el tráfico de red, como conexiones a los servidores de


comando y control de hackers

 Identificar cuándo el malware intenta ofuscarse o usar técnicas de evasión

Una vez que se recopilan estas señales, los resultados se ejecutan a través de un modelo de
aprendizaje automático (ML) y un conjunto de reglas estáticas para determinar si el archivo es
simplemente sospechoso o verdaderamente malicioso.

Si Office 365 ATP está habilitado en el inquilino, ATP extiende la protección de EOP escaneando el
correo que lo hizo a través de los filtros y las técnicas descritas anteriormente. La función de
archivos adjuntos seguros de ATP escanea todos los archivos adjuntos, ya sea que parezcan
sospechosos o no, para proteger contra el malware que no tiene una firma AV conocida. Los
archivos adjuntos se abren en el mismo entorno de sandboxing utilizado por EOP y se analizan en
busca de cambios de comportamiento; nuevamente, cambios en el registro, la memoria, etc.
Una vez que se ha completado el proceso de archivos adjuntos seguros, el cuerpo real del
mensaje, incluidos los encabezados del mensaje, se ejecuta a través de los filtros antispam,
phishing y falsos de EOP. Si hay alguna URL incrustada en el cuerpo del mensaje y ATP está
habilitado en el inquilino, la función de enlaces seguros de ATP verifica el enlace con una lista de
URL maliciosas conocidas que se actualiza aproximadamente cada 20 minutos.

Finalmente, Microsoft también está involucrado con un equipo de analistas de seguridad o


cazadores cibernéticos, que pueden identificar nuevas campañas de amenazas e implementar
rápidamente reglas para proteger aún más la red de Office 365 contra ataques cibernéticos.

La canalización antimalware compuesta por EOP y ATP proporciona protección contra todo tipo de
spam y amenazas avanzadas mediante el uso de un enfoque de defensa en profundidad de varias
capas para resolver la seguridad del correo electrónico.

Información adicional: para obtener más información acerca de EOP, consulte el curso de


capacitación en línea titulado Administración de Microsoft Exchange Online en Office 365
(CLD222x) .
Purga automática de cero horas - Zero-hour auto purge

La purga automática de hora cero (ZAP) es una función de protección de correo electrónico en el
servicio de Protección en línea de Exchange que detecta mensajes con spam o malware que
anteriormente no se detectaron y se entregaron a las bandejas de entrada de los usuarios. Esto
generalmente se debe a la evolución de los patrones heurísticos y de entrega.

ZAP mitiga esto al monitorear continuamente las actualizaciones de las firmas de spam y malware
de Office 365 y puede identificar mensajes maliciosos no detectados previamente que ya están en
las bandejas de entrada de los usuarios. Si los destinatarios no han leído los mensajes, ZAP mueve
los mensajes a su carpeta de correo no deseado. Lo contrario es cierto para los mensajes que se
clasificaron incorrectamente como maliciosos (es decir, falsos negativos). Por ejemplo, si un
mensaje se marcó como spam y se entregó a la carpeta de correo no deseado del usuario, ZAP lo
movería a la bandeja de entrada del usuario.
Spoof Intelligence - Parodia de inteligencia

Como se discutió anteriormente, la suplantación de identidad se controla mediante la protección


incorporada proporcionada por EOP y mediante la implementación de técnicas de autenticación
como SPF, DKIM y DMARC. Para los clientes que tienen Office 365 Enterprise E5 o han comprado
licencias de Protección contra amenazas avanzadas, la función de Inteligencia de suplantación en
el Centro de seguridad y cumplimiento de Office 365 (SCC) puede proporcionar información sobre
los remitentes que están falsificando su dominio. Puede revisar los remitentes que están
falsificando su dominio y luego elegir permitir que el remitente continúe o bloquear al remitente.

La política de inteligencia de falsificación se crea automáticamente, se habilita de manera


predeterminada y se aplica por O365. Si bien no se puede deshabilitar, puede administrarlo y
controlar qué dominio o usuario puede falsificar su dominio revisando la política existente
aplicada en el SCC.
Managing spoof intelligence - Gestionar la inteligencia de parodia

Para cada cuenta de usuario falsificada que un remitente falsifique de su dominio, puede ver la
información en la siguiente tabla.

Administre remitentes que están falsificando su dominio

Siga estos pasos para ver los remitentes que falsifican su dominio y decidir si se debe permitir a
cada remitente hacerlo o no.

1. Vaya al Centro de seguridad y cumplimiento e ingrese sus credenciales de administrador.

2. En el Centro de seguridad y cumplimiento, expanda Administración de amenazas> Política.

3. Haz clic en Anti-Spam.

4. En el panel derecho, en la pestaña Estándar, expanda Inteligencia de parodia


5. Para ver la lista de remitentes que falsifican su dominio, seleccione Revisar nuevos
remitentes.

Nota: Si ya ha revisado los remitentes y desea cambiar algunas de sus opciones anteriores, puede
seleccionar Mostrar remitentes que ya revisé.

6. Cada fila en la pestaña Estándar representa un remitente que está falsificando uno o más
usuarios en su organización. Si un remitente está falsificando varios usuarios y desea
permitir que el remitente falsifique algunos usuarios, pero no otros, en la pestaña
Estándar, seleccione Elegir usuarios.
Esto abre la pestaña Detallado con la lista de usuarios que están siendo falsificados divididos en
filas individuales para que pueda elegir si permite o no que el remitente falsifique a cada usuario
individualmente.

Para agregar un remitente a la lista de permisos para un usuario, seleccione Sí en ¿Permitido para


falsificar? columna. Para agregar un remitente a la lista de bloqueo para un usuario,
seleccione Ninguna.

7. Haga clic en Guardar para guardar cualquier cambio.


Phishing and spoofing protection

Protección contra suplantación de identidad y suplantación de identidad

Por diseño, el protocolo SMTP admite suplantación de identidad. Permite que un dominio envíe en
nombre de otro dominio porque hay razones legítimas para hacerlo; por ejemplo, cuando ha
contratado a una empresa externa para generar y enviar publicidad o actualizaciones de productos
en su nombre. O bien, puede tener una aplicación que falsifique su propia organización para
enviar notificaciones internas por correo electrónico.

Pero la suplantación de identidad también es utilizada por los phishers para hacer que alguien crea
que está recibiendo correo de alguien que no es, generalmente en un esfuerzo por engañar al
destinatario para que divulgue las credenciales de la cuenta o comparta información confidencial.

EOP tiene una protección incorporada contra la suplantación de identidad y contra la suplantación
de identidad diseñada para detectar casos legítimos de suplantación de identidad mientras
protege a las organizaciones de las ilegítimas. Sin embargo, a veces el servicio no tiene suficiente
inteligencia o historial para tomar esa determinación. Por ejemplo, esto puede suceder si un
nuevo remitente sin reputación comienza a enviar correos electrónicos o si el volumen de correo
electrónico es demasiado pequeño para generar una reputación positiva.

Es por estas razones que EOP admite técnicas de autenticación de correo electrónico que incluyen
el Marco de políticas del remitente (SPF), el Correo identificado de DomainKeys (DKIM) y el
Cumplimiento de informes y mensajes basados en el dominio (DMARC) para ayudar a detectar
casos legítimos de suplantación de identidad mientras evita la suplantación de identidad no
deseada y suplantación de identidad. Estas técnicas utilizan el Sistema de nombres de dominio
(DNS) para agregar información verificable a los mensajes de correo electrónico sobre el remitente
de un mensaje de correo electrónico.

Nota: Se recomienda que los administradores de Office 365 implementen estas tres técnicas de
autenticación de correo electrónico.

Marco de políticas del remitente (SPF)

Un registro TXT SPF es un registro DNS que ayuda a evitar la suplantación de identidad y el
phishing al verificar el nombre de dominio desde el que se envían los mensajes de correo
electrónico. SPF valida el origen de los mensajes de correo electrónico verificando la dirección IP
del remitente frente al supuesto propietario del dominio emisor y determina si un remitente
puede enviar en nombre de un dominio. Si al remitente no se le permite hacerlo, es decir, si el
correo electrónico no pasa la verificación SPF en el servidor receptor, la política de spam
configurada en ese servidor determina qué hacer con el mensaje. Durante la configuración inicial
en Office 365, los administradores de inquilinos crean un registro TXT SPF en DNS para garantizar
que los sistemas de correo electrónico de destino confíen en los mensajes enviados desde el
dominio personalizado del inquilino, es decir, contoso.com versus contoso.onmicrosoft.com.
DomainKeys Identified Mail (DKIM)

DKIM se puede habilitar en Office 365 para dominios personalizados y ayuda a evitar que los
falsificadores envíen mensajes que parecen provenir de su dominio al agregar una firma digital a
los mensajes de correo electrónico en el encabezado del mensaje. Cuando configura DKIM,
autoriza a su dominio a asociar o firmar su nombre a un mensaje de correo electrónico mediante
la autenticación criptográfica. Los sistemas de correo electrónico que reciben correo electrónico
de su dominio pueden usar esta firma digital para ayudar a determinar si el correo electrónico
entrante que reciben de usted es legítimo.

Cumplimiento de mensajería e informes basados en dominio (DMARC)

DMARC también se puede habilitar para dominios personalizados y protege el caso donde un
phisher ha falsificado el 5322. Desde la dirección de correo electrónico, que es la dirección de
correo electrónico que se muestra en clientes de correo como Outlook y outlook.com. Por el
contrario, SPF detecta el caso donde el phisher falsifica la dirección 5321.MailFrom, que es donde
se dirigen los mensajes de rebote, mientras que DMARC detecta el caso que es más
engañoso. DMARC ayuda a recibir los sistemas de correo a determinar qué hacer con los mensajes
que fallan las comprobaciones SPF o DKIM y proporciona otro nivel de confianza para sus socios de
correo electrónico.

Información adicional: consulte los siguientes artículos para obtener información adicional sobre
phishing y protección contra la suplantación de identidad:

 Cómo funciona la protección antifalsificación en Office 365

 Cómo Office 365 usa Sender Policy Framework (SPF) para evitar la suplantación de
identidad

 Use DKIM para validar el correo electrónico saliente enviado desde su dominio
personalizado en Office 365

 Use DMARC para validar el correo electrónico en Office 365


Cómo funciona la protección antiseño en Office 365

Exchange Online Protection (EOP), el componente de filtrado de correo electrónico de Office 365,
está implementando, o ya ha implementado, una protección completa contra el obispo para todos
sus clientes. La mayoría de nuestros clientes ya tienen esta protección, y ahora nos estamos
preparando para implementarla para todos los demás.

En los últimos meses, EOP (junto con el resto de la industria) ha visto un aumento masivo en los
ataques dirigidos de phishing donde el atacante engaña a un empleado de la organización, como el
CEO, y envía un correo electrónico a otro empleado de alto rango, como el CFO, pidiéndoles que
realicen una transferencia bancaria o un comportamiento similar. No hay archivos adjuntos o
enlaces en el mensaje, solo instrucciones de lenguaje regulares que le piden al objetivo que
cumpla con las demandas.

Por ejemplo:

Estos tipos de mensajes se envían en bajo volumen y contienen un lenguaje que es


gramaticalmente correcto sin errores de ortografía, pero son fraudulentos. También pueden
causar mucho daño financiero a una organización si el destinatario objetivo no es consciente de
que el mensaje es malicioso.

EOP ya tiene tecnología antispoofing que incluye SPF, DKIM y DMARC. Sin embargo, muchas
organizaciones no tienen la experiencia o los recursos necesarios para establecerlos o
mantenerlos. Sin embargo, todavía necesitan protección antisofobia: este tipo de mensajes deben
detectarse y los usuarios deben protegerse incluso si no tiene publicados los registros de
autenticación necesarios.

Esta Protección de phishing de lanza de  dominio exacto (también conocido como Compromiso de


correo electrónico comercial) es la nueva característica que EOP ha implementado la detección de
suplantación de identidad para su dominio incluso sin los registros estándar SPF, DKIM o DMARC.

No tiene que hacer nada para recibir esta protección, la obtiene automáticamente de forma
gratuita. Además, puede personalizarlo para hacerlo más o menos estricto permitiendo que otros
envíen en su nombre.
¿Cómo lo resuelve EOP?

Primero, EOP verifica si el mensaje está destinado a su organización y proviene de cualquiera de


sus dominios aprovisionados, o un subdominio de cualquiera de sus dominios aprovisionados. Por
ejemplo, cualquiera de estos puede ser una parodia potencial:

Si los dominios From y To se alinean, EOP verifica si el mensaje es legítimo. ¿Es un mensaje que se
originó internamente dentro de la organización? Está bien. ¿Están autorizados a enviar correos
electrónicos en su nombre? Eso también está bien. ¿Es un buen remitente masivo conocido? Está
bien. EOP también utiliza la reputación del dominio de envío (o falta de reputación), la reputación
de IP de envío, la reputación del destinatario (¿cuántos mensajes recibe de este remitente? ¿Cómo
se enruta su correo electrónico a través del servicio EOP?), Y también hace uso del aprendizaje
automático.

EOP utiliza todos estos datos para asegurarse de que el servicio marque el correo electrónico
malicioso como falsificaciones y no cualquier correo electrónico legítimo.
Cómo saber si EOP piensa que un mensaje es una parodia

Cuando EOP piensa que un mensaje "de" su dominio a cualquiera de sus dominios es una
falsificación, lo marca como spam y agrega el siguiente encabezado:

X-Microsoft-Antispam:…; SFTY: 9.5

El X-Microsoft-Antispam cabecera ya se utiliza al final del proyecto para indicar varios otros


componentes de filtrado de correo no deseado. El SFTY: 9.5 o SFTY: 9.11 se refiere al nivel de
seguridad de un mensaje. Esta propiedad de encabezado tiene otros valores, pero están
reservados para uso interno por EOP.

Puede verificar esto nuevamente mirando la dirección De: y la dirección Para:. Ambos dominios
serán iguales, subdominios entre sí o parte de sus dominios aceptados.

A fines del segundo trimestre de 2016, EOP comenzará a agregar Consejos de seguridad al
mensaje. Los consejos de seguridad son indicadores visuales que le permiten saber que el mensaje
es fraudulento o puede ser una estafa de phishing. Estos consejos de seguridad son visibles
cuando se usa Outlook en la web para ver su correo electrónico.
¿Cuánto correo electrónico se marcará como spam debido a este cambio?

Para ver cuánto correo electrónico marca esta función como spam, EOP también le permitirá ver
quién envía el correo electrónico con su dominio en el encabezado 5322.Desde el encabezado (el
que aparece en el cliente de correo electrónico) a los dominios de su organización. Por ejemplo,
suponga que tiene aprovisionados todos los siguientes dominios:

contoso.com
fabrikam.com
woodgrovebank.com

Este informe le dirá todas las combinaciones de:

Desde: A:
contoso.com contoso.com
contoso.com foo.contoso.com
contoso.com fabrikam.com
foo.contoso.com bar.woodgrovebank.com
Etcétera.

Para ver este informe usando Powershell (nota: los * -PhishFilterPolicycmdlets solo están
disponibles si ha comprado la licencia E5 o la licencia de Protección contra amenazas avanzadas):

1. Conéctese a Exchange Online con Powershell

 Ejecute el siguiente cmdlet: Get-PhishFilterPolicy –SpoofAllowBlockList | Export-CSV


"SpoofingSenders.csv" O, para obtener más detalles:

Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed | Export-CSV


"DetailSpoofingSenders.csv" Este cmdlet exportará todos los datos enviados a su
organización durante los últimos 30 días.

 Abra y revise el archivo * .csv descargado. Los nombres de las columnas se detallan a


continuación, con los que se marcarán como spam en negrita en púrpura:
Columna Descripción

PSComputerName Utilizado internamente por EOP

RunspaceId Utilizado internamente por EOP

PsShowComputerName Utilizado internamente por EOP

Remitente verdadero El dominio organizativo del registro PTR de la dirección IP de


envío que está falsificando su organización. Si no se encuentra
ningún dominio, se muestra la IP del remitente.

Volumen de correo Número de mensajes enviados a su organización por este


remitente en los últimos 30 días

Quejas del usuario Número de envíos no deseados de sus usuarios


correspondientes a este remitente en los últimos 30 días

Permitido falsificar Indica si esta entidad puede falsificar su organización. Hay 3


valores posibles:

Sí: todas las direcciones falsificadas de este remitente


falsificador podrán falsificar su organización

No: no se permitirá que las direcciones falsificadas de este


remitente falsifiquen su organización. Los mensajes de este
remitente se marcarán como spam cuando la función esté
habilitada.

Parcial: algunas direcciones falsificadas de este remitente de


suplantación de identidad podrán falsificar su organización, el
resto se marcará como spam. Agregue
el parámetro detallado para ver las direcciones específicas.

Remitente falso El remitente visible falsificado desde el que parece enviarse el


(solo incluido con el parámetro mensaje (en la dirección De: en su cliente de correo
detallado) electrónico, también conocido tiene el encabezado.from)

Resultado de autenticación (solo Esto muestra Pasado si el remitente pasó las verificaciones de


incluido con autenticación del remitente EOP (como SPF o DKIM), Falló si el
el parámetro detallado) remitente falló las verificaciones de autenticación del
remitente EOP, o Desconocido si no se conoce el resultado

Fuente de Permitido para suplantar Indica si el veredicto permitido para falsificar fue determinado
(solo incluido con automáticamente por el filtro de phishing o establecido por el
el parámetro detallado) administrador.

 
¿Cómo puede excluir a ciertos remitentes de ser marcados como spam?

Aunque EOP intenta excluir a todos los remitentes legítimos de ser marcados como spam, es
posible que el servicio no tenga suficiente historial para tomar esa determinación. Esto puede
suceder si un nuevo remitente comienza a enviar correos electrónicos como usted, o si el volumen
de correo electrónico es demasiado pequeño para generar una reputación positiva, o si el
remitente viene con un conjunto de IP que se sabe que envían correo no deseado o phishing. EOP
se autocorrige en los casos en que tiene suficientes datos para tomar una decisión, pero otros
casos de esquina pueden continuar marcados como spam.

Para eliminar la posibilidad de falsos positivos, recomendamos a los administradores que utilicen
una de las siguientes cuatro opciones para excluir a los remitentes de ser marcados como spam
por nuestro filtro antispoofing:

1. Agregue las direcciones IP del remitente a su registro SPF, o haga que se autentiquen con
DKIM

Puede usar SPF o DKIM para que un tercero envíe un correo electrónico en su nombre , sin
embargo, no es suficiente que un mensaje simplemente pase SPF o DKIM; el dominio en la
dirección De: debe alinearse con el dominio que pasó SPF o DKIM (ya sea una coincidencia exacta
o un subdominio).

Cualquiera que sea el método que elija, o idealmente elegir ambos métodos, esto permitirá que
EOP autentique los correos electrónicos de estos servicios de terceros que se envían como su
dominio a su dominio.

Sin embargo, también permite que otros (por ejemplo, Yahoo, Gmail, Comcast, etc.) verifiquen el
correo electrónico que envían como usted. Esto es beneficioso porque permite a sus clientes
generar confianza con su dominio sin importar dónde se encuentre su buzón y, al mismo tiempo,
EOP no marcará un mensaje como spam debido a suplantación de identidad porque pasa la
autenticación de su dominio.

Usuarios avanzados: para obtener más información sobre cómo hacer que los registros SPF
funcionen alrededor del límite de búsqueda de 10 DNS y automatizar sus registros SPF, consulte la
publicación del blog La autenticación por correo electrónico debe funcionar de inmediato y no
debemos confiar en que los propietarios de dominios lo hagan ellos mismos .
2. Use la política de falsificación en Powershell o UX en el Centro de administración de Exchange
para excluir la dirección IP de envío de la aplicación de Antispoofing

Alternativamente, si desea permitir que varios remitentes envíen correos electrónicos en su


nombre a su dominio (pero aún se somete a un filtro de spam), puede configurarlo explícitamente.

Para permitir que una dirección IP específica envíe correo electrónico como su dominio a sus
dominios usando Powershell (esto solo está disponible si tiene una licencia E5 o ha comprado una
licencia de Protección contra amenazas avanzadas):

a) Conéctese a Exchange Online con Powershell

b) Descargue la lista de remitentes falsificados, como arriba, con vista básica o detallada.

Get-PhishFilterPolicy –SpoofAllowBlockList | Export-CSV "SpoofingSenders.csv"

Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed | Export-CSV "SpoofingSenders.csv"

c) Abra su editor de texto favorito (como el Bloc de notas o el Bloc de notas ++) y busque las IP que
desea especificar anulaciones y escriba Sí o No en la columna Permitido para falsificar.

- Si especifica 'Sí' en la vista Estándar, todas las direcciones de remitente detectadas desde esa
dirección IP se enviarán como su dominio. Especificar 'No' lo evitará (es decir, si EOP puede creer
que es un buen remitente pero puede anularlo). Las futuras direcciones de remitentes detectadas
por el filtro de phishing pueden o no estar bloqueadas o permitidas

- Si especifica 'Sí' o 'No' en la Vista detallada, permitirá o bloqueará la dirección del remitente
detectada del remitente verdadero que falsifica su dominio.

- Si hay remitentes de suplantación de identidad que le gustaría permitir o bloquear de manera


proactiva que actualmente no aparecen en la Vista detallada, puede especificar el veredicto
"Remitente verdadero", "Remitente falso" y el veredicto "Permitido falsificar".

Guarde el archivo con un nuevo nombre UpdatedSpoofingSenders.csv .

d) Actualice los cambios que realizó en la columna "Permitido falsificar" ejecutando los dos
comandos siguientes en este orden:

$ UpdatedSpoofingSenders = Get-Content -Raw UpdatedSpoofingSenders.csv

Set-PhishFilterPolicy –SpoofAllowBlockList $ UpdatedSpoofingSenders

Los remitentes que no permitiste serán bloqueados.

e) Para verificar sus cambios:

Get-PhishFilterPolicy –SpoofAllowBlockList
O

Get-PhishFilterPolicy –SpoofAllowBlockList –Detailed

Bonificación: Office 365 planea brindarle información sobre los datos de inteligencia. Esto abarca
una amplia gama de señales de nuestras diversas plataformas. Estos remitentes de suplantación
de identidad, muchos de los cuales son maliciosos, lo harán en este conjunto de datos de
inteligencia. No es el único conjunto de señales que proporcionaremos, pero es importante. 

3. Agregue la dirección IP del remitente a una lista de IP permitidas en el Centro de


administración de Exchange

Alternativamente, si no desea agregar las direcciones IP del remitente a su registro SPF pero
tampoco desea que el correo electrónico se marque como correo no deseado debido a la
suplantación de identidad, puede agregar la IP o IP a su Lista de IP permitidas. Esto omitirá
cualquier filtro de spam de estas direcciones IP y marcará el mensaje como SCL –1, que entrega el
mensaje a su bandeja de entrada a menos que una Regla de transporte de Exchange (ETR) elimine
o ponga en cuarentena el mensaje.

Si un mensaje omite el filtrado debido a una entrada de la lista de direcciones IP permitidas, verá
las siguientes propiedades insertadas en un encabezado en el mensaje:

X-Forefront-Antispam-Report: IPV: CAL; ... SFV: SKN; ... SCL: -1

IPV: CAL significa "veredicto de filtrado de IP: lista de permitidos del cliente".

Para obtener más información sobre la administración de listas de IP admitidas,


consulte Configuración de la política de filtro de conexión en EOP .

4. Agregue las direcciones IP del remitente más el dominio de envío a una Regla de transporte
de Exchange (ETR) que omite el filtrado

Alternativamente, si no desea omitir el filtrado de todos los correos electrónicos de un conjunto


específico de direcciones IP en su organización porque esas IP son compartidas por más que solo
su dominio, puede crear un ETR. El ETR debe buscar una combinación de direcciones IP de
envío y un dominio de envío. Usted debe Nunca crear un ETR que sólo busca su dominio, porque
esto puede ser fácilmente aprovechada por los spammers.

La sintaxis de ETR debe ser:


Puede agregar tantas direcciones IP como desee a la regla, puede agregar otros dominios para
proteger, puede modificar el texto del encabezado para estamparlo para que sea más descriptivo,
e incluso puede especificar Excepciones a la regla.

El resultado es que el correo electrónico de estos rangos de IP envía correo electrónico ya que su
dominio omitirá el filtro de spam y se enviará a las bandejas de entrada de sus usuarios, excepto si
el usuario tiene al remitente en su lista personal de remitentes bloqueados, y no hay otros ETR
que se ejecuten con mayor prioridad que esta regla que toma medidas en el mensaje (por
ejemplo, una regla que envía un correo electrónico a la Cuarentena de administrador).

Si un mensaje omite el filtrado debido a un ETR como el anterior, verá el siguiente encabezado
insertado en el mensaje:

X-Forefront-Antispam-Report: SFV: SKN;… SCL: -1


X-ETR: Antispoofing permite el conjunto de reglas SCL -1

Para obtener más información sobre ETR, consulte

Gestión de reglas de transporte .

Una vez que se libera la funcionalidad Permitir / Bloquear anterior, no necesita hacer este ETR y en
su lugar debe usarlo.

Recuerde: es importante no permitir nunca solo su dominio en un ETR por sí solo sin ningún otro
criterio. Si lo hace, un spammer puede falsificar su dominio y obtendrá un pase gratuito a la
bandeja de entrada.

¿Se puede desactivar la protección antispoofing?

No, la protección antiseñido no se puede desactivar.

En cambio, si obtiene falsos positivos, debe usar cualquiera de las soluciones anteriores para evitar
el filtrado para estos remitentes. Esto garantiza que, en lugar de dejarlo expuesto a mensajes de
phishing, bloquee los tipos de falsificaciones más peligrosos y permita solo remitentes autorizados.

EOP ha hecho un gran trabajo al minimizar los posibles falsos positivos y, por lo tanto, este cambio
causará una interrupción mínima al flujo de correo legítimo.
¿Hay algo más que deba saber?

Si.

1. Para obtener una protección completa contra el desalojo, el registro MX de su dominio


debe apuntar a EOP como su registro MX principal. Si no es así, la protección antispoof no
se implementará para su dominio.
.

2. La protección antispoof no anula las reglas de permiso de IP, las reglas de permiso de ETR
o los remitentes seguros del usuario final, todo lo cual omite el filtro de correo no
deseado. Esto puede cambiar en el futuro.

¿Qué pasa con las listas de correo?

Las listas de correo son las instancias donde es más probable que vea falsos positivos. Esto se debe
a la forma en que se enruta el mensaje:

Cliente de Office 365 (local o totalmente alojado) -> Office 365 -> fuera de la lista de correo (pasa
SPF, DKIM, DMARC) -> vuelve a Office 365 (pasa SPF, pero falla el DKIM original, y DMARC también
fallará) )

Cuando el mensaje se vuelve a reproducir en Office 365, si el mensaje se ha modificado en tránsito


(por ejemplo, la línea de asunto se ha cambiado para incluir [Tema] o se ha agregado un pie de
página con información para cancelar la suscripción), esto pasará SPF (porque el cheque SPF de la
lista pasa) pero no pasa nuestros cheques antispoofing. Este es un problema conocido con las
listas de correo incluso con DMARC.

La solución de la industria es un nuevo estándar llamado Cadena de autenticación recibida , o


ARC. Esta es una manera de pasar resultados de autenticación de forma segura entre servidores
de correo. Sin embargo, ARC todavía está a unos meses de distancia.

Para los clientes, debe hacer lo siguiente:

a) Asegúrese de estar firmando con DKIM -> esto solucionará problemas donde el correo
electrónico no se modifica, pero no donde el correo electrónico se modifica intencionalmente
b) Utilice una de las soluciones anteriores: una autorización de IP para la lista de correo, o una
autorización de ETR basada en el IP de envío + dominio de envío O un ETR basado en el dominio de
envío (de la lista de correo) + 'Autenticación-Resultados' el encabezado contiene 'spf = pass'

c) También puede abrir un ticket de soporte con nosotros. Estamos trabajando en inventariar listas
de correo para excluirlos de los cheques antispoofing. Si haces eso, no necesitarás hacer
(b). Cuando se lanza ARC, y si controla el servidor de correo, también ayudará en la entrega.

Conclusión

Estos cambios en el filtro de spam de EOP ayudarán a proteger a su organización de algunos de los
mensajes de phishing más maliciosos que vemos hoy. La función está diseñada para minimizar los
falsos positivos y, al mismo tiempo, le permite anular las decisiones de filtro cuando sea necesario.

Notas al pie

[1] EOP admite DMARC para el correo electrónico entrante, que es una tecnología para detener la
falsificación del dominio De:. La principal diferencia entre DMARC y la solución Antispoofing de
EOP es que DMARC requiere la publicación de ciertos registros DNS, mientras que la solución
Antispoofing de EOP no. La segunda diferencia es que DMARC envía informes de fallas a las
direcciones de correo electrónico de informes forenses y agregados, mientras que para
Antispoofing de EOP esa información solo está disponible a través de Powershell o a través del
Centro de administración de Exchange.

Para obtener más información, consulte estas publicaciones de blog:

 Usar DMARC en Office 365

 Mejores prácticas para que los clientes de Exchange Online se alineen con DMARC

 ¿Cuál es la mejor combinación para su registro SPF, DKIM y DMARC?

[2] Para configurar servicios de terceros para enviar en su nombre (como su dominio) y hacer que
se autentique utilizando los métodos de autenticación antispam habituales:

a) Autenticación SPF

Si está enviando desde un servidor de correo local o un servicio alojado en la nube, y tiene una
dirección IP dedicada, debe agregarlos a su registro SPF. Por ejemplo, antes de actualizar su
registro SPF, podría verse así:

contoso.com EN TXT "v = spf1 incluye: spf.protection.outlook.com –todos"


Después de agregar la dirección IP dedicada (o el rango de direcciones CIDR), su registro SPF
podría verse así:

contoso.com IN TXT "v = spf1 incluye: spf.protection.outlook.com ip4: 1.2.3.4 –todos"

Si está utilizando un servicio más grande como un proveedor de servicios de correo electrónico
masivo o un proveedor de software como servicio, puede pedirle que incluya todos sus servidores,
lo cual es mucho más manejable:

contoso.com EN TXT "v = spf1 incluye: spf.protection.outlook.com ip4: 1.2.3.4 incluye:


bulkEmailProvider.com –todos"

Si hace esto, su correo electrónico que se envía como usted desde este servicio ahora se
autenticará con SPF.

Para más información:

 Personalice un registro SPF para validar el correo electrónico saliente enviado desde su
dominio en Office 365

 Errores comunes en registros SPF

b) Autenticación DKIM

Algunos proveedores de servicios de correo electrónico masivos, o proveedores de software como


servicio, le permiten configurar claves DKIM para el correo electrónico que se origina fuera de su
servicio. Esto requiere la coordinación entre usted y ellos para configurar los registros DNS
necesarios, y depende de la organización. Este también es un método útil para la autenticación de
correo electrónico.
El mensaje podría verse así:

Ruta de retorno: <[email protected]>


De: <[email protected]>
Firma DKIM: s = s1024; d = contoso.com
Asunto: Aquí hay un mensaje de la infraestructura del proveedor de correo electrónico masivo,
pero con una firma DKIM autorizada por contoso.com

En este ejemplo, el Proveedor de correo electrónico masivo le dio a Contoso una clave DKIM
pública para publicar en su registro DNS, y luego firma con la clave privada correspondiente
cuando envía un correo electrónico y coloca la firma DKIM resultante en el mensaje. Los terceros
pueden autenticarse contra el dominio DKIM d = y compararlo con el dominio en la dirección De:.

Para más información:

 Conexión manual de inicio de sesión DKIM en Office 365

 ¿Qué es el DKIM ?
Con SPF o DKIM, cuando se envía a EOP, se inserta un encabezado en el mensaje con los
resultados de autenticación, y smtp.mailfrom o header.d deben coincidir con el dominio en
header.from. En este caso, contoso.com en el encabezado.d en el encabezado DKIM-Signature se
alinea con el dominio en la dirección De:. En ausencia de un registro DMARC, EOP marca dmarc =
bestguesspass .

Resultados de autenticación: spf = pass (la IP del remitente es 1.2.3.4)


smtp.mailfrom = bulkemailprovider.com; contoso.com; dkim = pasar
(se verificó la firma) header.d = contoso.com; dmarc = bestguesspass
action = none header.from = contoso.com;

Cómo Microsoft 365 usa el marco de directivas de remitente (SPF) para


evitar la suplantación de identidad

Resumen: En este artículo se describe cómo Microsoft 365 usa el registro TXT del marco de
directivas de remitente (SPF) en DNS para asegurarse de que los sistemas de correo electrónico de
destino confían en los mensajes enviados desde su dominio personalizado. Esto se aplica al correo
saliente enviado desde Microsoft 365. Los mensajes enviados desde Microsoft 365 a un
destinatario dentro de Microsoft 365 siempre transmitirán SPF.

Un registro TXT SPF es un registro DNS que ayuda a evitar la suplantación de IP y la suplantación
de identidad mediante la comprobación del nombre del dominio desde el que se envían los
mensajes de correo electrónico. Para validar el origen de los mensajes de correo electrónico, SPF
contrasta la dirección IP del remitente con el supuesto propietario del dominio de envío.

Nota: El Grupo de trabajo de ingeniería de Internet (IETF) consideró en desuso los tipos de registro
SPF en 2014. En su lugar, asegúrese de que usa registros TXT en DNS para publicar la información
SPF. El resto del artículo usa el término registro TXT SPF para mayor claridad.

Los administradores de dominio publican información SPF en registros TXT de DNS. La información
SPF identifica los servidores autorizados de correo electrónico saliente. Los sistemas de correo
electrónico de destino comprueban que los mensajes proceden de servidores de correo
electrónico saliente autorizados. Si ya está familiarizado con SPF o tiene una implementación
sencilla y solo necesita saber qué incluir en el registro TXT de SPF en DNS para Microsoft 365,
puede configurar SPF en microsoft 365 para ayudar a evitar la suplantación de identidad. Si no
dispone de una implementación que esté completamente hospedada en Microsoft 365 o desea
obtener más información sobre cómo funciona SPF o cómo solucionar problemas de SPF para
Microsoft 365, siga leyendo.
Nota: Antes, debía agregar un registro SPF TXT diferente a su dominio personalizado si también
utilizaba SharePoint Online. Esto ya no es necesario. Este cambio debería reducir el riesgo de que
los mensajes de notificación de SharePoint Online acaben en la carpeta de Correo no deseado. No
es necesario realizar ningún cambio inmediatamente, pero si recibe el error "demasiadas
búsquedas", modifique el registro TXT de SPF como se describe en set up SPF in Microsoft 365
para ayudar a evitar la suplantación de identidad.

Cómo funciona SPF para evitar la suplantación de identidad y la


suplantación de identidad en Microsoft 365

SPF determina si permite o no que un destinatario envíe en nombre de un dominio. Si el remitente


no tiene permiso para hacerlo, es decir, si el correo electrónico no supera la comprobación SPF en
el servidor de recepción, la directiva contra el correo no deseado configurada en ese servidor
determina qué hacer con el mensaje.

Cada registro TXT SPF contiene tres partes: la declaración de que se trata de un registro TXT SPF,
las direcciones IP que pueden enviar correo desde su dominio y los dominios externos que pueden
enviar en nombre de su dominio, y una regla de cumplimiento. Un registro TXT SPF válido debe
constar de esas tres partes. En este artículo se describe cómo formar el registro TXT de SPF y se
ofrecen los procedimientos recomendados para trabajar con los servicios de Microsoft
365. También se proporcionan los vínculos a las instrucciones sobre cómo trabajar con el
registrador de dominios para publicar el registro en DNS.

Conceptos básicos de SPF: Direcciones IP que pueden enviar desde su dominio personalizado

Observe la sintaxis básica de una regla SPF:

v=spf1 <IP> <enforcement rule>

Por ejemplo, supongamos que existe la siguiente regla SPF para contoso.com:

v=spf1 <IP address #1> <IP address #2> <IP address #3> <enforcement rule>

En este ejemplo, la regla SPF indica al servidor de correo electrónico de recepción que solo debe
aceptar correo de estas direcciones IP para el dominio contoso.com:

 IP address #1

 IP address #2
 IP address #3

Esta regla SPF indica al servidor de correo electrónico de recepción que si un mensaje proviene de
contoso.com, pero no de una de estas tres direcciones IP, el servidor de recepción debe aplicar la
regla de cumplimiento en el mensaje. Normalmente, la regla de cumplimiento es una de estas
opciones:

 Error grave. Marca el mensaje con "error grave" en el sobre del mensaje y, después, sigue
la política de correo no deseado configurada en el servidor de recepción para este tipo de
mensaje.

 Error leve. Marca el mensaje con "error leve" en el sobre del mensaje. Normalmente, los
servidores de correo electrónico están configurados para enviar estos mensajes de todos
modos. La mayoría de los usuarios finales no ve esta marca.

 Neutro. No hace nada, es decir, no marca el sobre del mensaje. Esto se reserva
normalmente para fines de prueba y rara vez se usa.

Los ejemplos siguientes muestran cómo funciona SPF en diferentes situaciones. En estos ejemplos,
contoso.com es el remitente y woodgrovebank.com es el receptor.

Ejemplo 1: Autenticación de correo electrónico de un mensaje enviado directamente del


remitente al receptor

SPF funciona mejor cuando la ruta de acceso del remitente al receptor es directa, por ejemplo:

Cuando woodgrovebank.com recibe el mensaje, si la dirección IP #1 está en el registro TXT SPF


para contoso.com, el mensaje supera la comprobación SPF y se autentica.

Ejemplo 2: La dirección falsificada del remitente no supera la comprobación SPF

Supongamos que un suplantador de identidad busca una forma de suplantar contoso.com:


Como la dirección IP #12 no está en el registro TXT SPF de contoso.com, el mensaje no supera la
comprobación SPF y el receptor puede marcarlo como correo no deseado.

Ejemplo 3: SPF y los mensajes reenviados

Un inconveniente de SPF es que no funciona cuando se ha reenviado un correo electrónico. Por


ejemplo, supongamos que el usuario de woodgrovebank.com ha configurado una regla de reenvío
para enviar todo el correo electrónico a una cuenta de outlook.com:

En un principio, el mensaje supera la comprobación SPF en woodgrovebank.com pero no supera la


comprobación SPF en outlook.com, ya que la dirección IP #25 no se encuentra en el registro TXT
SPF de contoso.com. Outlook.com puede marcar entonces el mensaje como correo no deseado.
Para solucionar este problema, use SPF junto con otros métodos de autenticación de correo
electrónico como DKIM y DMARC.

Conceptos básicos de SPF: Incluir dominios de terceros que pueden enviar correo en nombre del
dominio

Además de las direcciones IP, también puede configurar el registro TXT SPF para incluir dominios
como remitentes. Estos se agregan al registro TXT SPF como instrucciones "Include". Por ejemplo,
contoso.com quiere incluir todas las direcciones IP de los servidores de correo de contoso.net y
contoso.org que también le pertenece. Para ello, contoso.com publica un registro TXT SPF que
tiene este aspecto:
v=spf1 include:contoso.net include:contoso.org -all

Cuando el servidor de recepción ve este registro en DNS, también realiza una búsqueda DNS en el
registro TXT SPF para contoso.net y, a continuación, en contoso.org. Si encuentra una instrucción
include adicional dentro de los registros para contoso.net o contoso.org, seguirá también los
mismos. Con el fin de ayudar a evitar los ataques por denegación de servicio, el número máximo
de búsquedas DNS para un único mensaje de correo electrónico es 10. Cada instrucción Include
representa una búsqueda DNS adicional. Si un mensaje supera el límite de 10, el mensaje tiene
errores SPF. Una vez que un mensaje alcanza este límite, dependiendo de cómo esté configurado
el servidor de recepción, es posible que el remitente reciba un mensaje que indique que el
mensaje generó "demasiadas búsquedas" o que se ha superado el número de saltos máximo del
mensaje (esto puede ocurrir cuando las búsquedas se repiten y superan el tiempo de espera de
DNS). Para obtener sugerencias sobre cómo evitar esto, consulte solución de problemas:
procedimientos recomendados para SPF en Microsoft 365.

Requisitos para el registro TXT de SPF y Microsoft 365

Si configura el correo cuando configura Microsoft 365, ya ha creado un registro TXT de SPF que
identifica a los servidores de mensajería de Microsoft como un origen de correo legítimo del
dominio. Probablemente, este registro tenga un aspecto similar al siguiente:

v=spf1 include:spf.protection.outlook.com -all

Si usted es un cliente totalmente hospedado, es decir, no tiene ningún servidor de correo local que
envíe correo saliente, este es el único registro TXT SPF que debe publicar para Office 365.

Si tiene una implementación híbrida (es decir, tiene algunos buzones de correo locales y otros
hospedados en Microsoft 365), o si es cliente independiente de Exchange Online Protection (EOP)
(es decir, su organización usa EOP para proteger los buzones de correo locales), debe agregar la
dirección IP saliente para cada uno de los servidores perimetrales locales al registro TXT de SPF en
DNS.

Formar el registro TXT de SPF para Microsoft 365

Use la información de sintaxis de este artículo para formar el registro TXT de SPF para su dominio
personalizado. Aunque existan otras opciones de sintaxis que no se mencionan aquí, estas son las
opciones más usadas. Una vez que haya formado el registro, debe actualizarlo en el registrador de
dominios.

Para obtener información sobre los dominios que tendrá que incluir en Microsoft 365,
consulte external DNS Records required for SPF. Use las instrucciones paso a paso para actualizar
registros SPF (TXT) para el registrador de dominios.
Usar DKIM para validar el correo electrónico saliente enviado
desde su dominio personalizado
Resumen: Este artículo describe cómo usa DomainKeys Identified Mail (DKIM) con Microsoft 365
para asegurarse de que los sistemas de correo electrónico de destino confían en los mensajes
enviados desde su dominio personalizado.

Debería usar DKIM además de SPF y DMARC para ayudarle a evitar que los suplantadores de
identidad envíen mensajes que parece que provienen de su dominio. DKIM le permite agregar una
firma digital a los mensajes de correo electrónico salientes en el encabezado del mensaje. Puede
sonar complicado, pero realmente no lo es. Cuando configura DKIM, autoriza su dominio para
asociar, o firmar, su nombre a un mensaje de correo electrónico mediante la autenticación
criptográfica. Los sistemas de correo electrónico que reciben correo electrónico desde el dominio
pueden usar esta firma digital para ayudarles a determinar si el correo entrante que reciben es
legítimo.

Básicamente, usa una clave privada para cifrar el encabezado del correo electrónico saliente del
dominio. Publica una clave pública en los registros DNS del dominio que los servidores de
recepción pueden usar para descodificar la firma. Usan la clave pública para comprobar que los
mensajes proceden realmente de usted y no de alguien que está suplantando la identidad del
dominio.

Microsoft 365 configura automáticamente DKIM para sus dominios "onmicrosoft.com" iniciales. Lo


que significa que no es necesario realizar ninguna acción para configurar DKIM para un nombre de
dominio inicial (por ejemplo, litware.onmicrosoft.com). Para más información sobre los dominios,
vea Preguntas más frecuentes de dominios.

También puede elegir no hacer nada acerca de DKIM para su dominio personalizado. Si usted no
configura DKIM para su dominio personalizado, Microsoft 365 crea un par de claves privadas y
públicas, que permiten que DKIM firme y configure la directiva predeterminada de Microsoft 365
para su dominio personalizado. Aunque esto suponga una cobertura suficiente para la mayoría de
los clientes, debería configurar manualmente DKIM para su dominio personalizado en las
siguientes circunstancias:

 Tiene más de un dominio personalizado en Microsoft 365

 También va a configurar DMARC (recomendado)

 Quiere tener el control sobre la clave privada

 Quiere personalizar los registros CNAME

 Quiere configurar claves de DKIM para los correos electrónicos que se originen en un
dominio de terceros, por ejemplo, si usa un troyano de envío masivo de correo electrónico
de terceros.

Cómo DKIM funciona mejor que SPF solo para evitar la suplantación de identidad
malintencionada

SPF agrega información a un sobre del mensaje, pero DKIM cifra realmente una firma dentro
del encabezado del mensaje. Cuando reenvía un mensaje, el servidor de reenvío puede quitar
partes de ese sobre del mensaje. Como la firma digital permanece en el mensaje de correo
electrónico porque forma parte del encabezado del correo, DKIM funciona incluso cuando un
mensaje se ha reenviado como se muestra en el siguiente ejemplo.

En este ejemplo, si solo había publicado un registro TXT de SPF en su dominio, el servidor de
correo del destinatario podría haber marcado el correo electrónico como correo no deseado y
generar un resultado de falso positivo. La adición de DKIM en este escenario reduce los informes
de correo no deseado de falso positivo. Debido a que DKIM se basa en la criptografía de clave
pública para autenticar y no solo en las direcciones IP, DKIM se considera una forma mucho más
segura de autenticación que SPF. Se recomienda usar SPF y DKIM, así como DMARC, en la
implementación.
Información esencial: DKIM usa una clave privada para insertar una firma cifrada en los
encabezados del mensaje. El dominio de firma, o el dominio saliente, se inserta como el valor del
campo d= en el encabezado. El dominio de comprobación, o dominio del destinatario, usa
entonces el campo =d para buscar la clave pública desde DNS y autenticar el mensaje. Si el
mensaje se comprueba, supera la comprobación DKIM.

Pasos que necesita seguir para configurar manualmente DKIM

Para configurar DKIM, deberá completar estos pasos:

 Publicar dos registros CNAME para su dominio personalizado en DNS

 Habilitar la firma DKIM para su dominio personalizado

Publicar dos registros CNAME para su dominio personalizado en DNS

Para cada dominio para el que quiera agregar una firma DKIM en DNS, necesita publicar dos
registros CNAME.

Ejecute los siguientes comandos para crear los registros del selector:

New-DkimSigningConfig -DomainName <domain> -Enabled $false

Get-DkimSigningConfig -Identity <domain> | Format-List Selector1CNAME, Selector2CNAME

Use el formato siguiente para los registros CNAME.

Importante: Si es uno de nuestros clientes de GCC High, calcularemos domainGuid de forma


diferente. En lugar de buscar el registro MX para su initialDomain para calcular domainGuid, lo
calculamos directamente desde el dominio personalizado. Por ejemplo, si su dominio
personalizado es "contoso.com", su domainGuid se convierte en "contoso-com", los puntos se
reemplazan por un guión. Por lo tanto, independientemente del registro MX al que señale su
initialDomain, siempre se usará el método anterior para calcular el domainGuid que se usará en
sus registros CNAME.
Donde:

 Para Microsoft 365, los selectores siempre serán "selector1" o "selector2".

 El domainGUID es el mismo que el domainGUID del registro MX personalizado para su


dominio personalizado que aparece antes de mail.protection.outlook.com. Por ejemplo,
en el siguiente registro MX del dominio contoso.com, el domainGUID es contoso-com:

contoso.com. 3600 IN MX 5 contoso-com.mail.protection.outlook.com

 initialDomain es el dominio que usó al registrarse en Microsoft 365. Los dominios iniciales


siempre terminan en onmicrosoft.com. Para obtener información sobre cómo determinar
el dominio inicial, vea Preguntas más frecuentes de dominios.

Por ejemplo, si tiene un dominio inicial de cohovineyardandwinery.onmicrosoft.com y dos


dominios personalizados cohovineyard.com y cohowinery.com, necesitará configurar dos registros
CNAME para cada dominio adicional, un total de cuatro registros CNAME.

Host name: selector1._domainkey

Points to address or value: selector1-cohovineyard-


com._domainkey.cohovineyardandwinery.onmicrosoft.com

TTL: 3600

Host name: selector2._domainkey

Points to address or value: selector2-cohovineyard-


com._domainkey.cohovineyardandwinery.onmicrosoft.com

TTL: 3600

Host name: selector1._domainkey

Points to address or value: selector1-cohowinery-


com._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600

Host name: selector2._domainkey

Points to address or value: selector2-cohowinery-


com._domainkey.cohovineyardandwinery.onmicrosoft.com

TTL: 3600

Nota: Es importante crear el segundo registro, pero solo uno de los selectores puede estar
disponible en el momento de la creación. En esencia, el segundo selector podría apuntar a una
dirección que aún no ha sido creada. Aun así, recomendamos crear el segundo registro CNAME, ya
que la rotación de las teclas será perfecta y no tendrá que hacer ningún paso manual.

Habilitar la firma DKIM para su dominio personalizado

Una vez que haya publicado los registros CNAME en DNS, está preparado para habilitar la firma
DKIM mediante Microsoft 365. Puede hacerlo a través del Centro de administración de Microsoft
365 o mediante PowerShell.

Para habilitar la firma DKIM para su dominio personalizado a través del Centro de
administración

1. Inicie sesión en Microsoft 365 con su cuenta profesional o educativa.

2. Seleccione el icono del iniciador de aplicaciones en la esquina superior izquierda y


elija Administrador.

3. En el panel de navegación inferior izquierdo, expanda Administración y elija Exchange.

4. Vaya a Protección > dkim.

5. Seleccione el dominio para el que quiere habilitar DKIM y, después, en Firmar los
mensajes de este dominio con firmas DKIM, elija Habilitar. Repita este paso para cada
dominio personalizado.

Para confirmar que la firma DKIM está configurada correctamente en Microsoft 365

Espere unos minutos antes de seguir estos pasos para confirmar que ha configurado
correctamente DKIM. Esto proporciona tiempo para que la información DKIM acerca del dominio
se reparta por toda la red.

 Envíe un mensaje desde una cuenta dentro de su dominio habilitado para DKIM en
Microsoft 365 a otra cuenta de correo electrónico como outlook.com o Hotmail.com.
 No use una cuenta de aol.com con fines de prueba. AOL puede omitir la comprobación
DKIM si se supera la comprobación SPF. Esto anulará la prueba.

 Abra el mensaje y observe el encabezado. Las instrucciones para ver el encabezado del
mensaje variarán según el cliente de mensajería. Para obtener instrucciones acerca de
cómo ver los encabezados de los mensajes en Outlook, consulte Ver encabezados de
mensajes de correo electrónico.

El mensaje con firma DKIM contendrá el nombre de host y el dominio que definió cuando publicó
las entradas CNAME. El mensaje tendrá un aspecto similar al de este ejemplo:

Busque el encabezado Authentication-Results. Aunque cada servicio de recepción usa un formato


ligeramente diferente para estampar el correo entrante, el resultado debe incluir algo
como DKIM=pass o DKIM=OK.

Usar DMARC para validar el correo electrónico:

Domain-based Message Authentication, Reporting, and Conformance (DMARC) trabaja con el


marco de directivas de remitente (SPF) y DomainKeys Identified Mail (DKIM) para autenticar a los
remitentes de los correos y garantizar que los sistemas de correo electrónico de destino confíen
en los mensajes enviados desde su dominio.Implementar DMARC con SPF y DKIM ofrece
protección adicional contra el correo electrónico de suplantación de identidad.DMARC permite a
los sistemas que reciben los correos determinar qué hacer con los mensajes enviados desde su
dominio que no superan las comprobaciones SPF o DKIM.

¿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 y especifica dónde se deben enviar los
avisos de devolución si se produce algún problema al entregar el mensaje (por ejemplo, un
aviso de no entrega).Aparece en la zona del sobre de un mensaje de correo electrónico,
aunque su aplicación de correo electrónico no suele mostrarla.A veces, recibe la
denominación 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.Esta dirección identifica al autor del correo electrónico.Es decir, el buzón
de la persona o el sistema responsables de escribir el mensaje.A veces, recibe la
denominación dirección 5322.From.

SPF usa un registro TXT de DNS para proporcionar una lista de direcciones IP de envío autorizadas
en un dominio dado. Normalmente, solo se realizan comprobaciones de SPF en la dirección
5321.MailFrom. Esto significa que la dirección de 5322.From no se autentica al usar solamente
SPF. Esto habilita un escenario donde un usuario puede recibir un mensaje que pasa una
comprobación de SPF, pero tiene una dirección de remitente 5322.From falsificada. Por ejemplo,
veamos esta transcripción de SMTP:

En esta transcripción, las direcciones del remitente son las siguientes:

 Dirección MailFrom (5321.MailFrom): [email protected]

 Dirección From (5322.From): [email protected]


Si configuró SPF, el servidor receptor realiza una comprobación en la dirección MailFrom
[email protected]. Si el mensaje procede de un origen válido para el dominio
phishing.contoso.com, entonces pasa la comprobación de SPF. Como el cliente de correo
electrónico muestra solo la dirección From, el usuario verá que este mensaje procede de
[email protected]. 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 From da 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:[email protected]; ruf=mailto:[email protected]; fo=1"

Microsoft envía sus informes DMARC a Agari, un tercero. Agari recoge y analiza los informes de la
DMARC. Visite el catálogo de MISA para ver más proveedores que ofrecen informes DMARC para
Microsoft 365.

Implementar DMARC para el correo entrante

No hay que hacer nada para configurar DMARC para el correo que se recibe en Microsoft
365. Nosotros nos hemos encargado de todo. 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.

Implementar DMARC para el correo saliente de Microsoft 365

Si usa Microsoft 365, pero no está usando un dominio personalizado (sino el dominio
onmicrosoft.com), solo tiene que configurar o implementar DMARC para la organización. SPF ya
está configurado y Microsoft 365 genera automáticamente una firma DKIM para el correo
saliente. Para más información sobre esta firma, consulte Comportamiento predeterminado para
DKIM y Microsoft 365.

Si tiene un dominio personalizado o usa servidores de Exchange locales aparte de Microsoft 365,
implemente 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

 Paso 2: Configurar SPF para el dominio

 Paso 3: Configurar DKIM para el dominio personalizado

 Paso 4: Formular el registro TXT de DMARC para el dominio

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 servidor de envío esp=reject, EOP marca el mensaje como correo de
suplantación de identidad en lugar de rechazarlo. En otras palabras, para el correo entrante,
Microsoft 365 trata a p=reject y p=quarantine de la misma manera. Los administradores pueden
definir la acción que debe realizarse sobre los mensajes clasificados como suplantación de
identidad dentro de la directiva contra la suplantación de identidad.
Microsoft 365 está configurado así porque algunos mensajes de correo legítimos pueden no
superar las comprobaciones de DMARC. Por ejemplo, un mensaje podría no superar las pruebas
DMARC si se envía a una lista de distribución que luego transmite el mensaje a todos los
participantes de la lista. Si Microsoft 365 rechazara estos mensajes, las personas podrían perder el
correo electrónico legítimo y no habría forma de recuperarlo. Es decir, estos mensajes seguirían
provocando un error en DMARC, pero se marcarían como correo no deseado y no se
rechazarían. Los usuarios que quisieran podrían colocar estos mensajes en la bandeja de entrada a
través de estos métodos:

 Los usuarios pueden agregar los remitentes seguros de manera individual mediante el
cliente de correo electrónico

 Los administradores pueden actualizar las notificaciones de la inteligencia de suplantación


de identidad para permitir la suplantación de 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 la entrada de los mensajes
de esos remitentes determinados.

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 tiene previsto proporcionar soporte a terceros
que proporcionan el sello ARS en el futuro.

También podría gustarte