¿Qué son las etiquetas DMARC?

Los registros DMARC son una combinación de varios mecanismos o etiquetas DMARC que comunican instrucciones específicas a los servidores de recepción de correo electrónico durante la transferencia del mismo. Cada una de estas etiquetas DMARC contiene un valor definido por el propietario del dominio. Hoy vamos a hablar de qué son las etiquetas DMARC y qué significa cada una de ellas. 

Aquí están todas las etiquetas DMARC disponibles que un propietario de dominio puede especificar en su registro DMARC:

Etiqueta DMARC Tipo Valor por defecto Qué significa
v obligatorio La etiqueta v representa la versión del protocolo DMARC y siempre tiene el valor v=DMARC1 
pct opcional 100 Esta etiqueta representa el porcentaje de correos electrónicos a los que se aplica el modo de política. Más información sobre la etiqueta DMARC pct
p obligatorio Esta etiqueta se refiere al modo de la política DMARC. Puede seleccionar entre rechazar, poner en cuarentena y ninguno. Más información sobre qué es la política DMARC para tener claro qué modo seleccionar para su dominio.
sp opcional El modo de política configurado para su dominio principal (p) Especificando la política de subdominio, la etiqueta sp se configura para definir un modo de política para sus subdominios. Obtenga más información sobre la etiqueta sp de DMARC para entender cuándo debe configurarla. 
rua Opcional pero recomendado La etiqueta rua es una etiqueta DMARC opcional que especifica la dirección de correo electrónico o el servidor web donde las organizaciones informantes deben enviar sus Datos rua agregados DMARC. 

Ejemplo: rua=mailto:[email protected];
ruf Opcional pero recomendado Del mismo modo, el mecanismo ruf especifica la dirección a la que el Informe ruf forense DMARC se debe enviar. Actualmente, no todas las organizaciones informantes envían datos forenses. 

Ejemplo: ruf=mailto:[email protected]
para opcional 0 La etiqueta fo se refiere a las opciones disponibles de informes de fallos/forenses que los propietarios de dominios pueden elegir. Si no ha habilitado ruf para su dominio, puede ignorar esto. 

Las opciones disponibles para elegir son: 

0: se le envía un informe de fallo/forense DMARC si su correo electrónico no supera la alineación SPF y DKIM

1: se envía un informe de fallo/forense DMARC cuando su correo electrónico falla la alineación SPF o DKIM

d: se envía un informe de fallo de DKIM si la firma DKIM del correo electrónico no se valida, independientemente de la alineación

s: se envía un informe de fallo SPF si el correo electrónico no supera la evaluación SPF, independientemente de la alineación.
aspf opcional Esta etiqueta DMARC representa el modo de alineación SPF. El valor puede ser estricto(s) o relajado(r)
adkim opcional Del mismo modo, la etiqueta DMARC adkim representa el modo de alineación DKIM, cuyo valor puede ser estricto(s) o relajado(r) 
rf opcional afrf La etiqueta DMARC rf especifica los distintos formatos para la presentación de informes forenses.
ri opcional 86400 La etiqueta ri se refiere al intervalo de tiempo en segundos entre dos informes agregados consecutivos enviados por la organización informante al propietario del dominio.

Para crear un registro para DMARC al instante, utilice nuestro generador de DMARC gratuito. Alternativamente, si tiene un registro existente, compruebe su validez realizando una búsqueda de DMARC.

Regístrese hoy mismo para obtener una prueba gratuita de prueba de DMARC para obtener asesoramiento de expertos sobre cómo proteger su dominio de los spoofers.

/por

¿Qué es la etiqueta pct (porcentaje) en un registro DMARC?

Si usted, como propietario de un dominio, quiere especificar qué hacer con un correo electrónico que falla la autenticación, los registros DMARC pueden ayudarle con eso. Una empresa puede publicar un registro de texto en el DNS y especificar lo que quiere que ocurra con los correos electrónicos que fallan en la alineación de la fuente, determinando si los entrega, los pone en cuarentena o incluso los rechaza directamente. La etiqueta DMARC pct forma parte de este registro e indica al receptor del correo electrónico el porcentaje de mensajes que se verán afectados por esta política.

¿Qué significa pct en DMARC?

