Tras el primer artículo en el que os contaba cómo mejorar la seguridad del correo electrónico, toca ponernos manos a la obra con la configuración de SPF, DMARC y DKIM
Como decía en el primer artículo, configurar SPF no sería necesario, ya que viene en los registros por defecto. Además, no requiere configurar nada en Microsoft 365, solo en el panel de control de nuestro dominio.
Hay 2 formas de saber si tenemos configurado SPF, la primera revisando los registros de nuestro portal DNS:
O en cualquiera de las diversas webs de herramientas de revisión que existen, en mi caso suelo usar MXTOOLBOX, la cual es gratuita en las consultas básicas: https://mxtoolbox.com/
El cual indica que está habilitado. Por lo tanto, todo correcto.
Si no estuviese habilitado y nuestro servidor pertenece a Microsoft 365, solo deberíamos crear el registro deseado o agregar a nuestro portal DNS el registro TXT con este valor:
v=spf1 include:spf.protection.outlook.com -all
Los pasos para agregar este registro dependen del portal DNS contratado, por que prácticamente cada proveedor tiene portal personalizado y por lo tanto se configura con distintos pasos. Por ejemplo, en nuestro portal es así:
¿Que hemos configurado?:
v=: define la versión usada de SPF (versión 1).
Include: es la dirección válida, aquí podemos agregar más de una.
~all sugiere desautorización a las máquinas que no encajen en lo autorizado explícitamente.
Con este registro estaríamos informando al resto de los servidores de correo que solo enviamos correos válidos desde Office 365, y que cualquier correo que no tenga ese origen, no es legítimo. Ojo si tenemos proveedores de Mailings externos como por ejemplo mailchimp, tendremos que agregarlos.
En caso de que nuestro Servidor de correo no se encuentre en Microsoft 365, tengamos otro enviador válido, o simplemente queramos reforzar la seguridad, hay bastantes parámetros que podemos agregar o modificar
Configurar SPF para ayudar a evitar la suplantación de identidad – Office 365 | Microsoft Docs
Incluso podemos usar algunas webs gratuitas que nos ayudan a configurarlo:
La configuración de DMARC, es casi idéntica en los pasos a realizar, solo cambia el contenido del registro TXT, por lo tanto, solo requiere de configuración en nuestro portal DNS.
Para configurar DMARC debemos agregar un registro TXT en nuestro portal DNS el cual debemos de “construir” nosotros previamente. Este es el más usado para Microsoft 365 y el que podemos encontrar en la página oficial:
_dmarc.domain TTL IN TXT «v=DMARC1; p=policy; pct=100»
A este registro solo debemos cambiar la palabra domain, por nuestro dominio y configurar algunos parametros.
_dmarc.jmcastillo.eu 3600 IN TXT «v=DMARC1; p=reject»
Para configurarlo solo debemos agregar un registro Tipo TXT a nuestro portal DNS:
Y con eso ya estaría configurado.
¿Que hemos configurado?:
Para recibir informes de error con DMARC, se utiliza la etiqueta «ruf». Esta etiqueta actúa de manera similar a la etiqueta «rua» (que envía informes agregados de DMARC) en que se especifica la dirección de correo electrónico o las direcciones de correo electrónico a las que enviar informes de error.
Esta etiqueta tiene el formato de una lista separada por comas de direcciones «mailto:». Por ejemplo, si deseas recibir informes de errores en el buzón «dmarc-failures@jmcastillo.eu», debes establecer la etiqueta «ruf» en ruf=»mailto:dmarc-failures@jmcastillo.eu». Si deseas que los informes vayan a varios correos electrónicos o a un procesador de informes DMARC, la etiqueta se vería así: ruf=»mailto:dmarc-failures@jmcastillo.eu», mailto:dmarc-failures@jmcastillo.eu
Para rua, quedaría de forma similar: rua=»mailto:dmarc-data@jmcastillo.eu», mailto:dmarc-data@jmcastillo.eu
Si publica una directiva de rechazo de DMARC (p=reject), ningún otro cliente de Office 365 podrá suplantar la identidad del 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 puede ser marcado como correo no deseado (como se describió anteriormente) 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.
Al contrario de los registros anteriores, este si que requiere de configuración en el portal de Microsoft 365.
Lo primero que debemos hacer es revisar si DKIM está configurado ya en nuestro entorno, para ello nos dirigimos al centro de administración de Microsoft 365, en el apartado seguridad y complimiento y en administración de amenazas pichamos en directivas:
Pinchamos en DKIM y vemos el estado:
Eso significa que no está activado.
Como prerequisito para configurar DKIM, recordad que debemos tener el módulo powershell EXO v2 instalado en la máquina desde la que conectemos a Exchange online:
Si no es así, debemos seguir los pasos desde este artículo de Microsoft: Conexión a Exchange Online PowerShell | Microsoft Docs
Una vez conectados, lo primero que tendremos que hacer (después de iniciar sesión) es ejecutar el siguiente comando:
New-DkimSigningConfig -DomainName <Nombre del dominio> -KeySize 2048 -Enabled $true
Tras esperar unos segundos, la respuesta del comando debe ser:
Es lógica la respuesta que nos devuelve. Aún no conocíamos los registros CNAME, así que hemos creado la configuración, pero no se ha habilitado.
**Nota para usuarios más experimentados: El registro CNAME es fácil de construir ya que solo varíaa el nombre del dominio. Si sabemos cómo construirlo y primero generamos el registro CNAME en el panel DNS, tras este comando quedará creado y habilitado.
Mientras, en portal Microsoft 365 el estado de DKIM ya ha cambiado y confirma que está creado, pero no habilitado:
Tras este paso, debemos ir al panel de control de nuestro DNS y crear 2 registros CNAME con los valores que nos devolvió powershell:
selector1-jmcastillo-eu._domainkey.jmcastillogarcia.onmicrosoft.com
selector2-jmcastillo-eu._domainkey.jmcastillogarcia.onmicrosoft.com
Así es en nuestro portal:
Resultando:
Tras ello tenemos 2 vías de activación: por el portal, o por powershell.
Por el portal de Microsoft 365, debemos volver a la política y activar el check
Y si todo ha ido bien, aparece este mensaje.
Por powershell debemos introducir este comando:
Set-DkimSigningConfig -Identity jmcastillo.eu -Enabled $true
Con estos pasos, hemos mejorado la seguridad en el tráfico de correo y hemos mejorado la experiencia de los usuarios y la confiabilidad en el uso del correo.
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)