Un registro TXT para cualquier protocolo de autenticación de correo electrónico contiene un montón de mecanismos o etiquetas que significan instrucciones dedicadas a los servidores de recepción de correo electrónico. En un registro DMARC, pct es un acrónimo de porcentaje que se incluye para abordar el porcentaje de correos electrónicos a los que se aplica la política DMARC definida por el propietario del dominio.

¿Por qué necesita la etiqueta DMARC pct?

La etiqueta pct es una forma de configurar y probar las políticas DMARC de su dominio que a menudo se pasa por alto, pero que es muy eficaz. Un registro DMARC con una etiqueta de porcentaje se parece a lo siguiente: 

v=DMARC1; p=rechazo; pct=100; rua=mailto:[email protected];

En el registro DNS DMARC mostrado arriba, el porcentaje de correos electrónicos para los que la política de rechazo DMARC es aplicable es del 100%. 

El tiempo que tarda un dominio en pasar de no utilizar DMARC en absoluto, a utilizar la configuración más restrictiva es un periodo de rampa. El objetivo es dar tiempo a los dominios para que se sientan cómodos con su nueva configuración. Para algunas empresas, esto puede llevar varios meses. Es posible que los dominios realicen una actualización instantánea, pero esto es poco habitual debido al riesgo de que se produzcan más errores o reclamaciones. La etiqueta pct se diseñó como una forma de aplicar gradualmente las políticas DMARC para acortar el período de implementación para las empresas en línea. La intención es poder desplegarla para un lote más pequeño de correos electrónicos primero antes de desplegarla completamente a todo el flujo de correo como en el caso que se muestra a continuación: 

v=DMARC1; p=rechazo; pct=50; rua=mailto:[email protected];

En este registro DNS DMARC, la política de rechazo para DMARC se aplica sólo al 50% de los correos electrónicos, mientras que la otra mitad del volumen se somete a una política de cuarentena para DMARC, que es la segunda política más estricta de la línea. 

¿Qué ocurrirá si no incluye una etiqueta pct en su registro DMARC?

Mientras se crea un registro DMARC utilizando un generador de registros DMARCpuede optar por no definir una etiqueta pct y dejar ese criterio vacío. En este caso, la configuración por defecto para pct se establece en 100, lo que significa que su política definida se aplicará a todos sus correos electrónicos. Por lo tanto, si quiere definir una política para todos sus correos electrónicos, una forma más sencilla de hacerlo sería dejar el criterio pct en blanco, como en este ejemplo:

v=DMARC1; p=cuarentena; rua=mailto:[email protected];

Advertencia: Si desea una política reforzada para DMARC, no publique un registro con pct=0

La lógica detrás de esto es simple: si quiere definir una política de rechazo o cuarentena en su registro, esencialmente quiere que la política se aplique a sus correos electrónicos salientes. Establecer su pct a 0 anula su esfuerzo ya que su política es ahora aplicable a cero correos electrónicos. Esto es lo mismo que tener el modo de política establecido en p=none. 

Nota: Para proteger su dominio de los ataques de suplantación de identidad y evitar cualquier posibilidad de que su dominio sea suplantado por los atacantes, la política ideal debería ser DMARC en p=reject; pct=100;

Pase a la aplicación de DMARC de forma segura iniciando su viaje de DMARC con PowerDMARC. Realice una prueba gratuita de prueba de DMARC hoy mismo.

/por

¿Qué es la etiqueta DMARC sp (Política de subdominios)?

El atributo "sp" es la abreviatura de política de subdominio y no es un atributo muy utilizado actualmente. Permite que un dominio especifique que se debe utilizar un registro DMARC diferente para los subdominios del dominio DNS especificado. Para simplificar las cosas, recomendamos que se omita el atributo "sp" en el propio dominio de la organización. Esto conducirá a una política por defecto que evita la suplantación de identidad en los subdominios. Es importante recordar que el comportamiento de los subdominios siempre está determinado por la política organizativa predominante. 

Los subdominios heredan la política del dominio principal a menos que se anule explícitamente mediante un registro de política de subdominio. El atributo "sp" puede anular esta herencia. Si un subdominio tiene un registro DMARC explícito, este registro tendrá prioridad sobre la política DMARC del dominio principal, incluso si el subdominio utiliza la configuración predeterminada de p=none. Por ejemplo, si se define una política DMARC de prioridad 'all', el elemento 'sp' influirá en el procesamiento DMARC en los subdominios no cubiertos por ninguna política específica.

¿Por qué necesita la etiqueta DMARC sp?

Si tiene su registro DMARC como: 

v=DMARC1; p=reject; sp=none; rua=mailto:[email protected];

En este caso, mientras que su dominio raíz está protegido contra los ataques de suplantación, sus subdominios, aunque no los utilice para intercambiar información, seguirían siendo vulnerables a los ataques de suplantación.

Si tiene su registro DMARC como: 

v=DMARC1; p=none; sp=reject; rua=mailto:[email protected];

En este caso, si bien no se compromete a una política de rechazo en el dominio raíz que utiliza para enviar sus correos electrónicos, sus subdominios inactivos siguen estando protegidos contra la suplantación. 

Si quieres que las políticas de tu dominio y subdominio sean las mismas, puedes dejar el criterio de la etiqueta sp en blanco o desactivado al crear un registro, y tus subdominios heredarán automáticamente la política impuesta al dominio principal. 

Si utiliza nuestro generador de registros DMARC para crear un registro DMARC para su dominio, debe activar manualmente el botón de política de subdominio y definir la política deseada, como se muestra a continuación:

 

Después de crear su registro DMARC es importante comprobar la validez de su registro utilizando nuestra herramienta de búsqueda de registros DMARC para asegurarse de que su registro no tiene errores y es válido.

Comience su viaje de DMARC con PowerDMARC para maximizar la seguridad del correo electrónico de su dominio. Tome su prueba gratuita de prueba de DMARC hoy mismo.

/por

¿Cómo actualizar sus claves DKIM (de 1024 bits a 2048 bits) para Microsoft Office 365 Exchange Online?

Debido a las amenazas que acechan en Internet, las empresas deben demostrar que son legítimas empleando métodos de autenticación sólidos. Un método común es a través de DomainKeys Identified Mail (DKIM), una tecnología de autenticación de correo electrónico que utiliza claves de cifrado para verificar el dominio del remitente. DKIM, junto con SPF y DMARC ha mejorado drásticamente la postura de seguridad del correo electrónico de las organizaciones en todo el mundo.

Más información sobre qué es DKIM.

Al configurar DKIM para sus correos electrónicos, una de las principales decisiones que debe tomar es determinar la longitud de la clave DKIM. En este artículo, le mostraremos la longitud de clave recomendada para una mejor protección y cómo actualizar sus claves en Exchange Online Powershell.

Importancia de actualizar la longitud de su clave DKIM

La elección de 1024 bits o 2048 bits es una decisión importante que debe tomarse al elegir su clave DKIM. Durante años, la PKI (infraestructura de clave pública) ha utilizado claves DKIM de 1024 bits para su seguridad. Sin embargo, a medida que la tecnología se vuelve más compleja, los hackers se esfuerzan por encontrar nuevos métodos para paralizar la seguridad. Por ello, la longitud de las claves es cada vez más importante.

A medida que los hackers siguen inventando mejores formas de romper las claves DKIM. La longitud de la clave está directamente correlacionada con la dificultad de romper la autenticación. El uso de una clave de 2048 bits proporciona una mayor protección y una mejor seguridad contra los ataques actuales y futuros, lo que pone de manifiesto la importancia de actualizar su longitud de bits.

Actualización manual de sus claves DKIM en Exchange Online Powershell

  • Comience por conectarse a Microsoft Office 365 PowerShell como administrador (asegúrese de que su cuenta de Powershell está configurada para ejecutar scripts de Powershell firmados)
  • En caso de que DKIM esté preconfigurado, para actualizar sus claves a 2048 bits ejecute el siguiente comando en Powershell: 

Rotate-DkimSigningConfig -KeySize 2048 -Identity {Guid del Signing Config existente}

  • En caso de que no haya implementado DKIM previamente, ejecute el siguiente comando en Powershell: 

New-DkimSigningConfig -DomainName <Domain for which config is to be created> -KeySize 2048 -Enabled $true

  • Por último, para verificar que ha configurado correctamente DKIM con un bitness actualizado de 2048 bits, ejecute el siguiente comando:

Get-DkimSigningConfig -Identity <Domain for which the configuration was set> | Format-List

Nota: Asegúrese de estar conectado a Powershell durante la realización del procedimiento. Los cambios pueden tardar hasta 72 horas en implementarse.

DKIM no es suficiente para proteger su dominio contra el spoofing y el BEC. Mejore la seguridad del correo electrónico de su dominio configurando DMARC para office 365.

/por

Informes agregados de Microsoft DMARC

El tan esperado despliegue por fin está aquí! Microsoft está enviando informes agregados DMARC RUA a sus usuarios y es probable que no lo hayas notado. Los informes agregados DMARC de Microsoft se envían desde la siguiente dirección de correo electrónico: [email protected]. El archivo agregado DMARC de Microsoft en bruto se envía en formato XML estándar. Microsoft ha adoptado finalmente los informes DMARC, lo que significa esencialmente que ahora los usuarios de Hotmail, Outlook, Live y msn.com podrán disfrutar de las diversas ventajas de los datos agregados DMARC de Microsoft.

Procesamiento de datos agregados de Microsoft DMARC

El analizador de informes PowerDMARC analiza los datos agregados de Microsoft DMARC en un formato organizado que le ayudará a procesarlos de forma más eficiente.  

Para ayudar a los usuarios a aprovechar las ventajas de los datos de informes agregados enviados por Microsoft, el analizador de informes DMARC ha sido preconfigurado para recibir sus informes directamente en la plataforma. Todo lo que tienen que hacer los usuarios es añadir sus dominios en la plataforma PowerDMARC junto con la configuración del registro DNS DMARC, mientras nosotros procesamos y presentamos los informes de forma fácil y comprensible. Aquí encontrará:

  • Datos agregados de DMARC enviados desde direcciones de destinatarios de Hotmail, Outlook, Live y msn.com analizados desde el formato de archivo XML sin procesar en información sencilla y legible organizada en tablas
  • PowerDMARC está preconfigurado para evitar las violaciones de la RFC, lo que nos permite recibir y analizar los datos DMARC enviados por los servidores de Microsoft sin que usted tenga que preocuparse por ello
  • Registre varios dominios, supervise sus canales de correo electrónico y realice cambios de DNS directamente desde el panel de control con botones de acción al alcance de su mano
  • Filtrar los resultados en categorías variadas como por resultado, por fuente de envío, por organización, por país, geolocalización y estadísticas detalladas o resultados de búsqueda por dominio en la barra de búsqueda
  • Obtenga una visión más profunda del rendimiento de sus correos electrónicos y detecte rápidamente los intentos de suplantación de dominio, suplantación de identidad o correos electrónicos falsos que se envían utilizando sus dominios empresariales de Microsoft. También podrá analizar cualquier fallo de SPF, DKIM de sus fuentes de envío.

Arriba se muestra una captura de pantalla de nuestros informes agregados de DMARC por organización que muestran los datos de DMARC RUA enviados desde Microsoft.

Problemas que puede encontrar al manejar los informes agregados de Microsoft DMARC por su cuenta

Los correos electrónicos agregados de Microsoft DMARC no son compatibles con RFC

El principal problema al que se han enfrentado los usuarios con estos correos electrónicos que contienen informes enviados por Microsoft es que no se ajustan a las especificaciones RFC para los correos electrónicos de Internet. Mientras que el capítulo 2.1.1 del RFC 5322 establece claramente que una línea de caracteres no debe exceder los 78 caracteres, los datos adjuntos BASE64 en estos correos electrónicos agregados de Microsoft DMARC son una línea continua sin saltos de línea adecuados que exceden el límite de 78 caracteres. La violación resultante de la RFC es la razón por la que la mayoría de estos correos electrónicos están aterrizando en el registro de rechazo del usuario en lugar de ser entregados a su bandeja de entrada. 

Los archivos XML en bruto son difíciles de leer

Al igual que los datos DMARC enviados por todas las organizaciones informantes, el archivo RUA en bruto está en lenguaje de marcado extensible (XML) que es difícil de leer y comprender.

Requisitos previos para recibir Microsoft DMARC RUA

Para recibir informes agregados de sus dominios en outlook.com, debe asegurarse de que tiene un registro PowerDMARC válido publicado en su DNS, junto con una política DMARC definida. Las organizaciones de informes enviarán entonces los datos de los informes agregados a su servidor web o dirección de correo electrónico especificados. Esto le ayudará a obtener visibilidad y cumplimiento de DMARC en sus proveedores de correo electrónico de terceros, sobre los que de otro modo no tendría control. 

Proteja sus dominios en Microsoft Office365 y otros comenzando su viaje de autenticación de correo electrónico hoy mismo. Súbase a bordo con una prueba gratuita de prueba de DMARC o programe una demostración de demostración de DMARCy explore los beneficios de implementar una postura de seguridad de correo electrónico sólida en su organización.

/por

¿Cómo se soluciona el problema de "falta la política MTA-STS"?

En caso de que se haya encontrado con la "Falta la política MTA-STS: STSFetchResult.NONE "al utilizar herramientas en línea, ha llegado al lugar correcto. Hoy vamos a discutir cómo arreglar este mensaje de error y deshacerse de él mediante la incorporación de una política MTA-STS para su dominio.

El Protocolo Simple de Transferencia de Correo, también conocido como SMTP, es el protocolo estándar de transferencia de correo electrónico utilizado por la mayoría de los proveedores de servicios de correo electrónico. No es un concepto extraño que SMTP se haya enfrentado a retos de seguridad desde los albores del tiempo, retos que aún no han podido superar. Esto se debe a que, para hacer que los correos electrónicos sean compatibles con el pasado, SMTP introdujo el cifrado oportunista en forma de comando STARTTLS. Esto significa esencialmente que, en caso de que no se pueda negociar una conexión cifrada entre dos servidores SMTP en comunicación, la conexión se revierte a una sin cifrar, y los mensajes se envían en texto claro. 

Esto hace que los correos electrónicos transferidos a través de SMTP sean vulnerables a la vigilancia generalizada y a los ataques de espionaje cibernético como el Man-in-the-middle. Esto supone un riesgo tanto para el remitente como para el destinatario y puede conducir a la violación de datos sensibles. Aquí es donde el MTA-STS entra en acción y hace que el cifrado TLS sea obligatorio en SMTP para evitar que los correos electrónicos se entreguen a través de conexiones no seguras. 

¿Qué es una política MTA-STS?

Para mejorar la seguridad de su correo electrónico SMTP y sacar el máximo provecho de los protocolos de autenticación como el MTA-STS, el servidor de envío debe tener soporte para el protocolo y el servidor de recepción de correo electrónico debe tener una política MTA-STS definida en su DNS. También se recomienda un modo de política forzada para ampliar aún más los estándares de seguridad. La política MTA-STS define los servidores de correo electrónico que utilizan MTA-STS en el dominio del receptor. 

Para habilitar MTA-STS para su dominio como receptor de correo electrónico, necesita alojar un archivo de política MTA-STS en su DNS. Esto permite que los remitentes de correo electrónico externos envíen correos electrónicos a su dominio que estén autenticados y cifrados con TLS con una versión actualizada de TLS (1.2 o superior). 

No tener un archivo de política publicado o actualizado para su dominio puede ser la razón principal para encontrarse con mensajes de error como "Falta la política MTA-STS: STSFetchResult.NONE", lo que implica que el servidor del remitente no pudo obtener el archivo de política MTA-STS cuando consultó el DNS del receptor, encontrando que faltaba.

Requisitos previos para el MTA-STS:

Los servidores de correo electrónico para los que se habilitará el MTA-STS deben utilizar una versión de TLS de 1.2 o superior, y deben tener certificados TLS que se adhieran a las normas y especificaciones RFC actuales, que no hayan caducado y que los certificados del servidor estén firmados por una autoridad certificadora raíz de confianza.

Pasos para arreglar "Falta la política MTA-STS"

1. Creación y publicación de un registro TXT de DNS MTA-STS 

El primer paso es crear un registro MTA-STS para su dominio. Puedes crear un registro al instante utilizando un generador de registros MTA-STS, que te proporcionará un registro DNS a medida para tu dominio. 

2. Definición de un modo de política MTA-STS

MTA-STS ofrece dos modos de política para que los usuarios trabajen.

  • Modo de prueba: Este modo es ideal para los principiantes que no han configurado el protocolo antes. El modo de prueba MTA-STS le permite recibir informes SMTP TLS sobre problemas en las políticas MTA-STS, problemas en el establecimiento de conexiones SMTP cifradas o fallos en la entrega del correo electrónico. Esto le ayuda a responder a los problemas de seguridad existentes en sus dominios y servidores sin necesidad de aplicar el cifrado TLS.
  • Modo de aplicación: Mientras siga recibiendo sus informes de TLS, con el tiempo es óptimo que los usuarios apliquen su política de MTA-STS para que el cifrado sea obligatorio al recibir correos electrónicos mediante SMTP. Esto evita que los mensajes sean modificados o manipulados mientras están en tránsito.

3. Creación del archivo de política MTA-STS

El siguiente paso es alojar los archivos de políticas MTA-STS para sus dominios. Tenga en cuenta que, aunque el contenido de cada archivo puede ser el mismo, es obligatorio alojar las políticas por separado para los distintos dominios, y un único dominio sólo puede tener un único archivo de política MTA-STS. Si se alojan varios archivos de políticas MTA-STS para un mismo dominio, pueden producirse errores de configuración del protocolo. 

El formato estándar de un archivo de política MTA-STS es el siguiente: 

Nombre del archivo: mta-sts.txt

Tamaño máximo del archivo: 64 KB

versión: STSv1

modo: prueba

mx: mail.sudominio.com

mx: *.sudominio.com

max_age: 806400 

Nota: El archivo de política mostrado arriba es simplemente un ejemplo.

4. Publicación de su archivo de política MTA-STS

A continuación, tiene que publicar su archivo de política MTA-STS en un servidor web público al que puedan acceder servidores externos. Asegúrese de que el servidor en el que aloja su archivo soporta HTTPS o SSL. El procedimiento para ello es sencillo. Asumiendo que su dominio está preconfigurado con un servidor web público:

  • Añada un subdominio a su dominio existente que debe comenzar con el texto: mta-sts (por ejemplo, mta-sts.dominio.com) 
  • Su archivo de política apuntará a este subdominio que ha creado y tiene que ser almacenado en un archivo .well-known
  • La URL del archivo de políticas se añade a la entrada DNS al publicar su registro DNS MTA-STS para que el servidor pueda consultar el DNS para obtener el archivo de políticas durante la transferencia del correo electrónico

5. Activar MTA-STS y TLS-RPT

Por último, debe publicar su MTA-STS y TLS-RPT en el DNS de su dominio, utilizando TXT como tipo de recurso, colocados en dos subdominios separados (_smtp._tls y _mta-sts). Esto permitirá que sólo lleguen a su bandeja de entrada mensajes encriptados por TLS, verificados y no manipulados. Además, recibirá informes diarios sobre los problemas de entrega y encriptación en una dirección de correo electrónico o servidor web configurado por usted, desde servidores externos.

Puede verificar la validez de sus registros DNS realizando una búsqueda de registros MTA-STS después de que su registro sea publicado y esté activo.  

Nota: Cada vez que realice modificaciones en el contenido de sus archivos de política MTA-STS, deberá actualizarlo tanto en el servidor web público en el que aloja su archivo como en la entrada DNS que contiene la URL de su política. Lo mismo ocurre cada vez que actualice o añada dominios o servidores.

¿Cómo pueden ayudar los servicios MTA-STS alojados a resolver el problema de "falta la política MTA-STS"?

La implementación manual del MTA-STS puede ser ardua y desafiante y dejar espacio para los errores. El MTA-STS alojado de PowerDMARC MTA-STS alojados de PowerDMARC ayudan a catapultar el proceso para los propietarios de dominios, haciendo que la implementación del protocolo sea rápida y sin esfuerzo. Usted puede:

  • Publique sus registros CNAME para MTA-STS con unos pocos clics
  • Subcontratar el trabajo duro que supone el mantenimiento y el alojamiento de los archivos de políticas MTA-STS y los servidores web
  • Cambie su modo de política siempre que lo desee, directamente desde su panel de control personalizado, sin tener que acceder a sus DNS
  • Mostramos los archivos JSON de los informes TLS de SMTP en un formato organizado y legible para el ser humano, que resulta cómodo y comprensible tanto para los técnicos como para los no técnicos

¿Y lo mejor? Cumplimos con el RFC y soportamos los últimos estándares TLS. Esto le ayuda a comenzar con la configuración de MTA-STS sin errores para su dominio, y a disfrutar de sus beneficios mientras deja que nosotros nos encarguemos de las molestias y complejidades en su nombre. 

Espero que este artículo le haya ayudado a deshacerse del aviso "Falta la política MTA-STS: STSFetchResult.NONE", y a configurar los protocolos adecuadamente para su dominio para mitigar las lagunas y los desafíos en la seguridad SMTP. 

Habilite hoy mismo el MTA-STS para sus correos electrónicos realizando una prueba gratuita de autenticación de correo electrónico DMARC de pruebapara mejorar sus defensas contra MITM y otros ataques de espionaje cibernético.

/por