Subsecciones de las tendencias del correo electrónico
Directrices de AUTENTICACIÓN de correo electrónico

¡¡ATENCIÓN!! Este documento ha sido traducido automáticamente del italiano
Pautas
Configuración del servicio de correo electrónico para la autenticación
La Agencia Nacional Italiana de Ciberseguridad ha publicado las Directrices para la configuración del servicio de correo electrónico para la autenticación, con el objetivo de reforzar la fiabilidad del servicio de correo electrónico para todas las organizaciones interesadas y aumentar su nivel general de seguridad.
Control de versiones
| VERSIÓN |
FECHA DE PUBLICACIÓN |
NOTAS |
| 1.0 |
Abril de 2026 |
Primera publicación. |
ÍNDICE
1. Introducción
1.1. Premisa
El correo electrónico representa hoy en día uno de los servicios más críticos en el contexto digital, ya que se encuentra entre los principales canales utilizados por organizaciones y usuarios para la comunicación y el intercambio de información.
El funcionamiento del servicio de correo electrónico, y en particular la transmisión de mensajes, se basa en el protocolo SMTP, que, sin embargo, no incorpora de forma nativa mecanismos adecuados para la autenticación del remitente ni para la protección de la confidencialidad e integridad de los mensajes. Estas vulnerabilidades lo exponen al riesgo de ataques como la suplantación de identidad, el phishing, la manipulación y la interceptación de mensajes durante su transmisión.
Para mitigar las debilidades del protocolo SMTP y, por lo tanto, reducir el riesgo derivado de los ataques mencionados, con el tiempo se han desarrollado mecanismos para la autenticación del remitente y la protección de la integridad del mensaje, como SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) y DMARC (Domain-based Message Authentication, Reporting and Conformance).
Estas directrices ilustran estos mecanismos con el objetivo de reforzar la fiabilidad del servicio de correo electrónico y aumentar su nivel general de seguridad, con especial referencia a las amenazas descritas en el Capítulo 4.
Las contramedidas y los protocolos necesarios para proteger la confidencialidad de los mensajes de correo electrónico (como S/MIME y OpenPGP, que se refieren al cifrado de mensajes) no son objeto de estas directrices.
1.2. Reglamento de Referencia
1.3. Documentos de referencia
» Volver arriba
2. Contexto regulatorio
Para proteger los activos digitales del país, incluidos los servicios de correo electrónico y las infraestructuras que los alojan, se ha implementado un amplio conjunto de medidas de seguridad derivadas de la legislación vigente y sujetas a actualizaciones constantes.
El máximo nivel de protección para los servicios más críticos del país, vinculados a la protección de la seguridad nacional, está garantizado por el Perímetro Nacional de Ciberseguridad, establecido por el Decreto Ley n.º 105, de 21 de septiembre de 2019, modificado por la Ley n.º 133, de 18 de noviembre de 2019. Este perímetro proporciona medidas de seguridad con niveles de protección particularmente altos, detallados en el Anexo B del Decreto del Primer Ministro n.º 81, de 14 de abril de 2021, que se aplican a las redes, sistemas de información y servicios de TI de entidades públicas y privadas de las que depende el ejercicio de una función esencial del Estado o la prestación de un servicio esencial para el mantenimiento de las actividades civiles, sociales o económicas fundamentales para los intereses del Estado, cuyo compromiso podría resultar en perjuicio de la seguridad nacional.
Además, los servicios de correo electrónico, al igual que todos los servicios digitales de la administración pública, están sujetos a las disposiciones del Reglamento sobre la Nube, adoptado en virtud del artículo 33-septies del Decreto Ley n.º 179, de 18 de octubre de 2012, y actualizado por la Agencia Nacional de Ciberseguridad (ACN) mediante el Decreto Directorial n.º 21007, de 27 de junio de 2024. Conforme a dicho Reglamento, todas las administraciones públicas deben clasificar sus datos y servicios digitales como ordinarios, críticos o estratégicos, según el modelo elaborado por la ACN. Esta actividad tiene como objetivo garantizar que los datos y servicios digitales de la administración pública se procesen y presten a través de infraestructuras digitales y servicios en la nube que cumplan con los requisitos, incluidos los de seguridad, adecuados a los riesgos asociados al nivel de clasificación correspondiente, tal como se detalla en el Reglamento.
El Decreto Legislativo n.º 138 de 4 de septiembre de 2024 (el denominado Decreto NIS), que transpone la Directiva (UE) 2022/2555, también estableció, mediante los Anexos 1 y 2 de la Determinación ACN 379907/2025, las medidas básicas de seguridad que las entidades esenciales e importantes deben adoptar a efectos de las obligaciones establecidas en los artículos 23 y 24 del Decreto NIS, definiendo un marco de seguridad para reforzar la protección de las redes y los sistemas de información, incluidos los servicios de correo electrónico.
» Volver arriba
3. Arquitectura del servicio de correo electrónico
Como se indica en la premisa, el funcionamiento del servicio de correo electrónico se basa en el protocolo SMTP, que regula la transmisión de mensajes de correo electrónico desde el remitente al destinatario.
El protocolo SMTP se definió originalmente en 1982 como un protocolo de almacenamiento y reenvío, en el que el remitente genera un mensaje a través de su cliente de correo, en la jerga Agente de Usuario de Correo (MUA), que lo envía al servidor de correo del remitente. Este, a través de un componente llamado Agente de Transferencia de Correo (MTA), reenvía el mensaje, posiblemente también a través de uno o más MTA intermedios, entregándolo al MTA del servidor de correo de destino. El usuario receptor accede al mensaje a través de su cliente de correo (MUA)[1].
Por lo tanto, el MTA es un componente del servicio de correo electrónico que gestiona la transmisión de mensajes desde el remitente al destinatario. Los componentes del MTA están presentes en los servidores de correo del remitente y del destinatario, y también se pueden configurar MTA intermedios, por ejemplo, para gestionar listas de distribución.

Figura 1. Arquitectura de alto nivel del servicio de correo electrónico.
La figura representa únicamente los componentes de interés para estas directrices.
Aunque el término MTA identifica un componente específico de los servidores de correo electrónico, dado que para los fines de este documento se hace referencia a estos últimos principalmente en su función como MTA, donde no hay ambigüedad, para simplificar la exposición se utilizará a menudo el término servidor de correo electrónico en lugar del más específico MTA.
En esta guía nos centramos en la configuración de los protocolos SPF, DKIM y DMARC para permitir que los servidores de correo verifiquen la autenticidad e integridad de los mensajes de correo electrónico.
» Volver arriba
4. Amenazas
El protocolo SMTP presentado en el capítulo anterior fue diseñado inicialmente para operar en una red académica relativamente pequeña y no tuvo en cuenta aspectos relacionados con la seguridad de los mensajes transmitidos ni la autenticación del remitente [1].
La creciente difusión del correo electrónico y las debilidades intrínsecas del protocolo SMTP han favorecido, con el tiempo, la aparición de ataques cuyos principales tipos se ilustran brevemente en los siguientes párrafos.
4.1. Suplantación de identidad del remitente
El spoofing es una técnica de ciberataque que se utiliza para falsificar la dirección del remitente de un mensaje y hacer que parezca provenir de una dirección fiable (como, por ejemplo, la de un compañero de trabajo, un conocido o la de la propia entidad bancaria), induciendo al destinatario a realizar acciones potencialmente peligrosas, como, por ejemplo, abrir un archivo adjunto de correo electrónico o hacer clic en los enlaces que contiene el mensaje.
Este tipo de ataque es relativamente sencillo de llevar a cabo, ya que el protocolo SMTP no incluye mecanismos de autenticación del remitente y, por lo tanto, a través del cliente de correo electrónico es posible configurar cualquier dirección de remitente al originar el mensaje.
Dirección de correo electrónico del remitente: envelope-from y message-from
El formato del mensaje de correo electrónico prevé dos campos distintos para indicar la dirección de correo electrónico del remitente. Estos campos se denominan envelope-from y message-from: el primero (también conocido como return-path, ya que especifica la dirección de correo electrónico a la que deben enviarse los mensajes de error generados cuando un correo electrónico no llega al destinatario) es la dirección que se utiliza para enrutar correctamente el mensaje; el segundo es la dirección que el destinatario ve en el encabezado del mensaje recibido.
Haciendo una analogía con el envío de una carta dentro de un sobre por correo tradicional, el campo "sobre-de" representa la dirección del remitente que aparece en el sobre de la carta, mientras que el campo "mensaje-de" corresponde al encabezado presente en la carta que indica quién escribió al destinatario.
Es importante tener en cuenta que las dos direcciones pueden no coincidir. Esta distinción permite gestionar situaciones como, por ejemplo, el reenvío de mensajes de servicios de terceros, la distribución a través de listas de correo o las respuestas automáticas por correo electrónico.
De hecho, es posible indicar cualquier remitente tanto a nivel del remitente del mensaje (la dirección de correo electrónico del remitente que muestra el destinatario en el encabezado del mensaje recibido) como del remitente del sobre (la dirección de correo electrónico del remitente utilizada para la transmisión del mensaje).
Para contrarrestar estas amenazas, resulta esencial proporcionar mecanismos que permitan autenticar de forma fiable al remitente y verificar que la persona que envió el mensaje está realmente autorizada para hacerlo.
4.2. Suplantación de identidad (Phishing)
El phishing es una técnica de ataque cibernético destinada a la adquisición fraudulenta de información (como, por ejemplo, credenciales de inicio de sesión, números de tarjetas de crédito u otros datos confidenciales), generalmente mediante el envío de mensajes engañosos que simulan provenir de remitentes confiables.
La suplantación de identidad, analizada en el párrafo anterior, es una de las principales técnicas que utiliza un atacante para falsificar la identidad del remitente y hacer que el mensaje parezca provenir de un usuario o dominio legítimo.
Como alternativa, se puede utilizar una dirección/dominio del remitente similar a uno reconocible por el destinatario, modificando, por ejemplo, el llamado nombre para mostrar para reforzar la autenticidad aparente del mensaje.
Para enviar mensajes de phishing, también se pueden utilizar cuentas legítimas que hayan sido previamente comprometidas por el atacante.
Un mensaje de phishing suele tener un contenido diseñado para generar urgencia, alarma o interés económico en el destinatario, creando situaciones que lo inducen a reaccionar impulsivamente y realizar acciones específicas, como abrir archivos adjuntos maliciosos o hacer clic en enlaces que redirigen a sitios web aparentemente legítimos, pero que en realidad han sido creados por el atacante con el objetivo de robar información o instalar software malicioso.
Por lo general, los ataques de phishing se llevan a cabo enviando el mismo mensaje de correo electrónico a un gran número de víctimas, sin adaptar el texto al perfil específico de cada una de ellas.
Una variante del phishing es el llamado spear phishing, en el que el atacante conoce el perfil de la víctima y lo ataca específicamente.
A diferencia de un correo electrónico de phishing genérico, un mensaje de spear phishing utiliza información contextual más precisa para convencer al usuario de que está interactuando con un remitente confiable [2].
4.3. Manipulación de mensajes
El contenido de un mensaje de correo electrónico, al igual que cualquier otra comunicación que viaje a través de la red de Internet y que no utilice técnicas de cifrado de extremo a extremo (E2EE), puede ser interceptado y modificado durante la transmisión entre el remitente y el destinatario (un tipo de amenaza comúnmente denominada ataque de intermediario).
En consecuencia, además de la pérdida de confidencialidad, el mensaje recibido podría no corresponderse con el que fue redactado originalmente por el remitente.
Un atacante podría, por ejemplo, manipular el contenido del mensaje para que parezca provenir de un remitente fiable, modificar el texto o cualquier enlace o archivo adjunto presente en el mensaje, o insertar código malicioso.
El destinatario, confiando en la aparente autenticidad del mensaje, puede ser inducido a realizar acciones potencialmente dañinas, como comunicar credenciales de inicio de sesión, autorizar pagos o abrir archivos maliciosos.
Para contrarrestar estas amenazas, resulta fundamental adoptar mecanismos que garanticen la integridad y autenticidad del mensaje, asegurando que el contenido recibido no haya sido modificado y que el remitente sea realmente quien dice ser.
» Volver arriba
5. Contramedidas
El capítulo 2 repasó la normativa que establece medidas de seguridad para la protección de los servicios de correo electrónico. Este documento tiene como objetivo principal servir de guía para la implementación de las medidas de seguridad previstas en dicha normativa y recogidas en el Anexo A, las cuales también son relevantes para la configuración de los servicios de correo electrónico, con el fin de mitigar los riesgos asociados a las amenazas analizadas en el capítulo 4.Cabe señalar, no obstante, que las indicaciones contenidas en estas directrices también se recomiendan a quienes no estén sujetos a la normativa mencionada.
Las medidas de seguridad en cuestión no se refieren explícitamente a la configuración del servicio de correo electrónico, sino —según la normativa aplicable— a la configuración de los sistemas informáticos y de control industrial (PSNC y Cloud Regulation) o de los sistemas de información y redes (NIS2). Los servicios de correo electrónico a los que se refieren estas directrices pertenecen a ambos tipos de sistemas.
En particular, a continuación se ilustran los SPF, DKIMy DMARC , que proporcionan mecanismos de seguridad diseñados con el objetivo de reforzar la seguridad general del servicio de correo electrónico y, en particular, la autenticación del remitente y el control de la integridad de los mensajes.
5.1. FPS
SPF – Sender Policy Framework es un protocolo de autenticación, formalizado por RFC 7208, que permite al propietario de un dominio especificar qué direcciones IP están autorizadas para enviar mensajes de correo electrónico en su nombre y establecer las políticas que el destinatario debe aplicar si la dirección IP asociada al dominio de la dirección de correo electrónico del remitente no se encuentra entre las autorizadas explícitamente.
Las direcciones IP autorizadas figuran en un registro DNS TXT relacionado con el dominio del remitente, denominado registro SPF, y se ilustran en la siguiente sección de este párrafo.
De esta forma, el servidor de correo electrónico del destinatario al recibir un mensaje de un dominio determinado, puede consultar el registro SPF relacionado y autenticar su origen verificando que la dirección IP desde la que se recibió el mensaje se encuentra entre las autorizadas para enviar mensajes en nombre del dominio.
Es importante observar que el dominio que se verifica a nivel SPF es el relacionado con el remitente del sobre; por consiguiente, la adopción del protocolo SPF por sí sola no es suficiente para contrarrestar la suplantación de identidad, ya que este tipo de ataque podría llevarse a cabo a nivel del remitente del mensaje.
En caso de que una organización externalice, total o parcialmente, su servicio de correo electrónico a un tercero, como por ejemplo un proveedor de servicios en la nube, debe asegurarse de que los mensajes enviados por dicho proveedor superen las comprobaciones SPF. Para ello, la organización debe incluir en su registro SPF las direcciones IP desde las que los proveedores envían correos electrónicos en nombre del dominio de la organización.
En el caso del reenvío automático de correo electrónico, dado que los mensajes suelen ser redirigidos por un servidor intermedio, la dirección IP que realiza la entrega final ya no coincide con la autorizada originalmente por el dominio del remitente. En estos casos, para evitar que falle la verificación SPF, es necesario autorizar también los servidores de reenvío intermedios o recurrir a mecanismos como SRS (Sender Rewriting Scheme) o ARC (Authenticated Received Chain), que pueden ser más eficaces, especialmente en presencia de numerosos servidores de reenvío intermedios.
Cabe destacar que para que SPF sea realmente efectivo, debe estar configurado correctamente no solo por el remitente, sino también por el destinatario. En particular:
- El remitente debe publicar el registro SPF en el servidor DNS correspondiente, declarando las direcciones que están autorizadas para enviar correos electrónicos en su nombre;
- El destinatario debe configurar su propio servidor de correo para que ejecute la verificación SPF en los mensajes recibidos y aplique de forma coherente las políticas resultantes.
5.1.1. Registro SPF
Un registro SPF es un registro DNS de tipo TXT cuyo nombre corresponde al dominio del remitente y cuyo contenido está constituido la sección que indica la versión una serie de directivas que indican el comportamiento del servidor de correo del destinatario cuando hay una coincidencia entre la dirección IP del dominio del remitente y una directiva.
Las directivas se forman mediante un mecanismo precedido por un calificador. Los principales mecanismos utilizados en los registros SPF son: [2]:
- ip4, enumera las direcciones IPv4 autorizadas;
- ip6, enumera las direcciones IPv6 autorizadas;
- a, autoriza las direcciones IP presentes en el registro A del dominio;
- mx, autoriza las direcciones IP relacionadas con los registros MX del dominio;
- incluye, autoriza las IP presentes en el registro SPF de otro dominio;
- "all"representa todas las direcciones IP que no han sido autorizadas explícitamente a través de los otros mecanismos.
En particular, el "all" permite establecer políticas para los mensajes provenientes de direcciones IP que no hayan sido declaradas por mecanismos anteriores.
Además, SPF proporciona los siguientes calificadores para asociarlos con los mecanismos:
- + (pass) indica que las direcciones IP que coinciden con el mecanismo asociado están autorizadas. Es el calificador predeterminado si no se especifica otro;
- - (fail) indica que las direcciones IP que coinciden con el mecanismo asociado no están autorizadas;
- ~ (softfail) indica que las direcciones IP que coinciden con el mecanismo asociado probablemente no estén autorizadas. Esta es una declaración más incierta que la anterior. En estos casos, el mensaje debe aceptarse pero marcarse para un análisis más profundo; se utiliza, por ejemplo, en casos de depuración o cuando se prevé que la verificación SPF podría no ser exitosa;
- ? (neutral) indica que no se proporciona ninguna indicación para las direcciones IP que coincidan con el mecanismo asociado. El comportamiento predeterminado es aceptar el mensaje.
Es importante destacar que, en la práctica, el registro SPF se compone para especificar las direcciones IP autorizadas, y luego se utiliza la directiva -all para indicar que todas las demás direcciones no están autorizadas (para más detalles, consulte los ejemplos a continuación). Esta es la configuración recomendada, ya que permite indicar explícitamente las direcciones IP autorizadas y excluir todas las demás.
En cualquier caso, se recomienda no utilizar nunca la directiva +all (o su equivalente all), ya que correspondería a la autorización de todas las direcciones IP.
Ejemplos de registros SPF
Autorizar una dirección IP específica
v=spf1 ip4:203.0.113.0 -todos
El registro SPF que se muestra arriba utiliza la versión 1 de SPF y autoriza, mediante el mecanismo ip4 , la dirección IP 203.0.113.0 (de hecho, como no se especifica ningún calificador para el mecanismo ip4 , se utiliza implícitamente el valor predeterminado + ). La directiva -all, formada por el mecanismo all y el calificador - (fail), especifica que todas las demás direcciones no están autorizadas.
Autorizar un espacio de direcciones IP específico
v=spf1 ip4:203.0.113.0/24 -todos
El registro SPF que se muestra arriba es análogo al anterior, pero autoriza todas las direcciones IP del 203.0.113.0/24 .
Autorizar múltiples direcciones IP
v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -todos
El registro SPF que se muestra arriba autoriza exclusivamente las direcciones IPv4 203.0.113.22 y 203.0.113.44.
Autorizar direcciones de registro MX y un dominio específico
v=spf1 mx incluir:spf.emailprovider.it -todo
El registro SPF que se muestra arriba autoriza exclusivamente las direcciones IP de los registros MX del mismo dominio que el registro SPF y las autorizadas del dominio spf.emailprovider.it (por ejemplo, el dominio de un proveedor de servicios de correo electrónico).
5.1.2. Proceso de autenticación
Si está configurado correctamente para realizar la verificación SPF, el servidor de correo del destinatario, al recibir un nuevo mensaje, recupera el registro SPF del dominio del remitente consultando el servidor DNS que contiene los registros de dicho dominio, según la dirección indicada en el campo "de" del sobre. Por ejemplo, si la dirección indicada en el campo "de" del sobre es alice@example.com, el servidor de correo del destinatario recupera el registro SPF del dominio example.com.

Figura 2. Mecanismo de funcionamiento de la verificación SPF.
El servidor de correo del destinatario realiza entonces la verificación SPF, analizando el registro SPF para determinar si la dirección IP desde la que recibió el mensaje está autorizada para enviar correos electrónicos para el example.com . Si el correo electrónico supera la verificación SPF, se entrega al destinatario.
Por ejemplo, si el registro SPF del dominio example.com fuera v=spf1 ip4:203.0.113.22 -all la verificación pasaría solo si la dirección IP del servidor remitente fuera 203.0.113.22 , mientras que fallaría para cualquier otra dirección.
» Volver arriba
5.2. DKIM
DKIM (DomainKeys Identified Mail) es un protocolo de autenticación, formalizado por el RFC 6376, que permite al propietario de un dominio garantizar la autenticidad de los mensajes de correo electrónico enviados mediante la adición de una firma digital (firma DKIM) generada por el servidor de correo a través de algoritmos criptográficos públicos e insertada en las cabeceras del mensaje que se va a transmitir.
Para que el destinatario pueda verificar que el mensaje no ha sido modificado durante la transmisión, la clave pública asociada a la firma DKIM se guarda en un registro TXT del DNS público del dominio del remitente, denominado registro DKIM, que el servidor de correo del destinatario consulta al recibir el mensaje.
La firma y el registro DKIM se ilustran en las secciones siguientes de este párrafo.
Al igual que con SPF, DKIM también debe ser configurado correctamente por el remitente y el destinatario y, en particular:
- El remitente debe configurar su servidor de correo para generar firmas DKIM y publicar el registro DKIM en el servidor DNS correspondiente;
- El destinatario debe configurar su servidor de correo para que realice la verificación DKIM en los mensajes recibidos.
5.2.1. Firma DKIM
La firma DKIM se genera a partir de elementos designados del cuerpo y las cabeceras del mensaje y consta de una serie de pares clave-valor que especifican elementos entre los cuales:
- v: versión del protocolo;
- a: algoritmo de cifrado utilizado;
- d: dominio de firma que declara la autenticidad del mensaje;
- s: selector que indica qué clave pública DKIM buscar en el registro DNS;
- h: lista de encabezados de correo electrónico incluidos en la firma;
- bh: hash del cuerpo del mensaje codificado en formato base64;
- b: firma digital real generada con la clave privada y codificada en formato base64;
- x: fecha de validez de la firma;
- c: tipo de canonización.
La canonicalización es el proceso de normalizar los elementos de un mensaje antes de firmarlo digitalmente, con el fin de reducir el impacto de pequeñas modificaciones que puedan ocurrir durante la transmisión, como espacios repetidos o saltos de línea. Existen dos tipos de canonicalización: la simple, que requiere una coincidencia exacta entre el mensaje original y el recibido, y la relajada, que aplica normalizaciones como la eliminación de espacios, la conversión de mayúsculas a minúsculas en los encabezados y la reducción de líneas vacías consecutivas en el cuerpo del mensaje.
5.2.2. Registro DKIM
El registro DKIM se conserva en un registro DNS de tipo TXT cuyo nombre tiene la estructura selector._domainkey.domain, donde _domainkey es una etiqueta que indica que el registro DNS es efectivamente un registro DKIM. El contenido del registro DKIM consta de una serie de pares clave-valor que especifican elementos entre los cuales:
- v: versión del protocolo;
- k: tipo de clave, que por defecto es RSA;
- p: clave pública codificada en formato base64.
Ejemplo de registro DKIM
Nombre: s1._domainkey.example.com
Valor: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...
El registro DKIM de ejemplo está asociado con el selector s1 del example.com , utiliza la versión 1 y contiene la clave pública RSA codificada en formato base64 (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).
5.2.3. Proceso de autenticación
Si el protocolo DKIM está configurado correctamente en los servidores de correo del remitente y del destinatario, el funcionamiento del proceso de autenticación y verificación DKIM garantiza que el servidor de correo del remitente cree la firma DKIM del mensaje, tal como se describe en el párrafo 5.2.1, la cual se agrega al propio mensaje. En concreto, la firma DKIM contiene en el d el dominio de firma y en el b la firma digital del mensaje generada con la clave privada del dominio de firma.

Figura 3. Mecanismo de funcionamiento de la verificación DKIM.
Al recibir un mensaje, el servidor de correo del destinatario recupera el registro DKIM del dominio firmante (d de la firma DKIM) del servidor DNS que contiene los registros de dicho dominio. A continuación, utiliza la clave pública contenida en el registro DKIM para verificar la firma digital (b ) que contiene la firma DKIM. Si la verificación es exitosa, el mensaje se entrega al destinatario.
5.2.4. Aspectos criptográficos
En el ámbito criptográfico, DKIM ha utilizado históricamente el RSA , en particular la rsa-sha256 , considerada el estándar desde 2007. La nueva alternativa, introducida por el RFC 8463, es Ed25519-SHA256, una forma moderna de firma digital basada en curvas elípticas que garantiza una mayor eficiencia y claves mucho más compactas.
A nivel técnico, RSA, con una longitud de clave de 2048 bits, sigue siendo el estándar universal, pero las claves son largas y las firmas relativamente grandes, mientras que Ed25519 ofrece claves nueve veces más cortas y firmas cuatro veces más pequeñas, con un rendimiento de firma hasta treinta veces superior al de RSA 2048. A pesar de estas ventajas, su uso en entornos reales es limitado: en 2026, Ed25519 solo está verificado por unos pocos proveedores, mientras que algunos operadores importantes no ofrecen soporte fiable ni para la firma ni para la verificación, lo que lo hace inadecuado como única solución en producción.
Por este motivo, a pesar de su superioridad técnica, en el momento de redactar este documento, no se recomienda el uso de Ed25519 salvo en combinación con RSA, mediante firma dual, desde una perspectiva experimental y como medida de compatibilidad futura. Hasta que los principales proveedores implementen completamente su verificación, RSA sigue siendo esencial para garantizar la máxima seguridad en la entrega de mensajes.
En cuanto a la seguridad a largo plazo, es importante recordar que ni RSA ni Ed25519 son resistentes a los ataques de futuras computadoras cuánticas [3], y la transición hacia algoritmos post-cuánticos requerirá nuevos estándares DKIM que actualmente no existen, lo que hace esencial monitorear los desarrollos de criptografía de próxima generación y las futuras recomendaciones de ACN en esta área.
En lo que respecta a la gestión de claves criptográficas, la clave privada DKIM debe protegerse con rigurosas medidas de seguridad, manteniéndola en sistemas aislados accesibles únicamente a servicios autorizados, adoptando permisos restrictivos, rotación periódica y monitorización constante para evitar accesos no autorizados o vulneraciones de seguridad.
» Volver arriba
5.3. DMARC
DMARC – Domain-based Message Authentication, Reporting and Conformance es un protocolo de autenticación, formalizado por RFC 7489, que integra mecanismos SPF y DKIM, permitiendo al propietario de un dominio especificar, a los destinatarios de los mensajes transmitidos desde ese dominio, las políticas para gestionar aquellos mensajes que no superen las verificaciones SPF y DKIM.
En concreto, DMARC introduce un mecanismo de autenticación —denominado alineación— que verifica la correspondencia entre los dominios autenticados por SPF y DKIM y el dominio correspondiente al "message-from " del mensaje recibido. Cabe destacar que la comprobación de alineación entre el "message-from " y el dominio SPF/DKIM falla en cualquier caso si la verificación SPF/DKIM correspondiente también falla (véase la figura 4).

Figura 4. Mecanismo de verificación DMARC.
La alineación se puede verificar en estricto , donde se requiere una coincidencia exacta entre los dominios autenticados por SPF/DKIM y el correspondiente al message-from , o en modo relajado, donde basta con que los dominios principales coincidan, aunque los subdominios sean diferentes.
Por ejemplo, en relajado para los dominios sub1.example.com y sub2.example.com se encontraría una alineación para fines de verificación DMARC (ya que el dominio principal, example.com, es el mismo). Sin embargo, en estricto , la verificación de alineación DMARC fallaría debido a la falta de una coincidencia exacta entre los dominios.
Mediante la verificación de alineación, incluso si un atacante lograra pasar las comprobaciones SPF y/o DKIM utilizando un mensaje-from diferente del sobre-from autenticado por SPF y/o del dominio de firma autenticado, DMARC seguiría detectando la discrepancia, asegurando una verificación coherente y fiable de la identidad del remitente [2].
Las políticas para gestionar los mensajes que no superan se especifican en un registro TXT del servidor DNS relativo del dominio del remitente, denominado registro DMARC, y se ilustran en la siguiente sección de este párrafo.
DMARC también permite indicar a los destinatarios que envíen informes a los propietarios del dominio remitente sobre los mensajes que afirman provenir de dicho dominio. De esta forma, el propietario del dominio puede verificar si su dominio se está utilizando de forma no autorizada y en qué medida, analizando, por ejemplo, cuántos mensajes son realmente rastreables hasta él del total de mensajes que afirman provenir de ese dominio.
Al igual que con SPF y DKIM, DMARC también debe ser configurado correctamente por el remitente y el destinatario y, en particular:
- El remitente debe publicar el registro DMARC en su DNS especificando las políticas con las que gestionar los mensajes que no superen la verificación DMARC;
- El destinatario debe configurar su servidor de correo para que ejecute la verificación DMARC en los mensajes recibidos.
5.3.1. Registro DMARC
El nombre del registro DMARC tiene la estructura _dmarc.dominio, donde _dmarc es una etiqueta que se utiliza para indicar que el registro DNS es un registro DMARC y dominio es el dominio al que se refiere la política.
El registro DMARC consta de una serie de pares clave-valor que especifican elementos entre los cuales:
- v: Protocolo DMARC versión;
- p: política que se aplicará a los mensajes que fallen la verificación DMARC, puede asumir uno de los valores
none, quarantine, reject;
- aspf: modo de alineación que se aplicará a la comprobación SPF (puede ser
relajado, valor predeterminado o estricto);
- adkim: modo de alineación que se aplicará a la verificación DKIM (puede ser
relajado, valor predeterminado o estricto);
- rua: direcciones de correo electrónico a las que enviar informes agregados con información estadística y resumida sobre los mensajes recibidos del dominio del remitente;
- ruf: direcciones de correo electrónico a las que enviar informes detallados sobre los mensajes individuales recibidos del dominio del remitente que no superaron la verificación DMARC.
Ejemplo de registro DMARC
Nombre:
_dmarc.example.com
Valor:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s
El registro DMARC de ejemplo está asociado con el dominio example.com , utiliza la versión 1 y especifica la política de rechazo para los mensajes que no superan la verificación DMARC, solicitando el modo estricto ( s ) para la verificación de la alineación de los dominios SPF y DKIM y para transmitir informes agregados a la dirección de correo electrónico dmarc-reports@example.com e informes de fallos a la dirección dmarc-fail@example.com .
5.3.2. Políticas DMARC
Como se describe en el párrafo anterior, el registro DMARC indica la política que el servidor de correo receptor debe aplicar a los mensajes que no superan la verificación DMARC. Las políticas posibles son las siguientes:
- Ninguno: el dominio del remitente no proporciona ninguna indicación sobre la entrega de mensajes que no superen la verificación DMARC;
- cuarentena: el dominio del remitente indica que los mensajes que no superen la verificación DMARC deben considerarse sospechosos (por ejemplo, sometidos a un examen más exhaustivo, tratados como spam o etiquetados como sospechosos);
- rechazar: el dominio del remitente indica que los mensajes que no superen la verificación DMARC deben ser rechazados.
5.3.3. Proceso de verificación y aplicación de la póliza
Si el protocolo DMARC está configurado correctamente tanto en el servidor de correo del remitente como en el del destinatario, al recibir el mensaje, el servidor de correo del destinatario recupera los registros SPF y DKIM para realizar las verificaciones correspondientes, así como la verificación DMARC (detallada al inicio del párrafo 5.2.4). En caso de que el mensaje no supere la verificación DMARC, se aplica la política indicada en el registro DMARC (ninguna, cuarentena o rechazo).

Figura 5. Proceso de verificación y aplicación de las políticas DMARC.
Cabe destacar que cada servidor de correo puede adoptar heurísticas y políticas locales para determinar si se entrega o no un mensaje, teniendo en cuenta también el resultado de las verificaciones SPF, DKIM y DMARC. Por lo tanto, generalmente existe un proceso de toma de decisiones adicional («Filtro estándar» en la Figura 5) posterior a las verificaciones mencionadas, que puede incluir comprobaciones adicionales (como, por ejemplo, filtros antispam y antimalware).
Además, el servidor de correo receptor puede transmitir:
- a las direcciones indicadas en el
rua del registro DMARC, informes agregados con información estadística y resumida sobre los mensajes recibidos del dominio del remitente;
- A las direcciones indicadas en el
ruf del registro DMARC, se enviarán informes detallados sobre los mensajes individuales recibidos del dominio remitente que no superaron la verificación DMARC.
» Volver arriba
6. Conclusiones
Como se analizó en el capítulo anterior, para contrarrestar mejor las amenazas vinculadas a la suplantación de dominio del remitente es necesario que los tres protocolos examinados se implementen conjuntamente y, en particular, que [3]:
- El dominio remitente publica correctamente los registros SPF, DKIM y DMARC en el DNS;
- El servidor de correo del remitente está configurado para firmar los mensajes con DKIM;
- El servidor de correo del destinatario está configurado para realizar verificaciones SPF y DKIM y aplicar políticas DMARC.
Con respecto a la implementación del protocolo, también se formulan las siguientes recomendaciones [2]:
- Configure SPF especificando qué direcciones IP están autorizadas a enviar correos electrónicos en nombre del dominio; para los dominios que no se utilizan para la transmisión de correo electrónico, por ejemplo, aquellos destinados exclusivamente a sitios web, se debe crear un registro SPF para indicar explícitamente que no hay remitentes de correo electrónico válidos para ese dominio;
- Utilice protocolos y algoritmos de cifrado de última generación considerados seguros para las claves DKIM; a la fecha de redacción de este documento, se recomienda RSA de 2048 bits;
- Proteger adecuadamente la clave privada DKIM almacenada en el servidor de correo, adoptando permisos de acceso restrictivos, y garantizar que solo el software del servidor de correo tenga privilegios de lectura sobre la clave;
- Configure cada servidor de correo con un par de claves y un selector únicos, con el fin de reducir el impacto de una posible vulneración de la clave privada;
- proteger la clave privada tanto de la divulgación accidental como de los intentos de acceso o modificación por parte de un atacante;
- estipule que el software relacionado con cualquier lista de correo verifique las firmas DKIM en los mensajes entrantes y adjunte nuevas firmas DKIM en los salientes;
- Utilice pares de claves DKIM únicos para cada tercero que envíe correos electrónicos en nombre de la organización;
- Rote periódicamente los pares de claves DKIM (al menos cada seis meses) para mitigar el impacto de una posible vulneración de seguridad;
- Revocar inmediatamente las claves en caso de sospecha de vulneración de seguridad;
- Supervise los informes de DMARC para identificar cualquier error de configuración o intento de abuso.
Para obtener más detalles, consulte los recursos que figuran en la sección Documentos de referencia.
Se observa que, para proteger adecuadamente la seguridad del correo electrónico, además de los protocolos de autenticación aquí examinados, existen otros protocolos —que no son objeto de estas directrices— como, por ejemplo, TLS (Transport Layer Security), que garantiza el cifrado del canal de transmisión, y SMIME y OpenPGP , que se refieren al cifrado de extremo a extremo y la autenticación de mensajes.
Cabe destacar que, si bien no se trata de un protocolo de seguridad de correo electrónico en sentido estricto, para garantizar la seguridad del servicio de correo electrónico se recomienda implementar DNSSEC (Domain Name System Security Extensions), una extensión del protocolo DNS que añade firmas criptográficas a los registros DNS para garantizar la integridad y autenticidad de las consultas DNS. Gracias a DNSSEC, por ejemplo, la información relativa a los registros SPF, DKIM y DMARC se protege durante la transmisión, lo que reduce el riesgo de alteración y, por lo tanto, aumenta la seguridad del servicio de correo electrónico.
» Volver arriba
Apéndice A: Medidas de seguridad
Perímetro Nacional de Ciberseguridad (PSNC)
PR.IP-1: Se definen y gestionan prácticas de referencia (denominadas líneas base) para la configuración de sistemas informáticos y sistemas de control industrial que incorporan principios de seguridad (por ejemplo, el principio de mínima funcionalidad).
- Existe un documento actualizado detallado que indica, también en relación con la categoría ID.AM, al menos:
- a) las políticas de seguridad adoptadas para el desarrollo de configuraciones de sistemas de control industrial y de TI y el despliegue únicamente de las configuraciones adoptadas;
- b) la lista de configuraciones de sistemas de control industrial y de TI empleadas y la referencia a las prácticas de referencia relativas;
- c) los procesos, metodologías y tecnologías empleadas que contribuyen al cumplimiento de las políticas de seguridad.
Regulación de la nube: infraestructuras y servicios digitales para la administración pública
PR.IP-01: Se definen y gestionan prácticas de referencia (denominadas líneas base) para la configuración de sistemas informáticos y sistemas de control industrial que incorporan principios de seguridad (por ejemplo, el principio de mínima funcionalidad).
- Se definen políticas y procedimientos en relación con la seguridad de las aplicaciones para brindar el apoyo adecuado para la planificación, la implementación y el mantenimiento de las funciones de seguridad de las aplicaciones, las cuales deben revisarse y actualizarse al menos anualmente.
- Existe un documento actualizado detallado que indica, también en relación con la categoría ID.AM, al menos:
- a) las políticas de seguridad adoptadas para el desarrollo de configuraciones de sistemas de control industrial y de TI y el despliegue únicamente de las configuraciones adoptadas;
- b) la lista de configuraciones de sistemas de control industrial y de TI empleadas y la referencia a las prácticas de referencia relativas;
- c) los procesos, metodologías y tecnologías empleadas que contribuyen al cumplimiento de las políticas de seguridad.
- Se definen y documentan los requisitos básicos de seguridad para diversas aplicaciones.
- Se definen e implementan métricas de carácter técnico útiles para supervisar el nivel de cumplimiento de los requisitos de seguridad y las obligaciones de cumplimiento establecidos.
- Existe un proceso para la mitigación y recuperación de vulnerabilidades de las aplicaciones, con el fin de garantizar la seguridad de las mismas, automatizando la corrección cuando sea posible.
- Existe un proceso para validar la compatibilidad de los dispositivos con los sistemas operativos y las aplicaciones.
- Existe un sistema de gestión de variaciones en lo que respecta al sistema operativo, la aplicación de parches y/o las aplicaciones.
Regulación de la nube: servicios en la nube para la administración pública
PR.IP-01: Se definen y gestionan prácticas de referencia (denominadas líneas base) para la configuración de sistemas informáticos y sistemas de control industrial que incorporan principios de seguridad (por ejemplo, el principio de mínima funcionalidad).
- Se definen políticas y procedimientos con referencia a la seguridad de las aplicaciones para brindar un soporte adecuado para la planificación, realización y mantenimiento de las características de seguridad de las aplicaciones, las cuales deben revisarse y actualizarse al menos anualmente [IaaS, SaaS].
- Existe un documento actualizado detallado que indica, también en relación con la categoría ID.AM, al menos:
- a) las políticas de seguridad adoptadas para el desarrollo de configuraciones de sistemas de control industrial y de TI y el despliegue únicamente de las configuraciones adoptadas;
- b) la lista de configuraciones de sistemas de control industrial y de TI empleadas y la referencia a las prácticas de referencia relativas;
- c) los procesos, metodologías y tecnologías empleadas que contribuyen al cumplimiento de las políticas de seguridad [SaaS].
- Se definen y documentan los requisitos básicos de seguridad para diversas aplicaciones.
- Se definen e implementan métricas de carácter técnico útiles para supervisar el nivel de cumplimiento de los requisitos de seguridad y las obligaciones de cumplimiento establecidos. 5. Existe un proceso para la mitigación y recuperación de vulnerabilidades de las aplicaciones, con el fin de garantizar la seguridad de las mismas y automatizar la corrección cuando sea posible.
- Existe un proceso para validar la compatibilidad de los dispositivos con los sistemas operativos y las aplicaciones [PaaS, SaaS].
- Existe un sistema de gestión de variaciones en términos de sistema operativo, parches y/o aplicaciones [PaaS, SaaS].
NIS 2
PR.PS-01: Se establecen y aplican prácticas de gestión de la configuración.
- Para los sistemas de información y de red pertinentes, al menos, sus configuraciones básicas de seguridad (reforzadas) están definidas y documentadas en una lista actualizada.
- En cumplimiento de las políticas a que se refiere la medida GV.PO-01, se adoptan y documentan procedimientos en relación con el punto 1.
» Volver arriba
Bibliografía
[1] NIST, «Nota técnica 1945».
[2] NIST, «Publicación especial NIST 800-177 Revisión 1».
[3] Agencia Nacional de Ciberseguridad, «Criptografía postcuántica y cuántica: preparación para la amenaza cuántica».
[4] Agencia Nacional de Ciberseguridad, «Marco de autenticación de correo electrónico».
» Volver arriba
una buena alternativa a los correos electrónicos con copia oculta (CCO)
En una publicación anterior explicamos las ventajas y desventajas de usar correos electrónicos con copia oculta (CCO),
consulte: “cómo enviar y limitar correos electrónicos con copia oculta”.
En las conclusiones, entre otras frases, afirmamos:
Utilice aplicaciones específicas para enviar correos masivos. Los sistemas profesionales cuentan con un flujo de trabajo de aprobación y un control paso a paso, y están diseñados para evitar errores.
Resumen de este artículo:
Cómo funciona
Las plataformas de marketing por correo electrónico pueden ser difíciles de aprender y de mantener (en caso de que las proporcione a sus clientes).
Lo que describimos aquí es la idea de usar el software de código abierto "GNU Mailman" para enviar correos masivos. Esta sugerencia surge de nuestra propia experiencia ofreciendo la aplicación "copymail " , fácil de usar .
Una lista "unidireccional" de Mailman es una configuración para boletines informativos o anuncios
en la que solo los moderadores autorizados pueden publicar mensajes y los miembros no pueden responder a la lista.
Así es como funciona:
-
El usuario envía el mensaje desde su cliente de correo electrónico o desde el webmail a la dirección de correo electrónico de la lista.
A continuación, debe aprobar la entrega, que se distribuirá desde el servidor a todos los suscriptores.
-
El sistema gestiona automáticamente los correos electrónicos devueltos y, si se desea, las bajas de suscripción.
Las suscripciones deben registrarse manualmente.
-
El servicio es altamente confiable y puede gestionar miles de direcciones sin dificultad.
El envío se realiza a través de los servidores SMTP de RealSender u otros proveedores.
volver arriba
Lista “unidireccional” de GNU Mailman
GNU Mailman es un software muy utilizado que ofrecen la mayoría de los proveedores de servicios de Internet.
En Internet existen varias guías que explican cómo configurarlo y usarlo para envíos masivos de correo electrónico:
- Los miembros se unen rellenando un formulario en su sitio web (y respondiendo al correo electrónico de confirmación)
- Se les enviará un mensaje de bienvenida que no menciona cómo publicar en la lista
- Recibirán tus boletines informativos, con un pie de página que incluye instrucciones sencillas para darse de baja
- Solo las personas autorizadas pueden publicar en la lista (enviar los boletines informativos)
La referencia principal es este documento tomado de dos publicaciones de Barry Warsaw en la lista de correo mailman-users: ¿
Cómo creo una lista de correo/anuncio/unidireccional?
El texto explica en detalle los puntos principales:
- Cómo crear un mensaje de bienvenida personalizado y una página de información de la lista que evite mencionar cómo publicar en la lista
- Cómo minimizar los problemas de contraseñas y los problemas de cancelación de suscripción que se suelen presentar en este tipo de listas
- Cómo restringir la lista para que solo las personas autorizadas puedan publicar
- Cómo configurar una lista de anuncios para responder a una dirección de contacto
- Cómo publicar en la lista de anuncios
Otro artículo de la Universidad de Stanford explica cómo
usar Mailman para configurar una lista de correo exclusivamente para anuncios:
Cómo configurar una lista de correo unidireccional solo para anuncios o boletines informativos - Artículo de la base de conocimientos KB00010792
volver arriba
Un poco de historia sobre GNU Mailman
Las listas de correo pueden estar basadas en debates o en anuncios. El software Mailman está escrito en Python; antes de su lanzamiento, la comunidad de Python utilizaba Majordomo, un gestor de listas de correo basado en Perl.
Actualmente, Mark Sapiro se encarga del mantenimiento de la rama estable 2.1,
mientras que Barry Warsaw se concentra en la nueva versión 3.X.
Dos principios fundamentales que son cruciales para el éxito continuo de Mailman:
- Ningún mensaje debería perderse jamás
- Ningún mensaje debe entregarse más de una vez
En Mailman 2, los desarrolladores rediseñaron el sistema de gestión de mensajes para garantizar que estos dos principios siempre fueran de suma importancia. Esta parte del sistema se ha mantenido estable durante al menos una década y es una de las razones clave por las que Mailman es tan popular hoy en día.
volver arriba
Gestión de rebotes de VERP
VERP significa Ruta de Retorno de Sobre Variable. Es una técnica muy conocida que utilizan las listas de correo para determinar de forma inequívoca las direcciones de correo electrónico que rebotan. Cuando la lista de correo recibe un rebote, puede tomar medidas útiles, como deshabilitar la dirección rebotante o eliminarla de la lista.
Existe un formato estándar para los mensajes de rebote, denominado notificaciones de estado de entrega. Mailman utiliza una biblioteca que contiene docenas de heurísticas de formato de rebote, todas las cuales se han observado en la práctica durante los veinte años de existencia de Mailman.
VERP aprovecha un requisito del protocolo SMTP fundamental para proporcionar una detección inequívoca de rebotes, devolviendo dichos mensajes al remitente del sobre. No se trata del "De:" en el cuerpo del mensaje, sino del "MAIL FROM" establecido durante el diálogo SMTP. Este valor se conserva a lo largo de la ruta de entrega, y el servidor de correo receptor final está obligado, según los estándares, a enviar los rebotes a esta dirección.
Si el servidor de Mailman es mylist@example.org, el remitente del sobre codificado en VERP para una publicación en la lista de correo enviada a anne@example.com será:
mylist-bounce+anne=example.com@example.org. Los correos electrónicos rebotados se envían a la dirección del destinatario codificada en VERP. Mailman puede entonces analizar el "Para:" para decodificar el destinatario original como anne@example.com.
El uso de VERP requiere que Mailman envíe exactamente una copia del mensaje por destinatario. VERP exige un remitente para cada destinatario, y la única forma de lograrlo es enviando una copia única del mensaje. Este método también ayuda a evitar que el mensaje se identifique como spam.
volver arriba
Alineación de direcciones From y Mail From
Durante el período de prueba, la configuración predeterminadade la aplicación "copymail" utiliza un dominio proporcionado por nosotros como de correo electrónico del remitente (también conocida como dirección de rebote/ruta de devolución/dirección de sobre), que es la dirección a la que se devuelven los correos electrónicos rebotados. Este dominio de correo electrónico del remitente es diferente del de dirección del remitente (la dirección del remitente visible para los destinatarios).
Antes de ponerlo en producción, es necesario realizar algunos cambios en el DNS para autenticar los mensajes enviados con el del remitente . Los estándares de correo electrónico más recientes permiten enviar correos electrónicos autenticados utilizando un subdominio como del remitente (por ejemplo, email.tudominio.com) y, al mismo tiempo, seguir utilizando el dominio base como del remitente (por ejemplo, info@tudominio.com). Encontrará más detalles en la de configuración avanzada de autenticación de correo electrónico .
La misma situación puede darse en otros entornos. Le recomendamos que lo verifique con su proveedor de servicios de internet.
volver arriba
Proxy inverso para servidores SMTP
Un proxy inverso es un servidor que se sitúa delante de uno o más servidores web
para gestionar las solicitudes de los clientes, mejorando así la seguridad, el rendimiento y la escalabilidad.

En lugar de comunicarse directamente con los servidores,
los clientes envían sus solicitudes al proxy inverso,
que las redirige a los servidores adecuados,
actuando como un único punto de acceso seguro.
Beneficios clave:
- Seguridad:
Puede bloquear solicitudes maliciosas, cifrar el tráfico
y proteger los servidores backend de ataques directos.
- Rendimiento:
Distribuye el tráfico entrante entre varios servidores, evitando la sobrecarga
de un solo servidor y garantizando una mayor disponibilidad.
- Escalabilidad:
Permite añadir o eliminar servidores backend sin interrupción del servicio,
ofreciendo la capacidad de gestionar un tráfico creciente.
Proxy inverso solo HTTP (Capa 7)
Hay varias herramientas disponibles en Internet; después de investigar, inicialmente descartamos aquellas que solo admiten el protocolo HTTP (Capa 7):
NO Apache
“¡Ay, Dios mío! Tómese un momento para familiarizarse con las tecnologías que está utilizando. El correo electrónico usa SMTP. Apache usa HTTP. Apache no sabe absolutamente nada sobre SMTP. Si desea trabajar con mensajes de correo electrónico, necesitará una tecnología compatible con SMTP.” – EEAA comentó el 18 de agosto de 2016 a las 2:49.
NO Caddy
“Caddy no puede actuar como proxy para TCP, solo para HTTP sobre TCP. Utilice un proxy inverso que pueda actuar como proxy para TCP, como Traefik, Nginx o haproxy, o utilice este complemento experimental.” – ElevenNotes comentó el 24 de septiembre de 2024
A continuación, nos centramos en las tres opciones recomendadas en los comentarios: "Traefik, NginX o HAProxy", instalándolas y probándolas una por una.
Traefik fue la primera opción.
La mayoría de los tutoriales comenzaban con Docker, una plataforma que quería evitar y para la que prefería una solución sencilla, posiblemente basada en uno de los gestores de paquetes de Linux, como YUM para distribuciones basadas en RPM como Fedora y CentOS, o APT (Advanced Package Tool), que se utiliza en distribuciones basadas en Debian como Ubuntu y Debian.
Tras una larga búsqueda, encontramos este artículo reciente, que describe el tipo de instalación que buscábamos:
Configurar Traefik como un servicio systemd.
Una aclaración: debe cambiar la configuración de SELinux de "Enforcing" a "Permissive"
Tras probar dos cursos en Udemy, encontramos este excelente:
Traefik Crash Course (sin Docker).
Logramos que funcionara reproduciendo los ejemplos. Hacia el final del vídeo, el excelente instructor expresó su total desaprobación de esta herramienta:
Traefik Crash Course - 53:50 Summary.
Esto nos desanimó a seguir probando, lo que nos llevó a buscar otra alternativa.
NginX fue la segunda opción
En este caso, la instalación fue más sencilla, usando YUM en resumen:
yum install epel-release nginx nginx-mod-stream nginx-mod-mail
Una nota: en SELinux, necesitas habilitar el relé:
setsebool -P httpd_can_network_relay 1
Para la capacitación, fuimos a lo seguro, con el mismo instructor del curso anterior:
NginX Crash Course (la primera parte termina después de aproximadamente una hora y veinte minutos). El instructor tampoco está convencido de esta aplicación, en particular del hecho de que funciona como servidor web y proxy inverso:
NginX Crash Course - 1:20:10 Summary.
El informe termina con "Elijo HAProxy en lugar de NginX", así que decidimos probar HAProxy también.
Finalmente, también probamos HAProxy.
La instalación resultó ser facilísima, ya que es una aplicación muy común, disponible en todos los gestores de paquetes de Linux, por ejemplo: yum install haproxy
También hemos consultado a nuestro instructor de confianza:
HAProxy Crash Course.
Funciona, pero lamentablemente NO es adecuado para la autenticación SMTP:
“No es posible configurar haproxy de esta manera, porque haproxy no admite SMTP en absoluto”.
– lukastribus comentó el 17 de agosto de 2023.
Un servidor SMTP estándar como proxy inverso
Llegados a este punto, tras dos semanas de pruebas, nos dimos cuenta de que
es mejor utilizar un servidor SMTP estándar como proxy inverso para otros servidores SMTP.
Cumple su función utilizando únicamente el protocolo SMTP, autentica correctamente las conexiones
y puede reenviar solicitudes a otros servidores SMTP mediante la función "smarthost".
En Postfix, en main.cf, como
relayhost = [dirección_de_host_inteligente]:puerto
En Sendmail, en sendmail.mc, como
define(`SMART_HOST',`mail.example.com')
volver arriba
En ocasiones, has exportado datos de tu sitio web o software empresarial
que contienen información de pedidos o detalles de clientes.
Es posible que solo necesitaras la dirección de correo electrónico y la fecha del pedido.
Una opción es importar todos los datos a Excel, eliminar las columnas no deseadas
y exportar las restantes.
Esto puede no funcionar bien si el campo de correo electrónico también contiene la descripción de la dirección de correo electrónico,
por ejemplo: “Dave Martin
Puede resultar engorroso si tienes que repetir la tarea varias veces
o si tienes que explicar todos los pasos a otra persona.
Una expresión regular (abreviada como "regex" o "regexp")
es una secuencia de caracteres que especifica un patrón coincidente en un texto.
Un caso muy sencillo es localizar una palabra escrita de dos maneras diferentes en un editor de texto,
la expresión regular seriali[sz]e coincide tanto con "serialise" como con "serialize".
Una situación más compleja es la sintaxis para identificar en el texto
Tutorial de expresiones regulares (Regex)
Vídeo recomendado de YouTube:
“38 minutos bien invertidos, merece totalmente la pena” .
Cómo encontrar cualquier patrón de texto
(a partir del minuto 25 se explica la sintaxis para extraer direcciones de correo electrónico).
Guía rápida para el uso de expresiones regulares
Las expresiones regulares suelen ser aceptadas
en editores de texto avanzados como Notepad++ o Atom.
También existen herramientas online gratuitas, una de ellas es:
https://regexr.com , un servicio online para aprender, crear y probar expresiones regulares.
Explicación de la interfaz web:
«Expresión» es el campo que contiene la sintaxis de la expresión regular.
«Texto» es el contenido que desea analizar.
En «Herramientas > Lista» se mostrarán los resultados de la extracción.
Expresión:
[a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+
Texto:
Dave Martin 615-555-7164 173 Main St., Springfield RI 55924 davemartin@bogusemail.com Charles Harris 800-555-5669 969 High St., Atlantis VA 34075 charlesharris@bogusemail.com Eric Williams 560-555-5153 806 1st St., Faketown AK 86847 laurawilliams@bogusemail.com
Herramientas > Lista:
$&\n
Resultado:
davemartin@bogusemail.com charlesharris@bogusemail.com laurawilliams@bogusemail.com
Ejemplo 2: para extraer la dirección de correo electrónico y la fecha
Expresión:
","(.*?)([a-zA-Z0-9_-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+)(.*?)",".*",(\d{2}\.\d{2}\.\d{4})
Texto:
"lorem ipsum dolor sit amet",Robert Farrell<rmfarrell@bogusemail.com> ","",01.02.2024, ,5379, "consectetur adipiscing elit","""Mesa, René<rmesa@bogusemail.com> ""","",01.04.2024, ,20826, "sed do eiusmod tempor incididunt","Antonio Bugan<antonio@bogusemail.com> ","",01.04.2024, ,2856, "ut labore et dolore magna aliqua","Crawley Down Tennis Club<hello@bogusemail.com> ","",05.01.2024, ,4453,
Herramientas > Lista:
$2,$4\n
Resultado:
rmfarrell@bogusemail.com,02.01.2024 rmesa@bogusemail.com,04.01.2024 antonio@bogusemail.com,04.01.2024 hello@bogusemail.com,05.01.2024
Guía rápida para el uso de expresiones regulares
. - Cualquier carácter excepto nueva línea \d - Dígito (0-9) \D - No es un dígito (0-9) \w - Carácter de palabra (az, AZ, 0-9, _) \W - No es un carácter de palabra \s - Espacio en blanco (espacio, tabulación, nueva línea) \S - No es un espacio en blanco (espacio, tabulación, nueva línea) \b - Límite de palabra \B - No es un límite de palabra ^ - Inicio de una cadena $ - Fin de una cadena [] - Coincide con caracteres entre corchetes [^ ] - Coincide con caracteres que NO están entre corchetes | - O ( ) - Cuantificadores de grupo: * - 0 o más + - 1 o más ? - 0 o uno {3} - Número exacto {3,4} - Rango de números (mínimo, máximo)
Fuente: fragmentos de código de GitHub
volver arriba
Cómo proteger los dominios ''NO-MAIL''
La mayoría de las empresas y organismos públicos registran varios nombres de dominio.
Las empresas suelen adquirir más de un dominio para protegerse de errores de usuario y salvaguardar su marca.
Otras veces, lo hacen para promocionar eventos o proyectos que merecen una visibilidad especial.
Las cifras pueden variar desde unas pocas docenas de dominios hasta varios cientos para una sola actividad.
Oscilan entre unos doscientos en un municipio de una gran ciudad y los miles de Ferrari y Goldman Sachs.
Las cifras ascienden a niveles asombrosos si se tiene en cuenta el número total de dominios registrados,
que a finales de 2022 alcanzó los 350 millones de nombres de dominio, según afirma Verisign.
Muchos de estos dominios se utilizan como escaparate. No hay direcciones de correo electrónico en el sitio web.
Las solicitudes de contacto suelen redirigirse a formularios o a redes sociales.

La gestión del envío de correos electrónicos, con las autenticaciones necesarias (SPF, DKIM, DMARC, etc.), se está volviendo cada vez más compleja.
Por este motivo, normalmente solo se utiliza un dominio para las comunicaciones externas oficiales por correo electrónico.
Sin embargo, la idea de proteger la presencia en línea puede resultar un arma de doble filo.
Los dominios de exhibición mal configurados pueden ser fácilmente explotados por actores maliciosos.
Con frecuencia, abusan del nombre conocido del remitente para ganarse la confianza de los destinatarios y exigir acciones
que revelen información confidencial o la apertura de enlaces y archivos adjuntos.
Los destinatarios corren el riesgo de comprometer la seguridad de sus sistemas,
permitiendo el acceso desde el exterior a bandas de ciberdelincuentes.

Los complejos sistemas de autenticación mencionados anteriormente también tienen sus ventajas.
El protocolo DMARC fue diseñado para detectar correos electrónicos falsos y
evitar que personas u organizaciones no autorizadas envíen correos con nuestros remitentes.
Una configuración rápida permite declarar que un dominio determinado NO está en uso,
advirtiendo a los destinatarios que rechacen cualquier correo electrónico proveniente de ese dominio.
Basta con insertar un registro (una sola fila) en el DNS del dominio con esta indicación:
_dmarc.tudominio.com. TXT "v=DMARC1; p=rechazar"

La aplicación de esta regla depende del sistema que recibe los mensajes.
La buena noticia es que el protocolo DMARC es un estándar aprobado por la IETF desde marzo de 2015.
La mayoría de los servicios de correo electrónico en línea lo implementan para proteger a sus usuarios.
Los mensajes procedentes de dominios “NO-MAIL” serán rechazados automáticamente.
De esta forma, además de proteger a su empresa contra el abuso, evitará
que se utilicen por error dominios "antiguos" que ya no están autorizados para enviar correos ni autenticados.
¿Por qué las empresas utilizan SMS?
El problema: correos electrónicos sin leer, llamadas sin contestar.
La bandeja de entrada del correo electrónico está repleta de mensajes que compiten por la atención del consumidor,
lo que dificulta aún más que las empresas se hagan notar entre sus clientes y potenciales clientes.
Conseguir que alguien lea un correo electrónico importante (o incluso que atienda una llamada telefónica)
es cada vez más difícil.

El 48% de los consumidores tiene más de 50 mensajes sin leer en su bandeja de entrada.
La mayoría de los consumidores no eliminan los mensajes no leídos, por lo que los correos electrónicos se siguen acumulando.
– Fuente: ZipWhip. ¿Por qué tus clientes ya no leen tus correos electrónicos? (PDF, 15 MB)
Algunas actualizaciones son urgentes y pueden ser cruciales. Enviarlas por correo electrónico conlleva el riesgo
de que el mensaje no se lea o termine en la carpeta de correo no deseado.
Cuando se les preguntó "¿cuántas cuentas de correo electrónico tiene?", el 77% respondió "dos o más".
Normalmente, solo una está configurada en el teléfono inteligente.

Llamar a los clientes y no obtener respuesta
, o que la llamada vaya al buzón de voz,
es algo cada vez más común.
El 97% de los consumidores admite ignorar las llamadas de empresas y números desconocidos.
– Fuente: ZipWhip ¿Por qué sus clientes ya no contestan el teléfono? (pdf 15 MB)
La solución: envíame un mensaje de texto
La COVID-19 incrementó el uso de dispositivos electrónicos;
el 64% de las personas entrevistadas declaró: "Paso más tiempo en mi teléfono".

El 58% de los consumidores afirma que los mensajes de texto son la forma más eficaz para que las empresas se comuniquen con ellos rápidamente.
– Fuente: ZipWhip Estado de los mensajes de texto 2021 (pdf 21 MB)
Incluso en el comercio electrónico, donde normalmente se requiere el correo electrónico para registrarse,
algunas grandes empresas, como Amazon, ofrecen la posibilidad de registrarse mediante el número de teléfono móvil.
La explicación: cinco buenas razones para enviar mensajes de texto
-
inmediatos
y casi siempre se leen, generalmente segundos después de recibirlos.
La tasa de apertura supera el 95 % (de este 95 %, el 90 % se abre en los tres minutos posteriores a la entrega).
Los mensajes SMS son breves y concisos; la comunicación es esencial e inmediata.
-
Es sencillo.
No necesitan conexión a internet para llegar a su destinatario.
Permite que tu marca alcance a segmentos demográficos con poca familiaridad con la tecnología.
Su uso es similar al del contenido de vídeo (rápido, instantáneo, como se puede decir en 160 caracteres).
-
El
SMS es omnipresente y compatible con todos los teléfonos móviles del planeta, sin necesidad de instalar nuevas aplicaciones.
El smartphone (o el teléfono móvil de generaciones anteriores) siempre está al alcance de su dueño, como la cartera y las llaves de casa.
Permite interactuar con el cliente esté donde esté, a través de un canal fiable.
-
son económicos, ya que
su envío tiene un bajo costo.
La longitud promedio de los mensajes no supera los 155 caracteres (el límite es de 160 caracteres por mensaje).
Combinar los mensajes de texto con llamadas telefónicas o correos electrónicos permite ahorrar tiempo al comunicarse con los clientes.
-
interactiva
se realiza a través de un canal sin presiones ni artificios.
Los SMS se asocian con mayor importancia, tienen más probabilidades de ser abiertos y leídos, y también de recibir respuesta.
El lenguaje de los mensajes de texto es sencillo y fomenta la interacción. Las tasas de respuesta alcanzan hasta el 45%.
Cómo gestionar los correos electrónicos rebotados
Los correos electrónicos rebotados, o simplemente "rebotes", son correos electrónicos enviados automáticamente
por un MTA (Agente de Transferencia de Correo) al remitente
para informarle que el mensaje NO fue recibido correctamente por el destinatario.
El asunto suele ser «Correo devuelto: consulte la transcripción para obtener más detalles».
La información explicativa del rebote, un código con una descripción, se encuentra en el contenido.
El "código de estado" debería identificar claramente el tipo de error que provocó la devolución , pero a menudo es necesario analizar e interpretar los códigos y las descripciones que utiliza cada proveedor de servicios de correo electrónico para clasificar correctamente el rebote
¿Cuáles son los riesgos de los correos electrónicos rebotados?
El envío de correos electrónicos a destinatarios incorrectos o inactivos se considera una "conducta de spam".
No puedes ignorarlos
Si quieres llegar al resto de tu lista, lo mejor es dejar de enviar correos a la parte "problemática".
A veces, esto se denomina "higiene de la lista".
Debes comprender su significado
Hay tres tipos de Notificación de estado de entrega (DSN): Éxito: el correo electrónico se ha entregado (la notificación se envía solo si la solicita el remitente)
Rebote duro: se ha producido un error permanente
Rebote suave: se ha producido un error temporal
Rebote duro (código de estado 5.XXX.XXX): la dirección de correo electrónico generó un error permanente
como "550 5.1.1 … Usuario desconocido" o "5.1.2 … Host desconocido"
Un error permanente indica que nunca debe volver a enviar a ese destinatario.
Un solo mensaje rebotado debería activar el bloqueo de la dirección de correo electrónico.
Rebote suave (código de estado 4.XXX.XXX): la dirección de correo electrónico generó un error temporal
como "452 4.2.2 … Buzón lleno"
Un error transitorio indica que puede volver a intentar la entrega en el futuro.
Al menos tres mensajes rebotados, con pocos días de diferencia entre sí, deberían activar el bloqueo de la dirección de correo electrónico.
Debes saber cómo funciona el manejo de rebotes (y cómo ajustarlo)
- Todos los mensajes recibidos son descargados por una aplicación
y se ponen a disposición para su revisión humana, ya sea a través de la interfaz de la aplicación o a través de un archivo JSON.
- La clasificación sigue ciertas reglas que pueden editarse
- Las opciones definen cuándo los rebotes suaves se “actualizarán” al nivel de rebotes duros

» Volver arriba
Comprueba el número de rebotes
En ocasiones, un error de configuración tanto del lado del remitente como del destinatario
puede provocar un rebote suave o incluso un rebote duro.
Es recomendable revisar la cantidad de mensajes rebotados durante la última semana
para comprobar si los valores son los mismos que antes o si hay alguna anomalía.
Si algo falla, lo notará de inmediato. Analizar los detalles de los rebotes le ayudará a encontrar la causa.
Algunos sistemas permiten definir el número de días (por ejemplo, 180)
tras los cuales se descarta la información de rebote de un suscriptor.
De esta forma, el servidor SMTP intentará contactar de nuevo con ese destinatario.
Los bloqueos activados por error se eliminarán automáticamente,
pero la reputación del servidor SMTP puede verse afectada.
» Volver arriba
Nuevas tendencias para el manejo de rebotes
En una frase: más vale prevenir que curar.

Para evitar dañar la reputación de sus servidores SMTP,
cada vez más proveedores de servicios de correo electrónico (ESP) utilizan una "lista de supresión de correo electrónico"
que actúa antes de que los mensajes lleguen al buzón del destinatario.
Cuando un cliente envía un correo electrónico que resulta en un rebote permanente,
la dirección de correo electrónico que produjo el rebote se agrega a la lista de supresión.
La lista de exclusión se aplica a todos los clientes. En otras palabras,
si otro cliente intenta enviar un correo electrónico a una dirección que figura en la lista de exclusión,
el servidor SMTP no lo enviará, ya que la dirección de correo electrónico está incluida en dicha lista.
El uso de servidores SMTP con IP dedicada puede evitar algunos problemas relacionados con el intercambio de reputación.
Por ejemplo, la lista de exclusión de correo electrónico puede limitarse a su dirección IP,
de modo que si otro cliente provoca que el servidor SMTP sea incluido en una lista negra y se produzcan los consiguientes rebotes,
sus envíos no se verán afectados.
» Volver arriba
Códigos de estado de mensajes rebotados
Los códigos de estado utilizados para identificar rebotes duros y rebotes suaves tienen la siguiente sintaxis:
status-code = class “.” subject “.” detail
Los códigos de estado constan de tres campos numéricos separados por “.”
- El primer subcódigo (clase) indica si el intento de distribución fue exitoso
- El segundo subcódigo (asunto) indica la fuente probable de cualquier anomalía en la entrega
- El tercer subcódigo (detalle) indica una condición de error específica
El subcódigo (clase) proporciona una clasificación general del estado.
Los valores enumerados para cada clase se definen de la siguiente manera en el RFC 3463 y el RFC 6522:
2.XXX.XXX Éxito (NO se envía a menos que lo solicite el remitente) Éxito especifica que el DSN está informando una acción de entrega positiva. Los subcódigos de detalle pueden proporcionar notificación de las transformaciones necesarias para la entrega. 4.XXX.XXX Fallo transitorio persistente Un fallo transitorio persistente es aquel en el que el mensaje tal como se envió es válido, pero la persistencia de alguna condición temporal ha causado el abandono o retraso de los intentos de enviar el mensaje. Si este código acompaña a un informe de fallo de entrega, el envío futuro puede ser exitoso. 5.XXX.XXX Fallo permanente Un fallo permanente es aquel que no es probable que se resuelva reenviando el mensaje en el formato actual. Se debe realizar algún cambio en el mensaje o el destino para una entrega exitosa.
Algunos ejemplos de código y descripción:
2.0.0: Enviado (Mensaje aceptado para entrega) 4.2.2: Cuota excedida 4.4.5: Espacio en disco insuficiente 5.0.0: Nombre de dominio no válido 5.1.1: Usuario desconocido 5.7.1: Contenido del mensaje rechazado
» Volver arriba
Cómo comprobar si mi SMTP es seguro
Ante el creciente número de ataques de ransomware en la década de 2020
, ¿es seguro el correo electrónico, nuestro principal canal de comunicación en Internet?
Los servidores SMTP constituyen una infraestructura especialmente sensible.
Pueden difundir mensajes de correo electrónico en nuestro nombre,
que nuestros interlocutores aceptan como provenientes de remitentes de confianza
porque el servidor remitente los autentica correctamente.
Los servidores SMTP constituyen una infraestructura especialmente sensible.
Envían mensajes de correo electrónico en nuestro nombre,
que nuestros interlocutores aceptan como provenientes de remitentes de confianza
porque han sido autenticados correctamente por el servidor SMTP del remitente.
¿Qué sucede si otra persona usa tu servidor SMTP?
¿Cómo puedo comprobar si mi servidor SMTP es seguro?
El uso de infraestructuras sensibles en Internet
requiere un alto nivel de protección para prevenir abusos.

Si intentas enviar mensajes a través de smtp.gmail.com,
serás bloqueado y recibirás esta "Alerta de seguridad crítica":
Aplicación menos segura bloqueada. Google bloqueó la aplicación que intentabas usar porque no cumple con nuestros estándares de seguridad. [...]
La única alternativa es utilizar OAuth2, un protocolo que no comparte datos de contraseña,
sino que utiliza tokens de autorización para demostrar la identidad.
Los servidores de correo más utilizados en Internet (datos de agosto de 2021) son:
Exim (58%), Postfix (35%), Sendmail (4%).

Para seguir utilizando su propio servidor de correo
y reducir el riesgo de ser pirateado, los requisitos mínimos que debe comprobar son:
-
Solo se acepta autenticación segura.
El nombre de usuario y la contraseña deben transmitirse a través de conexiones seguras,
normalmente el puerto 587+TLS , el puerto 25+TLS o el puerto 465+SSL.
Las comunicaciones de datos confidenciales en texto plano están deshabilitadas.
-
Debe haber una verificación en la dirección "Mail-From" (el remitente),
solo aquellos que usted haya autorizado podrán pasar.
-
Configure Fail2ban para bloquear todos los ataques externos
y así evitar intentos de forzar sus protecciones.
En particular, Fail2ban debe bloquear todos los intentos repetidos:
- iniciar sesión con un nombre de usuario o contraseña incorrectos
- enviar correos electrónicos con un remitente no autorizado
- Interrumpir la conexión SMTP durante el proceso de autenticación
(varias conexiones interrumpidas hacen que el servicio SMTP no esté disponible para los usuarios legítimos).
El bloqueo suele producirse entre tres y diez intentos
y prohíbe la dirección IP de origen durante un período de entre tres y veinticuatro horas.
Es bastante sencillo comprobar estos puntos y decidir si
su infraestructura SMTP requiere o no una actualización de seguridad.
Fail2ban protege tu servidor contra ataques de fuerza bruta/DDoS.
Funciona como si, cuando un desconocido llama a la puerta,
tras un cierto número de intentos, la puerta desapareciera.

Un testimonio de Hacker News:
Llevo varios años gestionando mi propio servidor de correo y creo que muchos otros aquí utilizan soluciones como Mail-in-a-box, mailcow, Mailu, etc. Hasta la pandemia, nunca tuve grandes problemas con mi servidor de correo, pero en las últimas semanas he recibido un tráfico entrante muy elevado, demasiado para mi servidor, y he tenido que reiniciarlo manualmente cada vez... [...] Edición: He cambiado la configuración de fail2ban y he descubierto que mi objetivo principal son los ataques de fuerza bruta, contra los que debería poder protegerme con herramientas como fail2ban
Fail2ban es una aplicación de análisis de registros que monitoriza los registros del sistema
en busca de síntomas de un ataque automatizado.
Cuando se detecta un intento de abuso,
Fail2ban, utilizando los parámetros definidos, añade una nueva regla al cortafuegos (iptables o firewalld)
para bloquear la dirección IP del atacante, ya sea durante un tiempo determinado o de forma permanente.
Fail2ban también puede avisarle por correo electrónico cuando se produzca un ataque.
Fail2ban se centra principalmente en ataques SSH, aunque puede configurarse
para funcionar con cualquier servicio que utilice archivos de registro y que pueda ser vulnerable a una brecha de seguridad.
Es de uso generalizado. Si lo buscas en Google, es fácil encontrar
ejemplos de configuración para proteger servidores de correo.
Configuración DNS para enviar correos electrónicos
¿Qué configuración DNS de dominio se requiere para enviar correos electrónicos?
Los proveedores de servicios de correo electrónico suelen exigir que verifiques el dominio del remitente
antes de usar sus servidores SMTP. Hay dos razones para esto:
-
Demuestra la propiedad del dominio
gestionando el DNS; así demuestras que controlas el dominio del remitente,
lo que significa que no estás utilizando el dominio de otra persona (suplantación de identidad).
-
Al enviar correos electrónicos autenticados
mediante la configuración de la autenticación SPF y DKIM, sus mensajes
serán reconocidos por los destinatarios como provenientes de un remitente "real"
si su dominio y su proveedor SMTP tienen una buena reputación;
los mensajes deberían llegar a la bandeja de entrada de los destinatarios.
Resumen:
Proveedores de servicios de correo electrónico: requisitos para remitentes verificados
A continuación, presentamos algunos de los principales proveedores que verificamos, en orden alfabético.
A finales de julio de 2021, probamos la configuración básica necesaria para comenzar a enviar correos electrónicos.
El dominio verificado fue “emailperfect.com”. Fue registrado en 2012 y nunca se había utilizado para enviar correos electrónicos.
| Nombre del proveedor |
Alineación de dominio "From" de DKIM
|
Alineación de dominio SPF “Mail-From”
|
Notas |
| Amazon SES |
Sí (3 registros CNAME) |
NO (@amazonses.com) |
|
| Pistola de correo |
Sí (registro TXT) |
Sí (registro TXT) |
Comprobación de entrega de Hotmail y Yahoo* |
| Correo a reacción |
Sí (registro TXT) |
NO (@mailjet.com) |
Comprobación de entrega de Hotmail y Yahoo* |
| RealSender |
Sí (2 registros CNAME) |
Sí (registro TXT) |
dirección IP dedicada |
| Sendgrid |
Sí (2 registros CNAME) |
Sí (registro CNAME) |
Verificación de entrega de Hotmail* |
Sendinblue |
NO (sendinblue.com) |
NO (@aa.d.sender-sib.com) |
No se requiere verificación del remitente |
| Smtp2go |
Sí (1 registro CNAME) |
Sí (registro CNAME) |
|
* = Enviamos un mensaje a cada uno de los siguientes buzones de correo y anotamos si algo sugería que volviéramos a revisarlos:
Gmail, Hotmail, Yahoo, Gmx, Aruba, Tiscali, Exchange Online
¿Por qué es tan importante un remitente verificado?
En 2021, consideramos obligatorio autenticar el dominio del remitente
para que el destinatario sepa que la dirección de correo electrónico del remitente no ha sido falsificada.
La verificación de autenticación preventiva también reduce considerablemente el riesgo de abuso de los sistemas de envío.
Por este motivo, hemos “eliminado” a un proveedor de la lista:
no requiere la validación del dominio antes de permitirle enviar mensajes.
¿Qué es la alineación de dominios?
Al enviar un mensaje, estamos tratando con dos dominios:
- en la dirección From del remitente, que es visible para los destinatarios
- en la dirección Mail-From (también llamada “remitente del sobre” o “ruta de retorno”),
que está oculta y es administrada directamente por el ESP para recibir los correos rebotados.
El requisito de “alineación de dominio” se resume en esta frase:
“cuando un remitente autentica su correo electrónico mediante SPF y/o DKIM,
al menos uno de los dominios debe coincidir con el dominio del remitente”.
¿Registro CNAME o registro TXT? ¿Cuál es mejor?
Para la autenticación DKIM, un registro CNAME es más fácil de implementar. Si bien
se puede lograr el mismo resultado agregando un registro TXT de 2048 bits, este proceso es más complejo.
Además, la delegación del registro DKIM mediante CNAME permite que su proveedor
modifique su clave cuando sea necesario por motivos de seguridad.
Para la autenticación SPF mediante un registro CNAME, la dirección Mail-From
será un subdominio administrado por su proveedor de correo electrónico, como por ejemplo: bounce.your-company-name.org.
El proveedor se encargará tanto de la autenticación SPF como de los mensajes rebotados.
El registro TXT para la autenticación SPF es la mejor opción con servidores de correo electrónico como Zimbra o Exchange,
donde cada remitente recibe directamente los mensajes devueltos.
Solo existe un registro TXT para la autenticación de dominio,
lo que puede dificultar su mantenimiento si se administran varios servidores SMTP.
¿Qué es una dirección IP dedicada?
La “dirección de protocolo de Internet” o “dirección IP”
es similar a un número de teléfono en su teléfono fijo o dispositivo móvil.
La mayoría de los servicios SMTP proporcionan direcciones IP compartidas a sus clientes.
Cada vez que se envía un correo, se le asigna una dirección IP diferente.
Una “dirección IP dedicada” significa que su dirección IP de envío de correo electrónico no cambiará con el tiempo.
Esto proporciona un gran control sobre la reputación del remitente, que no se verá perjudicada por el uso de direcciones IP ajenas.
¿Deberíamos gestionar directamente la configuración DNS del dominio de la empresa?
No necesariamente, porque requiere ciertas habilidades técnicas.
La dirección de la empresa debe tener en cuenta que unos pocos cambios en la configuración DNS
pueden acarrear graves consecuencias, tales como:
- redirigir a los visitantes del sitio web a otro servidor web
- redirigir los mensajes entrantes a un servidor de correo diferente
- romper la autenticación de correo electrónico para que los mensajes se consideren spam o sean rechazados
» Volver arriba
Cómo gestionar listas de correo
¿Cómo gestionar listas de correo con visión de futuro?
-
En primer lugar, ¿por qué usar un gestor de listas de correo?
Los sistemas CRM (como Salesforce y Microsoft CRM)
y los correos electrónicos empresariales (como Office 365 y Google Gmail)
no son adecuados para envíos masivos.
Fueron creados para la comunicación individual.
A menudo, para evitar abusos, imponen límites de envío diarios.
Muchas veces, las empresas necesitan enviar correos electrónicos a la mayoría de sus contactos o a grupos seleccionados.
Los envíos masivos deben gestionarse con sistemas específicos,
capaces de procesar grandes volúmenes de mensajes y de cancelar suscripciones automáticamente.
-
Segundo paso: ¿dónde encontrar estas soluciones?
La respuesta más sencilla es buscar ofertas de SaaS (Software como servicio)
. Mailchimp es el sistema más conocido; Inxmail, menos conocido, lo utilizan grandes empresas.
La elección entre la instalación local y los servicios en la nube siempre es importante.
Consideramos que la opción local ayuda a recuperar el control del correo electrónico, algo que promovemos.
Incluso si decide utilizar una aplicación autohospedada en la nube,
podrá cambiar de proveedor fácilmente manteniendo la misma solución.
-
Tres soluciones merecen ser mencionadas:
- Sendy es un producto maduro, pero de código cerrado y de pago.
- Listmonk es de código abierto. La versión 1 se lanzó en 2021. Ha sido desarrollado en Go,
se distribuye como un binario independiente y su única dependencia es una base de datos PostgreSQL. En GitHub tiene 5400 estrellas.
- Mailtrain también es de código abierto. La primera versión se lanzó en 2016 y la versión 2 en 2021.
Utiliza una base de datos MySQL. En GitHub tiene 4800 estrellas.
En nuestra búsqueda de una interfaz limpia, una solución centrada en listas, fácil de mantener
y fácil de restaurar en caso de problemas, hemos considerado listmonk como la mejor opción.
Listmonk es un gestor de listas de correo y boletines informativos autohospedado y de alto rendimiento. Se distribuye como un binario independiente y su única dependencia es una base de datos Postgres.

Primeros pasos de la solicitud
Este es el anuncio original en Hacker News:
knadh el 12 de julio de 2019 [–] Autor aquí. Para dar algo de contexto sobre por qué se creó listmonk, en el trabajo (negocio financiero regulado), tenemos que enviar correos electrónicos, principalmente actualizaciones importantes, a más de 1,5 millones de clientes regularmente. Usamos phpList durante mucho tiempo y luego probamos MailTrain y Sendy antes de finalmente decidir reinventar la rueda después de encontrar una serie de problemas, de los cuales, algunos de los más importantes se mencionan a continuación. - Rendimiento. Cantidades de tiempo irrazonablemente largas para enviar correos electrónicos. phpList se degradó hasta el punto de tardar varios días en procesar una campaña. listmonk puede generar N goroutines (~hilos) y enviar correos electrónicos a múltiples servidores SMTP. En una instancia EC2 estándar, podemos enviar más de 1,5 millones de correos electrónicos en un par de horas. - Las importaciones de suscriptores eran extremadamente lentas. La integración directa para mantener a los suscriptores sincronizados con CRM externos era engorrosa. Las inserciones directas en la base de datos eran complicadas debido a las complejas estructuras de las tablas. listmonk importa 10 000 registros/segundo a una base de datos Postgres en una instancia EC2 estándar. - Segmentación. A menudo, tenemos que segmentar rápidamente a los usuarios por atributos y condiciones personalizadas y enviarles una actualización. listmonk admite expresiones SQL para segmentar a los usuarios según sus atributos definidos como mapas JSON arbitrarios (gracias al tipo JSONB de Postgres). - Indisponibilidad de plantillas dinámicas. Las plantillas de listmonk admiten expresiones de plantilla de Go, por lo que es posible escribir lógica en los mensajes para hacerlos dinámicos.
Kailash Nadhes un desarrollador muy activo en el ámbito del software libre y de código abierto (FOSS).
Trabaja en Zerodha, la mayor correduría de bolsa de la India.
El blog del equipo técnico de Zerodha se publica en zerodha.tech.
Los detalles
Listmonk está bien documentado para su uso estándar (a través de una interfaz web) y para desarrolladores (a través de una API).

Esta solución es adecuada tanto para listas extensas (de hasta millones de suscriptores) como para grupos pequeños. Gracias a la función de consulta y segmentación de suscriptores , permite consultar y exportar una selección de suscriptores según sus perfiles y atributos. Los datos extraídos se pueden importar fácilmente a una nueva lista de correo segmentada.
Carece de algunas características importantes, como el manejo de rebotes de correo electrónico.
Pero debería estar disponible en la próxima versión principal:
Procesamiento de rebotes n.° 166.
Vista previa de la captura de pantalla del procesamiento de rebotes.
Consideraciones técnicas
Anteriormente utilizamos otra aplicación Go: RealSender - DMARC REPORTS.
Fuente: dmarc-report-converter. Funcionó de inmediato sin ningún problema.
"PostgreSQL, sistema de gestión de bases de datos con más de dos décadas de desarrollo, es actualmente la base de datos de código abierto más avanzada disponible." -- Breve historia de PostgreSQL - https://www.postgresql.org/docs/9.3/history.html
Tuvimos algo de experiencia con eso cuando trabajamos en el pasado con la instalación del servidor Inxmail Professional.
En 2017, Inxmail GmbH anunció que solo admitiría PostgreSQL, dejando de lado todas las demás bases de datos:
A partir del 1 de enero de 2019, nos centraremos en la base técnica óptima y dejaremos de ofrecer soporte para servidores Windows, así como para bases de datos MySQL, Oracle y MS SQL Server. Esto significa que solo ofreceremos soporte para Inxmail Professional en servidores Linux y PostgreSQL. -- Solución de licencia de Inxmail Professional: Cambios en nuestro soporte de sistema https://www.inxmail.de/files/files/de/downloads/Inxmail-Professional-licence-solution-EN.pdf
Sin duda, es una buena opción y una inversión en conocimientos valiosos para quienes se inician en este campo.
Los cursos en línea de Udemy pueden ayudar con la instalación inicial y el mantenimiento de PostgreSQL.
El código abierto conlleva riesgos: ¿se mantendrá en el futuro un proyecto reciente, lanzado en 2019?
Nadie lo sabe, tal vez en el peor de los casos algún otro desarrollador se encargue de él, pero:
- Parece esencial en sus características, si es demasiado complejo se vuelve difícil de mantener
- Enviamos un informe de error para Listmonk y recibimos una respuesta del desarrollador en dos horas.
- El autor trabaja en una gran empresa que lo utiliza internamente
Entregabilidad de correo electrónico
Capacidad de entrega de correo electrónico: preguntas y respuestas
hemancuso el 12 de julio de 2019 [–] Los proyectos como este parecen una gran idea, pero la entregabilidad parece una gran preocupación que es difícil de medir a menos que tengas una cantidad razonable de experiencia. ¿Cuáles son las mejores prácticas para usar/seleccionar un ESP si usaras un proyecto como este y quisieras asegurar una entregabilidad razonable? knadh el 12 de julio de 2019 [–] Autor aquí. Hemos estado usando listmonk en producción en nuestra empresa (negocio financiero regulado) para entregar actualizaciones por correo electrónico, incluidas las regulatorias, durante más de 6 meses. Alojamos nuestras propias instancias SMTP usando Postal en instancias EC2 y nunca hemos tenido ningún problema con la entregabilidad. Si es correo electrónico legítimo, no creo que sea un gran problema.
Coincidimos en que enviar las comunicaciones previstas a los clientes debería ayudar a evitar la mayoría de los problemas de entrega.
Según nuestra experiencia, cuanto mayor sea el número de mensajes, mayor será la probabilidad de que surjan inconvenientes.
Los servidores AWS EC2 suelen estar en la lista negra de Gmail; todos los mensajes enviados terminan en la carpeta de spam.
RealSender ofrece servidores SMTP IP dedicadosque
operan en un entorno fiable y constantemente monitorizado.
Acerca del nombre

goberoi el 13 de julio de 2019 [–] Pregunta totalmente aleatoria: ¿cómo elegiste el nombre? knadh el 13 de julio de 2019 [–] No lo recuerdo bien, pero creo que el proceso de pensamiento fue algo así como "gestión de listas sin complicaciones y pacífica".
Vamos a intentarlo
Puedes obtener una instalación de demostración funcional en minutos usando la imagen de Docker.
Alternativamente, puedes solicitar a RealSender una cuenta de demostración de Listmonk.
» Volver arriba
Cómo enviar boletines informativos
Tras ser incluido en la lista negra, el servicio de atención al cliente de un importante servicio antispam suele responder:
"Por favor, revise la higiene de su lista para asegurarse de que los destinatarios estén interesados en sus correos".
La “higiene de la lista” y el “interés de los destinatarios” tienen muchas facetas:
A - en el lado de la MÁQUINA - “higiene de listas”
-
Suscripciones y cancelaciones bien gestionadas:
el suscriptor debe haber validado su dirección de correo electrónico (doble confirmación),
los destinatarios deben poder cancelar su suscripción (cancelación de suscripción) de forma fácil y segura.
-
Enviar solo a destinatarios "activos" y totalmente comprometidos.
No enviar repetidamente a destinatarios con buzones llenos o inactivos.
Dejar de enviar a destinatarios inactivos si no interactúan, es una clara señal de falta de interés.
-
El contenido debe estar bien paginado (no una sola imagen) y ser adaptable para que se pueda leer en varios dispositivos;
de lo contrario, los filtros de spam podrían bloquear el mensaje antes de que llegue a la bandeja de entrada del destinatario.
-
Asegúrese de que las máquinas reconozcan quién envía
el correo electrónico. La autenticación permite que los servidores de correo de destino identifiquen los mensajes como enviados por remitentes de confianza.
B - en el lado HUMANO - “el interés de los destinatarios”
-
Los suscriptores deben esperar el contenido que reciben;
los destinatarios deben estar esperando con interés su mensaje y apreciarlo.
-
Las respuestas de los usuarios deben gestionarse;
a veces algo sale mal o simplemente algún destinatario necesita comunicarse contigo,
tal vez solo para decirte que no desea recibir más mensajes, incluso si hay un enlace para darse de baja.
Lado de la MÁQUINA - “higiene de listas”
Los puntos mencionados anteriormente se pueden gestionar fácilmente con listas pequeñas, de unos pocos cientos de destinatarios.
A menudo, el remitente los conoce personalmente, ya que son clientes o miembros de una asociación.
La situación se complica cuando la lista es más extensa, con miles de destinatarios
y más personas trabajando en los envíos.
En este caso, es imprescindible utilizar herramientas profesionales.
En Internet existen muchas soluciones profesionales para el marketing por correo electrónico;
la más conocida internacionalmente es MailChimp
, y muchos sitios web también enumeran alternativas a MailChimp.
La misión de EmailTrends es "recuperar el control del correo electrónico",
por eso sugerimos una alternativa.
Según W3Techs, WordPress impulsa el 40% de todos los sitios web en Internet
y es la tecnología más popular en toda Internet dentro de la categoría de código abierto.

Con más de 200.000 instalaciones activas, Mailpoet
es uno de los plugins de WordPress más utilizados para el envío de boletines informativos.
MailPoet es un software de código abierto y, desde finales de 2020,
forma parte de las empresas vinculadas a Automattic, la empresa matriz de WordPress.
Algunas capturas de pantalla pueden darte una idea de cómo se cumplen los distintos puntos:
suscripciones y cancelaciones de suscripciones

receptores plenamente comprometidos

cambiar el estado del suscriptor a "Rebotado"

plantillas de correo electrónico responsivas

Mailpoet tiene un modelo de negocio "freemium", que te permite elegir la opción:
"Solo quiero la versión Premium sin envíos".
El servidor SMTP dedicado de RealSender se puede configurar mediante la opción «Enviar con… > Otro».
El complemento «Bounce Handler MailPoet», junto con los buzones de correo para boletines informativos proporcionados por RealSender,
garantizará la autenticación correcta de los mensajes de correo electrónico enviados.
» Volver arriba
El lado humano: “el interés de los destinatarios”
El aspecto humano es más difícil de lograr,
y es precisamente ese aspecto el que marca la diferencia
cuando la gestión técnica no es perfecta.

“SÉ RELEVANTE”
es un eslogan que se utilizó hace algunos años en el marketing por correo electrónico.
Cuando envías información valiosa a personas
que conoces profundamente después de haber hablado con ellas durante mucho tiempo,
no importa lo malo que sea el formato
o si el mensaje termina en la carpeta de correo no deseado.
Siempre perdonarán las imperfecciones técnicas,
estarán esperando tus correos electrónicos, los leerán
y, si es necesario, harán clic en el botón "no es spam".
» Volver arriba
cómo enviar CORREOS ELECTRÓNICOS PRIVADOS
¿Cómo enviar correos electrónicos privados y cifrados?
El correo electrónico no es privado ni seguro.
No fue diseñado teniendo en cuenta la privacidad ni la seguridad.
Cualquier persona que gestione tu correo electrónico durante su transmisión puede leerlo,
incluyendo tu proveedor de servicios de Internet, un pirata informático o la NSA (Agencia de Seguridad Nacional de Estados Unidos).
Resumen:
¿Qué está pasando hoy?

en el lado “legal”
“El valor de cualquier información solo se conoce cuando se puede conectar
con algo más que llegue en un momento futuro.
Como no se pueden conectar puntos que no se tienen, esto nos lleva a un modo en el que,
fundamentalmente, intentamos recopilarlo todo y conservarlo para siempre.”
“Han dicho que solo son metadatos, que solo son metadatos, […]
con quién hablas, cuándo hablas con ellos, adónde has viajado.
Todos estos son eventos de metadatos.
PRISM trata sobre el contenido. […] Todos pueden verlo porque no está cifrado.”
Existen decenas de estudios psicológicos que demuestran
que cuando alguien sabe que puede estar siendo vigilado,
su comportamiento se vuelve mucho más conformista y sumiso.
[…] La vigilancia masiva crea una prisión mental […]
del lado “ilegal”
Los estafadores también podrían utilizar software malicioso para infiltrarse en la red informática de una empresa
y acceder a los correos electrónicos relacionados con asuntos financieros.
El fraude por correo electrónico empresarial (BEC, por sus siglas en inglés), también conocido como fraude por vulneración de cuenta de correo electrónico (EAC, por sus siglas en inglés),
es uno de los delitos cibernéticos más perjudiciales económicamente.
En una estafa BEC, los delincuentes envían un correo electrónico que parece provenir de una fuente conocida y
que realiza una solicitud legítima […]
volver arriba
los desafíos
Anonimato y confidencialidad
El anonimato es diferente de la confidencialidad
[...] encriptamos los mensajes
para que, aunque la gente vea que hemos enviado un mensaje,
no pueda leer su contenido,
pero a veces ni siquiera queremos que la gente vea que hemos enviado un mensaje.
El anonimato en Internet es difícil de lograr.
Requiere un conocimiento profundo de las herramientas que se decidan utilizar.
Esta guía podría darte una idea de su complejidad:
Proveedores de correo electrónico privado
La confidencialidad es más fácil de conseguir.
Aunque no tengas nada que ocultar, usar el cifrado
ayuda a proteger la privacidad de las personas con las que te comunicas
y dificulta la labor de los sistemas de vigilancia masiva.
Si tienes algo importante que ocultar, no estás solo;
estas son las mismas herramientas que utilizan los denunciantes para proteger su identidad
mientras sacan a la luz abusos contra los derechos humanos, corrupción y otros delitos.
El primer paso fundamental es protegerse
y dificultar al máximo la vigilancia de sus comunicaciones.
Cifrado de extremo a extremo
El cifrado de extremo a extremo (e2ee) para correo electrónico se puede utilizar para garantizar
que solo el remitente y los destinatarios de un mensaje puedan leer su contenido.
Sin esta protección, los administradores de red, los proveedores de correo electrónico y las agencias gubernamentales pueden leer fácilmente sus mensajes
Lograr el cifrado de extremo a extremo requiere precaución tanto por parte del remitente como del destinatario.
Un solo error de cualquiera de las partes involucradas puede ser suficiente para comprometer la seguridad del cifrado de extremo a extremo.
Los metadatos del correo electrónico, como la dirección del remitente, la del destinatario, la fecha y la hora, no se pueden proteger mediante el cifrado de extremo a extremo (e2ee).
El asunto del correo también puede quedar desprotegido y ser fácilmente legible, incluso cuando se utiliza e2ee.
volver arriba
las soluciones

<técnico> Pretty Good Privacy - también conocido como PGP
El software PGP sigue el estándar de cifrado OpenPGP
(RFC 4880) para cifrar y descifrar datos.
PGP cifra el cuerpo de tu correo electrónico en un código
que solo la persona autorizada puede leer.
PGP funciona en prácticamente cualquier ordenador o smartphone.
Su licencia es gratuita y no cuesta dinero.
Cada usuario tiene una clave pública y una clave privada únicas,
que son cadenas aleatorias de números.
Tu clave pública no es como una llave física, ya que se encuentra en un directorio en línea donde cualquiera puede descargarla.
Las personas usan tu clave pública, junto con PGP, para cifrar los correos electrónicos que te envían.
Tu clave privada es más bien como una llave física, ya que la guardas para ti (en tu ordenador).
Utilizas PGP y tu clave privada para descifrar los correos electrónicos cifrados que te envían otras personas.
Si un correo electrónico cifrado con PGP cae en manos equivocadas, simplemente parecerá ilegible.
Sin la clave privada del destinatario real, es prácticamente imposible leerlo.
Para protegernos de la vigilancia, debemos aprender cuándo usar PGP
y empezar a compartir nuestras claves públicas siempre que compartamos direcciones de correo electrónico.
<técnico> Cómo usar el cifrado PGP
Para usar PGP, necesitarás una clave pública y una clave privada (conocidas como par de claves).
Cada una es una larga cadena de números y letras generados aleatoriamente que son únicos para ti.
Tus claves pública y privada están vinculadas mediante una función matemática especial.
Se requiere una aplicación que gestione las claves y el cifrado/descifrado de mensajes;
esta es una selección de las más populares:
< fácil > Alternativas al cifrado PGP
PGP es la mejor solución para comunicaciones seguras con un socio que ya lo utiliza.
Convencer a tu contraparte para que empiece a usar PGP puede resultar complicado.
Los servicios que permiten compartir un secreto solo una vez son una alternativa.
Al enviar algo una sola vez, existen aplicaciones web de código abierto
que permiten introducir información que solo se puede ver una vez.
Una vez que el destinatario abre la página, la información se elimina
y lo único que queda en el registro de chat o en el correo electrónico es un enlace roto.
No es tan robusto como si todo el equipo usara PGP, pero es mucho más fácil de configurar y explicar.
Lo hemos usado para enviar información de inicio de sesión a personas con pocos conocimientos técnicos, y les resulta fácil de usar.
Ejemplo (sin añadir contraseña):
Supongamos que tienes una contraseña. Quieres compartirla con tu compañera de trabajo, Jane. Podrías enviársela por correo electrónico, pero entonces estaría en su bandeja de entrada, que podría tener una copia de seguridad y probablemente se encuentre en algún dispositivo de almacenamiento controlado por la NSA. Si Jane recibe un enlace a la contraseña y nunca lo abre, la contraseña desaparece. Si la NSA obtiene el enlace y revisa la contraseña... entonces la tendrá. Además, Jane no puede obtener la contraseña, pero ahora sabe que alguien no solo está revisando su correo electrónico, sino que también está haciendo clic en los enlaces.
Algunos de estos servicios, todos gratuitos y de código abierto, se enumeran a continuación.
También puede optar por alojar una instancia en su propio servidor web.
PrivateBin (similar a una versión segura de PasteBin) está desarrollado en PHP.
El código de PrivateBin está publicado en Github (3100 estrellas).
Las instrucciones de PrivateBin están disponibles en otro sitio web.
OneTimeSecret está desarrollado en Ruby.
El código y las instrucciones de OneTimeSecret están publicados en Github - 1200 estrellas
SnapPass está escrito en Python. Fue desarrollado originalmente por Pinterest.
El código y las instrucciones de SnapPass están publicados en Github - 600 estrellas
volver arriba
Cómo enviar y limitar correos electrónicos con copia oculta (CCO)
¿Cómo enviar y limitar correos electrónicos con copia oculta (CCO)?
“Cc” significa “Carbon Copy” (Copia al carbón) en el sentido (antiguo) de hacer una copia
en una máquina de escribir usando papel carbón.
El campo “CCO:” en los correos electrónicos (donde “CCO” significa “Copia Oculta”)
contiene las direcciones de los destinatarios del mensaje
cuyas direcciones no deben revelarse a otros destinatarios del mismo.
– IETF RFC 2822 “Formato de Mensaje de Internet”
La diferencia entre CCO y CC radica en la privacidad del destinatario.
Al usar la función CC, las direcciones de correo electrónico incluidas en el campo CC
son visibles para todos los destinatarios del correo.
Un destinatario con copia oculta (CCO) puede ver al destinatario directo (Para:), pero
no podrá saber quién más recibió una copia oculta del correo electrónico.
CCO (Copia Oculta) se considera un sistema de distribución masiva de correo electrónico fácil de usar.
A continuación, se presenta un breve análisis de las ventajas y desventajas de usar CCO.
Al final de la página, encontrará las conclusiones y algunas sugerencias.
VENTAJAS
Es fácil: cualquiera puede usarlo.
- Es una forma sencilla de contactar con varios destinatarios de correo electrónico
- Cualquier persona con un cliente de correo electrónico puede utilizarlo
- Cuando se utiliza correctamente, respeta la privacidad de los destinatarios al no revelar sus direcciones de correo electrónico
volver arriba
CONTRAS
El correo electrónico es una puerta de salida sin verificación previa.
La opción CCO (copia oculta) aumenta su alcance a cientos o miles de contactos.
La copia oculta (CCO) debe considerarse una
herramienta de comunicación de alto riesgo y potencialmente peligrosa.
- Es un proceso propenso a errores, los riesgos son:
- Agregar por error destinatarios CCO en el campo CC
suele causar graves daños a la marca.
Un nuevo mensaje de disculpa es la solución más común para esta situación.
» Los nombres de todos los destinatarios se hacen públicos.
» Uso no intencionado (y a veces intencional) de "responder a todos",
lo que genera cadenas de correo electrónico incontroladas
. » Alguien podría plantear un incidente de privacidad desde la perspectiva del RGPD
si el asunto/cuerpo contiene "categorías especiales" de datos personales, identificando así
a las personas que pertenecen a la misma categoría (es decir, enfermedad, orientación o creencias).
- agregar por error a alguien como destinatario principal (visible)
- Olvidaste agregar a alguien o agregaste a alguien que no debería recibir el mensaje
- Existe una alta probabilidad de que se clasifique como spam
- El problema es que la mayoría de los spammers envían mensajes usando CCO (Copia Oculta)
y los servidores de correo de destino son cautelosos al aceptar mensajes CCO.
- Si te envío un mensaje usando CCO,
recibirás un correo electrónico que no está dirigido a ti,
lo cual es un punto negativo a la hora de evaluar el mensaje como spam.
- El mismo mensaje se enviará a "varias" direcciones de correo electrónico
pertenecientes al mismo dominio a la vez, es fácil contarlas y bloquearlas.
- No hay control sobre las direcciones incorrectas
- Puede haber direcciones de correo electrónico duplicadas o triplicadas para el mismo destinatario;
esto afecta al envío a ese destinatario, incluso si una o más direcciones son correctas.
- Las direcciones sintácticamente incorrectas se aceptan sin previo aviso,
por ejemplo, si falta el símbolo @ o hay espacios.
- Sin personalización / Bajo impacto / Pocas o ninguna reacción
- El mensaje será necesariamente estándar y “anónimo”;
no es posible la comunicación individual, no hay ningún “Estimado/a Sr./Sra.”
- Los destinatarios a los que hayas añadido una copia oculta (CCO) recibirán un mensaje dirigido a otra persona
a la que probablemente no presten atención ni reaccionen.
- Es muy probable que haya problemas técnicos
- Cualquier acción abusiva por parte de spammers o hackers puede afectar rápidamente a muchos destinatarios,
comprometiendo la reputación del servidor SMTP (es decir, incluir el servidor en una lista negra).
- El buzón del remitente podría estar saturado de correos rebotados (usuario desconocido, buzón lleno, etc.);
su número puede variar entre el 5 % y el 20 % de los correos electrónicos que se han enviado.
- El envío puede tener un impacto negativo en los sistemas de entrega de correo electrónico (servidores SMTP), por ejemplo:
muchas respuestas de "inténtelo de nuevo más tarde", gran cantidad de mensajes en la cola de correo, fallo del sistema.
volver arriba
CONCLUSIONES
- Establece los límites
- Comprueba el número de destinatarios permitidos por tu proveedor de correo electrónico.
Hazlo tú mismo para estar 100% seguro.
RealSender comparte una lista de 300 direcciones @bogusemail.net para realizar pruebas;
los mensajes llegarán a un servidor de correo "agujero negro":
bogusemail-test.txt
- Limitar el número de destinatarios en un solo mensaje a un número pequeño, como 20,
permitir más destinatarios, permite enviar fácilmente mensajes
a miles de direcciones de correo electrónico, simplemente dividiéndolas en grupos pequeños.
- Hazte profesional
- Permitir el envío masivo de correos electrónicos a través de diferentes canales únicamente
- Utilice una dirección de remitente diferente al enviar muchos mensajes,
por ejemplo, otro subdominio, como @news.companyname.com.
Solo las personas autorizadas tendrán acceso a él
y lo manejarán con mayor cuidado.
- En oficinas estructuradas, donde muchas personas trabajan con correo electrónico,
se utilizan aplicaciones específicas para enviar correos masivos.
Los sistemas profesionales cuentan con un flujo de trabajo de aprobación
y control paso a paso, y están diseñados para evitar errores.
volver arriba
medir el MARKETING POR CORREO ELECTRÓNICO
¿Cómo medir el rendimiento de tus campañas de email marketing?
La siguiente información proviene de nuestros quince años de experiencia
con la plataforma de email marketing Inxmail.
¿Qué son las campañas de marketing por correo electrónico? Son correos electrónicos masivos, basados en el consentimiento del destinatario, cuyo contenido generalmente se personaliza según sus intereses, y donde el remitente puede obtener datos de retroalimentación basados en el comportamiento de los destinatarios.
Las respuestas o “datos de retroalimentación” son la base de las métricas
que sustentan los informes sobre el rendimiento de las campañas de marketing por correo electrónico.
A continuación, explicaremos qué son y cómo se miden:
Las mejores herramientas técnicas son inútiles si los mensajes no llegan a la bandeja de entrada del destinatario.
Aquí es donde entra en juego la "entregabilidad del correo electrónico":
campañas de marketing por correo electrónico
marketing basado en permisos
El marketing basado en el permiso, también llamado "marketing de diálogo",
es un concepto introducido por Seth Godin en 1999 en su libro superventas "Marketing de permiso".
En el libro, se define como lo opuesto al "marketing de interrupción"
que se utiliza generalmente en los medios de comunicación tradicionales, como la televisión y los periódicos.
Su objetivo es crear una comunicación personal y directa,
una relación entre las dos partes y activar un diálogo “humano”
cuya experiencia sea útil y enriquecedora para ambas.
volver arriba
Seguimiento de las reacciones de los usuarios
Dependiendo de los permisos de privacidad recopilados, el remitente puede registrar:
- datos agregados
- datos del usuario individual (por ejemplo, quién abrió el correo electrónico, quién hizo clic)
Los datos agregados
proporcionan información y retroalimentación global sobre las tendencias generales
(por ejemplo, cuántas personas abrieron el correo electrónico, cuántas hicieron clic).
Los datos de usuario único
permiten obtener información individual
mediante la recopilación de datos personales y el posterior envío de mensajes personalizados,
basados en interacciones previas y el comportamiento del usuario.
volver arriba
Cómo funciona el seguimiento de usuarios
El seguimiento de enlaces consiste en reemplazar la URL final del sitio web
por una dirección ficticia, que registra la visita y redirige al usuario a la página de destino.
En los mensajes de correo electrónico, solo se pueden rastrear los clics en los enlaces.
Las imágenes externas, aquellas para las que el cliente de correo electrónico solicita confirmación antes de descargarlas,
se tratan como enlaces, por lo que basta con rastrear la URL de una imagen externa
para conocer la tasa de apertura del correo electrónico.
El seguimiento normalmente solo registra el "mailid",
un identificador único del correo que se ha enviado.
El seguimiento personalizado se logra agregando a las páginas visitadas
uno o más parámetros generados por el software,
como por ejemplo: example.com/test.html?id=54725788327466628654
el parámetro "id" se refiere a un usuario específico y un enlace particular en el mensaje.
La información obtenida puede
actualizar automáticamente los datos del destinatario en la aplicación de marketing por correo electrónico
o transmitir los detalles sobre el origen del clic a la plataforma de análisis web.
Por ejemplo: una agencia de viajes podría medir
cuántas veces el usuario hace clic en noticias sobre la playa o la montaña,
incrementando un contador específico con el tiempo.
Los datos recopilados indicarán el destino preferido del destinatario.
volver arriba
Cómo funciona la medición de la tasa de apertura
Las tasas de apertura se miden combinando los datos de los clics en los enlaces rastreados
y los "clics ocultos" generados por las imágenes rastreadas que se han descargado.
Si se abre un mensaje en la vista previa del cliente de correo electrónico,
sin descargar las imágenes ni hacer clic en ningún enlace,
no es posible saber que se ha abierto.
Desde 2003, inicialmente Outlook, y luego la mayoría de los clientes de correo electrónico,
para proteger la privacidad de sus usuarios
comenzaron a bloquear la descarga automática de imágenes
que, de otro modo, se habrían registrado por cada correo electrónico leído.
Desde 2013, las imágenes en Gmail se muestran automáticamente por defecto.
La descarga la realiza un servidor externo, llamado «proxy»,
que oculta el terminal del usuario, pero permite a los operadores de email marketing
saber que la imagen se ha descargado y el mensaje se ha abierto.
Puedes encontrar más información aquí:
Cómo funciona el nuevo proxy de imágenes de Gmail y qué significa esto para ti.
El registro de las tasas de apertura no es preciso,
ya que arroja un valor inferior al de las aperturas reales.
De todos modos, es recomendable medirlas,
aunque solo sea para comparar los resultados de diferentes campañas.
volver arriba
Entregabilidad de correo electrónico
correos electrónicos semilla
En primer lugar, es necesario comprobar si los correos electrónicos llegan a las bandejas de entrada
de los principales dominios de correo gratuito presentes en su lista
y también a la bandeja de entrada de los dos principales proveedores de buzones de correo corporativos:
Google Apps y Office 365.
Los filtros antispam activados por contenido generalmente se activan por dominios presentes en las URL (http…).
Un buen consejo es usar un solo dominio en los enlaces de tus mensajes.
El dominio debe ser el mismo que el del remitente;
esto se denomina «alineación de dominio» y reduce el riesgo de ser detectado por los filtros antiphishing.
Por la misma razón, si se rastrean los enlaces, estos deben usar un subdominio
del dominio del remitente.
Para realizar pruebas reales, basta con activar un buzón de correo de prueba para cada proveedor
y, a continuación, activar el reenvío de mensajes a tu dirección.
Envía a cada buzón un mensaje con el asunto «Mensaje de prueba»
y el contenido «Mensaje de prueba», además del enlace a tu dominio.
Si el mensaje no pasa los filtros de spam, deberías recibirlo en tu bandeja de entrada.
volver arriba
tasas de rebote
Es normal recibir correos electrónicos rebotados.
Esto puede deberse a direcciones de correo electrónico abandonadas,
buzones de correo llenos u otros problemas técnicos.
Dependiendo de la "limpieza" de tu lista,
la tasa de rebote puede variar entre el 5% y el 20%.
A medida que aumenta el número de correos, resulta imposible gestionar manualmente los correos rebotados.
Las aplicaciones de marketing por correo electrónico integran una función llamada "gestor de rebotes"
que descarga automáticamente los mensajes rechazados,
los analiza y los clasifica según su contenido.
La dirección de correo electrónico de destino se desactiva automáticamente
después de varios "rebotes permanentes", errores persistentes como usuario desconocido y host inaccesible,
o después de un mayor número de "rebotes temporales", errores transitorios como buzón lleno.
Es importante monitorear las tasas de rebote (mensajes rechazados)
o las tasas de entrega (mensajes aceptados). Su suma representa el 100%.
Un cambio en estas tasas es un síntoma que debe investigarse.
volver arriba
Indicadores de referencia del marketing por correo electrónico
Las plataformas de marketing por correo electrónico más importantes publican cifras de referencia
basadas en los datos recopilados de todos sus clientes.
Términos técnicos utilizados en los informes:
- Aperturas: número de destinatarios que han hecho clic
en al menos un enlace rastreado o han abierto al menos una imagen rastreada.
- Tasa de apertura: Aperturas / Número de destinatarios (descontando rebotes)
- Clics únicos: número de destinatarios que han hecho clic en un enlace al menos una vez
- Tasa de clics (CTR): Clics únicos / Número de destinatarios (después de descontar los rebotes)
- Tasa de clics para aperturas (CTOR): clics únicos / aperturas
Aquí hay una breve lista, la mayoría de ellas se refieren a los Estados Unidos:
volver arriba
¿Qué se considera SPAM?
¿Qué usuarios y servidores de correo se consideran correos electrónicos no deseados (spam)?
Partiendo de nuestra experiencia con RealSender,
hemos intentado resumir los puntos principales que podrían afectar a la entrega en la bandeja de entrada.
Resulta inútil evaluar los demás puntos
si los mensajes no son esperados o deseados por sus destinatarios.
Reacciones de los usuarios
El remitente debe ponerse en el lugar del destinatario e intentar prever cómo se interpretará un correo electrónico.
Las quejas de los usuarios pueden provocar que se bloquee todo el servidor SMTP o el nombre de dominio, lo que afectaría la entrega de todos los mensajes futuros.
- Los usuarios generalmente* pueden administrar su bandeja de entrada: es "spam" lo que cada usuario considera spam
* = muchos proveedores de correo gratuito NO ofrecen la opción de optar por no recibir su "publicidad interna".
- El usuario expresa su elección haciendo clic en el botón "Denunciar spam" (dentro de Gmail)
o en el botón "Correo no deseado" (dentro de Outlook/Hotmail).
- Los filtros de spam de los servidores de correo modernos están conectados a las quejas de los usuarios; después de un cierto número de clics en "Marcar como spam",
todos los mensajes con contenido similar se enviarán directamente a la carpeta de spam.
Se requieren ajustes técnicos básicos para que se acepten los mensajes de correo electrónico.
Dirección IP y reputación de la clase IP
- Bloqueo de IP de servidor SMTP: puedes encontrar muchas herramientas en línea buscando en Google "verificación de lista negra"
- Reputación de la clase IP del servidor SMTP, consulte nuestro artículo del blog para obtener más información LA REPUTACIÓN DE LA IP SMTP IMPORTA
- Si los mensajes se envían desde un ordenador personal, también se debe comprobar la reputación de la dirección IP pública de la conexión a Internet
(algunos proveedores de servidores SMTP enmascaran la dirección IP de la conexión a Internet, de modo que el sistema del destinatario solo ve su dirección IP).
Configuración correcta del servidor SMTP
- DNS inverso
para asegurarse de que la dirección IP de su servidor de correo apunte al nombre de dominio que utiliza para enviar correo.
- El agente de transferencia de correo, la aplicación que enruta y entrega el correo electrónico,
debe configurarse correctamente, siguiendo el último RFC publicado por la IETF
(véase, por ejemplo: Making Postfix RFC Compliant)
Autenticación de correo electrónico correcta
Utiliza métodos de autenticación de correo electrónico, como SPF y DKIM, para demostrar que tus correos electrónicos y tu nombre de dominio están relacionados.
Además, esto ayuda a prevenir la suplantación de identidad de tu dominio de correo electrónico.
- SPF es un protocolo de autenticación de correo electrónico basado en rutas que permite a los receptores determinar si el remitente está autorizado a usar los dominios en el encabezado del mensaje, evaluando la dirección IP del servidor de correo saliente del remitente a partir de la información publicada por este en los registros DNS TXT. SPF está definido en el RFC 4408 de la IETF.
- DKIM es un protocolo de autenticación de correo electrónico que permite al remitente firmar los correos salientes mediante criptografía de clave pública, de forma que el destinatario pueda verificar su autenticidad. DKIM se define en el RFC 4871 de la IETF. Gmail y otras grandes empresas han adoptado el estándar DKIM para eliminar por completo el phishing y la suplantación de identidad en el correo electrónico.
- DMARC se basa en los estándares SPF y DKIM para la autenticación de correo electrónico. Los servidores de correo de destino procesan los correos no autenticados según la política DMARC del remitente e informan del resultado. DMARC se define en el documento RFC 7489, publicado por el Grupo de Trabajo de Ingeniería de Internet (IETF).
Comprobación de SPAMASSASSIN
- SpamAssassin es un software del lado del servidor que se utiliza para filtrar el correo no deseado. Emplea diversas técnicas de detección de spam.
Cada prueba tiene una puntuación. Las puntuaciones pueden ser positivas o negativas: las positivas indican spam y las negativas, correo legítimo (no spam).
El umbral de puntuación predeterminado para el destinatario es de 5.0. Si la puntuación de un correo electrónico supera este umbral, se marca como spam.
Su uso está tan extendido que la comprobación de la puntuación antes de enviar correos electrónicos debería considerarse obligatoria.
- Dos herramientas en línea pueden ayudarte a comprobar tu puntuación en SpamAssassin: noes spam y probador de correo
- Debes enviar el mensaje a la dirección de correo electrónico proporcionada
- Después de unos segundos, haga clic en el botón "Ver su informe" o en el botón "Comprobar su puntuación".
La única forma infalible de saber si un correo electrónico se clasifica como spam es...
enviarlo y ver cómo aparece en el otro extremo.
Inténtalo y verás qué pasa
- Si recibes un mensaje rebotado, esto puede ser de gran ayuda, ya que las últimas líneas suelen describir el problema que provocó el rechazo.
Si la explicación es incomprensible, simplemente intenta enviar un mensaje con el asunto y el contenido «Mensaje de prueba» y comprueba si se acepta.
En este caso, deberías enviar el mismo mensaje varias veces, reduciendo gradualmente el contenido, hasta identificar qué parte activa el filtro de spam.
- Disponer de un registro de envíos detallado puede ayudarle a verificar si los mensajes son aceptados o rechazados;
ejemplos de información disponibles en el registro.
- En algunos casos (poco frecuentes), se requiere una especie de "lista blanca".
Algunos sistemas antispam aprenden de la interacción de los usuarios con los mensajes que reciben.
Si el destinatario marca el correo como no spam,
el sistema lo reconocerá como mensajes válidos y comenzará a entregarlos en la bandeja de entrada en lugar de en la carpeta de correo no deseado.
Alternativamente, el remitente debe estar en la libreta de direcciones del destinatario o haber intercambiado correos electrónicos previamente con él.
CLIENTES DE CORREO ELECTRÓNICO DE CÓDIGO ABIERTO
¿Cómo recuperar el control del correo electrónico utilizando clientes de correo electrónico de código abierto listos para usar?
En la última década, hemos visto un cambio casi completo en los buzones de correo corporativos,
pasando de servidores de correo locales a servicios en la nube como Exchange Online (Office 365) o Gmail para empresas (Google Apps).
Las principales razones son:
- la necesidad de acceder a los correos electrónicos desde interfaces móviles y web
- la necesidad de proteger los buzones de correo del spam y el malware
De esta forma, la vida de los profesionales de TI se ha simplificado al delegar
la responsabilidad de gestionar la infraestructura de correo electrónico en las "grandes empresas tecnológicas".
El riesgo de abandonar las habilidades básicas de correo electrónico puede llevarnos a pensar que el correo electrónico
funciona por arte de magia, simplemente porque Microsoft y Google se encargan de ello.
Podemos recuperar el control del correo electrónico desglosando los componentes de mensajería y gestionándolos individualmente:
- el servidor de correo entrante
- el cliente de correo electrónico
- el servidor de correo saliente
Esto crea aislamiento y segmentación de servicios, lo que beneficia enormemente la seguridad.
Por lo tanto, reducir la superficie de ataque mediante el aislamiento y la segmentación se considera una buena práctica.
Además, aumenta la escalabilidad y la estabilidad.
Los clientes de correo electrónico son la interfaz principal de los buzones de correo. Son un software complejo que interactúa con los usuarios.
Existen muchas soluciones disponibles en el mercado; las hemos seleccionado en función de dos requisitos:
- proyectos multiplataforma, gestionados activamente y de código abierto
- listos para usar, para que los administradores del sistema puedan gestionarlos fácilmente
Se nos ocurrieron dos opciones:
-
Mozilla Thunderbird es un cliente de correo electrónico multiplataforma de código abierto para ordenadores personales. Desarrollado por la Fundación Mozilla,
es compatible con IMAP y POP (almacenamiento local de correo en el disco duro para acceder a él sin conexión a internet).
Ofrece excelentes funciones de filtrado y gestión de correo.
Thunderbird permite el uso de múltiples cuentas e identidades, incluyendo firmas automáticas.
Dispone de versiones listas para instalar en Windows, Mac OS y Linux. Para acceder de forma remota, los usuarios deben conectarse primero a su ordenador.
-
La nueva bifurcación de Rainloop es un cliente de correo electrónico web sencillo, moderno, ligero y rápido. Puede gestionar un gran número de cuentas de correo electrónico sin necesidad de conexión a bases de datos. Admite los protocolos SMTP e IMAP para enviar y recibir correos electrónicos fácilmente y sin problemas. En 2020, se publicó el proyecto SnappyMail en GitHub . Se trata de una bifurcación de RainLoop Webmail Community Edition, con importantes mejoras y mayor seguridad. Aquí tienes una demostración del cliente de correo electrónico SnappyMail . Si quieres probar la interfaz de administración, contáctanos .
Correo electrónico y privacidad en el trabajo
Advertencia: este tema tiene importantes implicaciones legales. Consulte con asesores cualificados para verificar la normativa y su aplicación.
El correo electrónico profesional es una herramienta de trabajo empresarial
que contiene una cantidad impresionante de información relacionada con el negocio.
Las empresas pueden hacer lo que quieran con el correo electrónico,
que es una herramienta de trabajo empresarial, pero ¿lo escriben y leen los empleados? ¿
Pueden leerlo? ¿Pueden hacer copias de seguridad? ¿Pueden archivarlo?
Resumen:
Direcciones de correo electrónico genéricas para el trabajo, sin restricciones
El buzón de correo electrónico del trabajo tiene un carácter ambivalente:
es una herramienta propiedad del empleador, pero utilizada por el empleado.
Debemos distinguir entre dos tipos diferentes de direcciones de correo electrónico empresariales:
- Buzón de correo electrónico personal de la empresa, por ejemplo: nombre.apellido@nombreempresa.com
- Buzón de correo genérico de la empresa, como información, soporte, ventas, marketing, facturación, etc.,
es decir, todos aquellos que NO están relacionados con una sola persona.
Los buzones de correo genéricos de la empresa no presentan ningún problema;
la empresa los revisa, lee todos los mensajes y no tiene restricciones.
buzón de correo personal de la empresa, como por ejemplo los coches de empresa
Los buzones de correo personales, como por ejemplo nombre.apellido@nombreempresa.com,
pueden contener datos personales del empleado que el empleador debe proteger.
Si optamos por utilizar este tipo de buzón de correo,
como empleadores debemos saber qué estándares técnicos adoptar
y qué herramientas utilizar para poder procesar los datos adecuadamente.
El buzón de correo puede compararse con el coche de empresa;
se pone a disposición del empleado para su uso en las tareas laborales.
El empleador, por ejemplo, puede comprobar el kilometraje para verificar que el empleado
no haya hecho un uso indebido de esta herramienta de trabajo, utilizándola para fines personales.
Sin embargo, el empleador no puede controlar de forma sistemática y sin motivos específicos
lo que el empleado hace dentro del coche de empresa.
El buzón es el equivalente al coche de empresa, una herramienta de trabajo que pertenece a la empresa,
entregada al empleado para que la utilice en el trabajo, simplemente para llevar a cabo sus tareas.
Lo que el empleado envía y recibe, incluso durante el horario laboral, es como lo que ocurre
dentro de la cabina del coche de empresa y se equipara a la correspondencia privada.
volver arriba
leer solo bajo ciertas condiciones
La empresa no puede leer el contenido de los correos electrónicos;
no puede hacerlo de forma sistemática ni sin un motivo específico.
Incluso si existe una motivación concreta, solo puede hacerse bajo ciertas condiciones.
Hay tres intereses diferentes en juego, que deben equilibrarse:
- el interés del empleador en acceder a este contenido
por motivos organizativos/de producción, seguridad laboral u otros.
- la expectativa legítima de los empleados
que consideran este contenido como confidencial
- La expectativa de terceros que escriben a esa empresa es
que quizás no sepan que el contenido de su correspondencia NO es privado ni confidencial.
(El aviso legal estándar al final de los correos electrónicos suele advertir que el contenido puede ser leído por otros).
Se deberá informar al empleado, mediante comunicación escrita adecuada, de que los mensajes de correo electrónico
solo podrán utilizarse para fines relacionados con la relación laboral, por ejemplo, prohibiendo su uso personal.
El documento debe contener instrucciones sobre cómo utilizar las herramientas de la empresa,
incluido el correo electrónico, e informar que, en cumplimiento de las normas de privacidad:
- Los mensajes de correo electrónico se archivarán para cumplir con la ley y proteger los activos de la empresa
- La empresa puede, en algunos casos, realizar comprobaciones sobre el contenido del buzón de correo del empleado
Los controles masivos están prohibidos
Se prohíben los denominados “controles masivos”,
como la lectura sistemática del contenido del buzón de correo electrónico de un empleado.
Los límites al control del empleador se basan en tres principios fundamentales:
-
Una de ellas es la buena fe, que es la posibilidad de que el empleador realice una comprobación
en el buzón de correo de la empresa del empleado solo si existe una razón bien fundada,
por ejemplo, para la protección de los activos de la empresa que podrían verse comprometidos o puestos en riesgo por un virus;
o en caso de sospecha de infidelidad del empleado, para realizar comprobaciones defensivas.
-
Los demás son la proporcionalidad en el control y la limitación en el tiempo y en el objeto de la investigación.
volver arriba
obligación de archivar los mensajes de correo electrónico
Las normas exigen que el empleador demuestre
haber adoptado medidas de seguridad adecuadas y eficaces
para proteger los datos de la empresa, como el archivo de correos electrónicos corporativos.
Acceso a los datos por parte del empleador
si se realiza en ausencia de información detallada de la empresa:
-
Representa una violación muy grave
que se puedan encontrar datos sensibles en el espacio personal del empleado,
por ejemplo información sobre tendencias políticas, religiosas, sexuales o sindicales,
que debe garantizarse al más alto nivel de confidencialidad.
-
Se trata de un delito penal
y además existe el riesgo de que todos los datos obtenidos ilegalmente
resulten inutilizables en cualquier proceso legal.
obligación de eliminar los mensajes de correo electrónico
La correspondencia comercial generalmente debe conservarse durante un máximo de diez años.
Esto permite preservar los activos de la empresa y defenderse en caso de litigio.
El almacenamiento y tratamiento de datos personales solo está permitido para un fin específico.
Si dicho fin deja de existir tras un cierto periodo de tiempo, por ejemplo, después de diez años, estos datos deberán eliminarse.
obligación de desactivar los buzones de correo
En caso de despido o renuncia del empleado,
el buzón de correo electrónico nombre.apellido deberá desactivarse en un breve plazo.
La empresa puede activar una respuesta automática que informe al remitente de que la cuenta ha sido desactivada,
invitándole a escribir a otra dirección de correo electrónico interna.
El archivo histórico de mensajes de la empresa de empleados despedidos
solo se puede conservar si se informó al empleado de que sus mensajes estaban siendo almacenados.
volver arriba
Protege tus correos electrónicos del SPAM
¿Cómo proteger los correos electrónicos empresariales del spam?
Es casi imposible pensar en el correo electrónico sin considerar el problema del spam.
Hemos intentado resumir la situación actual y las estrategias que se pueden seguir:
¿Qué porcentaje del tráfico de correo electrónico es spam?
Una fuente fiable es SenderBase, ahora llamada Talos,
que muestra que aproximadamente el 85 % del correo electrónico era spam y el 15 % era legítimo,
en comparación con el tráfico de correo electrónico registrado en septiembre de 2020.
Este porcentaje se ha mantenido estable, con pocos cambios en los últimos doce meses.

Fuente: Datos de correo electrónico y spam - Volumen total mundial de correo electrónico y spam.
volver arriba
¿Cuáles son los costes del spam?
A veces, el spam solo tiene fines promocionales, y el remitente
simplemente intenta conseguir más clientes para su negocio,
lo que provoca distracciones y pérdida de tiempo. Puede saturar tu bandeja de entrada,
dificultando la búsqueda de correos importantes.
No todos los correos no deseados son mensajes promocionales amistosos.
En muchos casos, las intenciones son maliciosas y buscan dañar o secuestrar los sistemas de los usuarios.
Las variantes más comunes de correo no deseado malicioso a nivel mundial incluyen troyanos, spyware y ransomware.
volver arriba
¿Cuáles son las últimas técnicas antispam?
Imagina las bandejas de entrada de tu empresa como la puerta de tu casa:
tienes que decidir quién puede entrar y quién se queda fuera.
Ninguna técnica es una solución completa al problema del spam.
Cada una presenta ventajas e inconvenientes, como el rechazo incorrecto de correos electrónicos legítimos (falsos positivos)
frente al rechazo de spam (falsos negativos)
, además de los costos asociados en tiempo, esfuerzo y dinero derivados del bloqueo indebido de correo legítimo.
Las técnicas antispam se pueden dividir en dos áreas: prevención y cura.
Prevención de spam (antes de que ocurra)
Restringe la disponibilidad de tus direcciones de correo electrónico con el objetivo de reducir la posibilidad de recibir correo no deseado.
-
Sea discreto:
no le dé su dirección de correo electrónico a todo el mundo;
cuanto menos conocida sea, menos spam recibirá.
Siempre que sea posible, utilice un correo electrónico diferente para los registros en línea.
-
Los formularios de contacto
no publican tu dirección de correo electrónico en línea;
cualquiera puede verla. Los "spambots" las capturan constantemente
para contactarte en línea. Usa formularios web/de contacto seguros*.
* = protegidos contra robots que los completan automáticamente.
Solución al spam (mientras está ocurriendo)
Una vez que los remitentes de spam tienen tu dirección de correo electrónico, la lucha se traslada a tu servidor de correo y a tu bandeja de entrada.
-
Sistemas de puntuación tipo SpamAssassin.
Utilizan diversas técnicas de detección de spam, incluyendo listas negras de correo electrónico basadas en DNS
(comúnmente llamadas listas negras en tiempo real, DNSBL o RBL), análisis de texto y filtrado bayesiano.
Cada prueba tiene un valor de puntuación. Las puntuaciones pueden ser positivas o negativas: los valores positivos indican "spam" y los negativos "no spam".
El umbral de puntuación predeterminado para el destinatario es de 5.0. Si la puntuación de un correo electrónico supera este umbral, se marca como spam.
Existen numerosas "pruebas de SpamAssassin" disponibles en internet
que permiten a los spammers comprobar sus mensajes antes de enviarlos.
-
Impulsado por los usuarios:
Los usuarios de estos sistemas pueden marcar los correos electrónicos entrantes como legítimos o spam, y estas marcas se registran en una base de datos central.
Cuando un número determinado de usuarios marca un correo electrónico como spam, el filtro lo bloquea automáticamente para que no llegue a las bandejas de entrada del resto de la comunidad.
En ocasiones, la retroalimentación de los usuarios se integra con controles automatizados, como el número de interacciones con el contenido de los mensajes,
la cantidad de clics en enlaces e imágenes descargadas, o la cantidad de veces que aparece el mismo mensaje en varias bandejas de entrada.
Cuando un sistema de filtrado de contenido colaborativo cuenta con una base de usuarios amplia y activa,
puede bloquear rápidamente un brote de spam, a veces en cuestión de minutos.
Este tipo de filtro es prácticamente invulnerable para los spammers.
-
La autenticación de correo electrónico
mediante SPF, DKIM y DMARC permite verificar si la dirección del remitente es realmente quien dice ser.
En 2020, su uso era generalizado y constituían una buena herramienta para identificar remitentes de confianza.
Es importante conocer de antemano el dominio exacto del que provienen los correos electrónicos,
ya que un simple cambio de una letra puede engañar fácilmente al usuario.
Los spammers pueden manipular la autenticación de correo electrónico
para que sus mensajes parezcan provenir de remitentes legítimos.
-
Remitentes autorizados, lista blanca
En una lista blanca se puede especificar una serie de direcciones o dominios de confianza.
Al principio, la libreta de direcciones personal y los correos electrónicos recibidos anteriormente serán de gran ayuda.
Si un remitente está en esta lista, se omiten todos los controles y el mensaje se recibe sin demoras.
Este método es fácil de implementar y muy efectivo cuando se asocia con la autenticación de correo electrónico, para evitar la suplantación de direcciones de correo electrónico*.
* = uso de un remitente falso para que el mensaje parezca provenir de alguien que no es la fuente real.
Una vez que su lista de contactos de confianza esté completa, ningún remitente desconocido llegará a su bandeja de entrada.
Todos los mensajes no deseados se pueden redirigir a una bandeja de entrada diferente para revisarla una vez al día o con menos frecuencia. A
los spammers les resultará difícil encontrar cuáles son los remitentes de confianza de cada destinatario.
Incluso si lo hacen, las comprobaciones de autenticación de correo electrónico le alertarán sobre el uso fraudulento.
volver arriba
Cómo funciona DMARC - actualizado
¿Cómo funciona dmarc con Google Mail y Office 365? (actualizado)
Hemos vuelto a comprobar cómo afecta la autenticación de correo electrónico a la entrega
en las cuentas de Google Mail y Office 365, los proveedores de correo electrónico empresarial más populares.
Los resultados se pueden dividir en dos grupos:
entrega de correos electrónicos
(Cómo afectan SPF, DKIM y DMARC a la entrega de mensajes enviados)
# Correo de Google: los correos electrónicos siempre se aceptan, la autenticación SPF parece no tenerse en cuenta en absoluto.
La firma DKIM se evalúa solo si coincide con la dirección de correo electrónico del remitente y DMARC está configurado con la política "cuarentena" o "rechazo".
# Office 365: responde completamente a SPF; cuando un mensaje pasa la verificación SPF, llega a la bandeja de entrada.
La firma DKIM se considera solo si coincide con la dirección de correo electrónico del remitente; de lo contrario, no importa.
Notas: en la última semana de agosto, Office 365 tuvo un comportamiento extraño:
solo los mensajes firmados con DKIM (dominio de firma alineado con la dirección del remitente)
y con el registro DMARC configurado (con cualquier política) se entregaron a la bandeja de entrada.
protección contra suplantación de identidad
(cómo spf, dkim y dmarc protegen la dirección de correo electrónico del remitente de ser suplantada*)
* = hacer que el mensaje parezca provenir de alguien que no es la fuente real
# Correo de Google: al activar dmarc, los remitentes suplantados se filtran a la carpeta Spam (con p=quarantine) o se rechazan (con p=reject).
No sucede nada si la política está configurada en “none” (p=none), en este caso todos los mensajes llegan a la Bandeja de entrada.
# Office 365: los resultados “spf fail” o “spf softfail” son suficientes para enviar a los remitentes falsos a la carpeta de correo basura.
requisitos de autenticación
Los requisitos sugeridos para la autenticación de correo electrónico se resumen a continuación:
|
entrega de correos electrónicos |
protección contra suplantación de identidad |
| Correo de Google |
Contraseña DKIM (alineada con el dominio) |
dmarc configurado con p=cuarentena o p=rechazo |
| Office 365 |
SPF pasa y DKIM pasa (alineado con el dominio) |
Se ha configurado SPF y DMARC (para mayor seguridad). |
Resultados de la prueba de entrega de correo electrónico
A continuación se muestra la gama completa de pruebas que se han realizado
|
|
Correo de Google |
Correo de Google (conjunto dmarc) |
Office 365 |
Office 365 (conjunto dmarc) |
| Paso spf |
dkim ninguno |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
| Error de SPF |
dkim ninguno |
bandeja de entrada |
correo basura |
basura |
basura |
| spf SoftFail |
dkim ninguno |
bandeja de entrada |
correo basura |
basura |
basura |
| ninguno de los factores de protección solar |
dkim ninguno |
bandeja de entrada |
correo basura |
basura |
basura |
|
|
|
|
|
|
| Paso spf |
diferencia dkim |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
| Error de SPF |
diferencia dkim |
bandeja de entrada |
correo basura |
basura |
basura |
| spf SoftFail |
diferencia dkim |
bandeja de entrada |
correo basura |
basura |
basura |
| ninguno de los factores de protección solar |
diferencia dkim |
bandeja de entrada |
correo basura |
basura |
basura |
|
|
|
|
|
|
| Paso spf |
pase dkim |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
| Error de SPF |
pase dkim |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
| spf SoftFail |
pase dkim |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
| ninguno de los factores de protección solar |
pase dkim |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
|
|
|
|
|
|
| Paso spf |
dkim inválido |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
bandeja de entrada |
| Error de SPF |
dkim inválido |
bandeja de entrada |
correo basura |
basura |
basura |
| spf SoftFail |
dkim inválido |
bandeja de entrada |
correo basura |
basura |
basura |
| ninguno de los factores de protección solar |
dkim inválido |
bandeja de entrada |
correo basura |
basura |
basura |
Notas:
- La dirección From (remitente visible) y Mail-from (también llamado "envelope from" o "return-path") son la misma, se refieren al mismo dominio
- “dkim pass”: el dominio de firma dkim es el mismo que el de la dirección From (el dominio está alineado).
- “dkim diff”: el dominio de firma dkim es diferente al de la dirección From (el dominio NO está alineado).
Dominio DKIM para DMARC
¿Cómo afecta la alineación de dominio DKIM a la autenticación DMARC?
DMARC (Autenticación, Informes y Conformidad de Mensajes Basados en Dominio)
es un estándar de autenticación de correo electrónico desarrollado para combatir el correo electrónico con dominios falsificados.
En el capítulo “3.1. Alineación de identificadores” dice:
Las tecnologías de autenticación de correo electrónico autentican diversos aspectos (y dispares) de un mensaje individual. Por ejemplo, [DKIM] autentica el dominio que adjuntó una firma al mensaje, mientras que [SPF] puede autenticar el dominio que aparece en la sección RFC5321.MailFrom (Mail-From) de [SMTP] o el dominio RFC5321.EHLO/HELO, o ambos. Estos pueden ser dominios diferentes y, por lo general, no son visibles para el usuario final. DMARC autentica el uso del dominio RFC5322.From al requerir que coincida (esté alineado con) un identificador autenticado. -- https://tools.ietf.org/html/rfc7489#section-3.1
Simplemente significa:
Cuando un remitente autentica su correo electrónico mediante SPF y/o DKIM, al menos uno de los dominios debe coincidir con el dominio del remitente
No nos quedaba claro si un mensaje podía fallar la comprobación SPF o DKIM
y aun así pasar la autenticación DMARC.
Lo probamos utilizando una herramienta disponible para todos: un buzón de Gmail.
Para ver el resultado, abre el mensaje y selecciona «Mostrar original».
Prueba 1 - mensaje reenviado: spf-fail, dkim-pass (alineado)

Prueba 2 - clave dkim rota: dkim-fail, spf-pass (alineada)

El resultado es evidente: el mensaje supera la autenticación DMARC si se cumple la condición
de SPF y alineación de dominio. <OR> DKIM y alineación de dominios
Para superar la comprobación DMARC, en algunos casos es importante validar la firma DKIM:
el dominio firmante (d=example.com) debe coincidir con el dominio From.
Ejemplos de resultados de “DMARC-PASS” que de otro modo no habrían funcionado:
Caso 1 : el reenvío interrumpe la autenticación SPF.
-
SPF-FAIL: Las comprobaciones de autenticación SPF fallarán en la mayoría de los casos,
porque una nueva entidad, no incluida en el registro SPF del remitente original, envía el correo electrónico reenviado.
-
DKIM-PASS (alineado): El reenvío de correo electrónico no afecta la firma DKIM
Resultado: La alineación DKIM permite que el mensaje supere la comprobación DMARC.
Caso 2 : el dominio SPF proporcionado por el ESP (Proveedor de servicios de correo electrónico)
NO PUEDE estar alineado con el dominio From.
-
SPF~PASS (NO alineado): La autenticación SPF falla debido a la alineación del dominio,
ya que el dominio utilizado por el ESP dentro de la dirección Mail-From es diferente al del remitente From.
-
DKIM-PASS (alineado): La firma DKIM utiliza el mismo dominio del remitente
Resultado: La alineación DKIM permite que el mensaje supere la comprobación DMARC.
PROVEEDORES DE CORREO ELECTRÓNICO más populares
¿Cuáles fueron los proveedores de correo electrónico más populares en 2020?
Para controlar la capacidad de entrega de correo electrónico, es importante saber qué proveedores de correo electrónico utilizan sus destinatarios.
De empresa a empresa
En el ámbito B2B, no disponemos de cifras precisas. La mayor parte de los buzones de correo empresariales se están migrando a "Suites de Oficina en la Nube", donde el mercado se divide entre "G Suite" y "Office 365".
Juntas, representan más del 90 % de la cuota de mercado global de correo electrónico empresarial, según datos de datanyze.com.
Recopilar esta información para una sola empresa es bastante sencillo.
A partir del registro MX del dominio de la empresa, podemos ver el proveedor de correo electrónico que se utiliza:
aspmx.l.google.com para “G Suite”
y mail.protection.outlook.com para “Office 365”.
Si su empresa opera en el sector B2B, se recomienda que supervise periódicamente un buzón de correo electrónico para cada uno de estos dos proveedores.
Un tercer competidor es Zoho (mx.zoho.com), cuya cuota de mercado ronda el 2% (fuente: ciodive.com).
De empresa a consumidor
En el caso del B2C, el análisis es más complejo. No existen datos públicos de correo electrónico abiertos basados en el tráfico de internet.
La única forma de obtener información sobre los destinatarios de correo electrónico es extraerla de nuestra lista de contactos o conseguirla a través de los grandes proveedores de servicios de correo electrónico. Algunos de ellos elaboran informes anuales para compartirlos con la comunidad de internet.
Los datos que aparecen a continuación muestran los tres principales proveedores de correo electrónico en veinticinco países. La información proviene del "Estudio comparativo y de participación por correo electrónico de 2019" publicado por Sendgrid.
Países
Argentina, Australia, Bélgica, Brasil, Canadá, Chile, China, Colombia, Dinamarca, Francia, Alemania, India, Indonesia, Italia, Japón, México, Nueva Zelanda, Rusia, Arabia Saudita, España, Sudáfrica, Suecia, Suiza, Reino Unido, Estados Unidos
Argentina
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| Arkansas |
gmail.com |
45.8% |
hotmail.com |
33.7% |
yahoo.com.ar |
8.2% |
|
87.7% |
volver arriba
Australia
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| AU |
gmail.com |
38.0% |
hotmail.com |
18.7% |
bigpond.com |
5.4% |
|
62.1% |
volver arriba
Bélgica
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| SER |
gmail.com |
30.6% |
hotmail.com |
23.0% |
telenet.be |
9.8% |
|
63.4% |
volver arriba
Brasil
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| BR |
gmail.com |
52.9% |
hotmail.com |
22.5% |
yahoo.com.br |
6.1% |
|
81.5% |
volver arriba
Canadá
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| California |
gmail.com |
38.6% |
hotmail.com |
18.8% |
yahoo.com |
4.5% |
|
61.9% |
volver arriba
Chile
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| CL |
gmail.com |
67.3% |
hotmail.com |
18.2% |
yahoo.es |
1.7% |
|
87.2% |
volver arriba
Porcelana
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| CN |
NetEase (126.com 163.com) |
n / A. |
Tencent (qq.com) |
n / A. |
Sina (sina.com) |
n / A. |
|
n / A. |
Nota: información tomada de “Descripción general del país: China” de ReturnPath
volver arriba
Colombia
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| CO |
gmail.com |
41.3% |
hotmail.com |
38.7% |
yahoo.com |
4.3% |
|
84.3% |
volver arriba
Dinamarca
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| DK |
gmail.com |
35.8% |
hotmail.com |
14.0% |
live.dk |
3.7% |
|
53.5% |
volver arriba
Francia
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| FR |
gmail.com |
36.0% |
hotmail.fr |
9.8% |
naranja.fr |
8.2% |
|
54.0% |
volver arriba
Alemania
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| Delaware |
gmail.com |
20.8% |
gmx.de |
10.0% |
web.de |
9.5% |
|
40.3% |
volver arriba
India
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| EN |
gmail.com |
82.4% |
yahoo.com |
3.4% |
yahoo.co.in |
1.6% |
|
87.4% |
volver arriba
Indonesia
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| IDENTIFICACIÓN |
gmail.com |
82.6% |
yahoo.com |
7.1% |
yahoo.co.id |
1.0% |
|
90.7% |
volver arriba
Italia
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| ÉL |
gmail.com |
46.8% |
libero.it |
9.9% |
hotmail.it |
7.2% |
|
63.9% |
volver arriba
Japón
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| JP |
gmail.com |
33.8% |
yahoo.co.jp |
12.7% |
docomo.ne.jp |
8.6% |
|
55.1% |
volver arriba
México
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| MX |
gmail.com |
42.6% |
hotmail.com |
31.5% |
yahoo.com.mx |
4.0% |
|
78.1% |
volver arriba
Países Bajos
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| NL |
gmail.com |
35.4% |
hotmail.com |
19.5% |
live.nl |
2.5% |
|
57.4% |
volver arriba
Nueva Zelanda
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| Nueva Zelanda |
gmail.com |
46.3% |
hotmail.com |
10.9% |
xtra.co.nz |
9.0% |
|
66.2% |
volver arriba
Rusia
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| RU |
correo.ru |
34.8% |
gmail.com |
22.7% |
yandex.ru |
19.6% |
|
77.1% |
volver arriba
Arabia Saudita
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| Sudáfrica |
gmail.com |
47.0% |
hotmail.com |
31.0% |
yahoo.com |
7.8% |
|
85.8% |
volver arriba
España
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| ES |
gmail.com |
50.2% |
hotmail.com |
25.8% |
yahoo.es |
3.8% |
|
79.8% |
volver arriba
Sudáfrica
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| ZA |
gmail.com |
65.5% |
yahoo.com |
4.1% |
hotmail.com |
2.9% |
|
72.5% |
volver arriba
Suecia
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| SE |
gmail.com |
33.2% |
hotmail.com |
21.0% |
en vivo.se |
3.0% |
|
57.2% |
volver arriba
Suiza
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| CH |
gmail.com |
25.5% |
bluewin.ch |
14.6% |
hotmail.com |
10.5% |
|
50.6% |
volver arriba
Reino Unido
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| Reino Unido |
gmail.com |
30.8% |
hotmail.com |
10.4% |
hotmail.co.uk |
9.2% |
|
50.4% |
volver arriba
Estados Unidos
| ISO |
Proveedor n.° 1 |
% |
Proveedor n.° 2 |
% |
Proveedor n.° 3 |
% |
|
Total |
| A NOSOTROS |
gmail.com |
41.9% |
yahoo.com |
15.1% |
hotmail.com |
5.3% |
|
62.3% |
volver arriba
Cómo funciona DMARC
¿Cómo funciona dmarc con Google Mail y Office 365 en 2020?
Hemos probado cómo afecta la autenticación de correo electrónico a la entrega
en Google Mail y Office 365, los proveedores de correo electrónico empresarial más populares.
Los resultados se pueden dividir en dos grupos:
-
Entrega de correos electrónicos
(cómo afectan SPF, DKIM y DMARC a la entrega de mensajes enviados)
Correo de Google: los correos electrónicos siempre se aceptan, la autenticación parece no tenerse en cuenta en absoluto.
Office 365: generalmente responde a SPF y DKIM. La única forma de obtener resultados consistentes, que lleguen a la bandeja de entrada, es asociarlos con DMARC.
-
Protección contra la suplantación de identidad
(cómo SPF, DKIM y DMARC protegen la dirección de correo electrónico del remitente contra la suplantación*)
* = hacer que el mensaje parezca provenir de alguien distinto al remitente real.
Correo de Google: al combinar DMARC y SPF (calificadores FAIL o SoftFAIL), los remitentes suplantados se filtran a la carpeta de spam o se rechazan (según la configuración de DMARC).
Office 365: SPF (calificadores FAIL o SoftFAIL) es suficiente para enviar remitentes falsos a la carpeta de correo no deseado.
Se resumen de la siguiente manera:
|
entrega de correos electrónicos |
protección contra suplantación de identidad |
| Correo de Google |
Siempre se acepta, la autenticación no se considera en absoluto |
dmarc + spf (fallo o fallo suave) |
| Office 365 |
pase dmarc + spf o dmarc + dkim |
spf (fallo o fallo suave) |
A continuación se detalla la gama completa de pruebas que se han realizado.
|
Correo de Google |
Office 365 |
| spf Pass - dkim ninguno |
bandeja de entrada |
bandeja de entrada |
| spf Fallo - dkim ninguno |
bandeja de entrada |
basura |
| spf SoftFail - dkim ninguno |
bandeja de entrada |
basura |
| FPS neutro - DKIM ninguno |
bandeja de entrada |
bandeja de entrada |
| ninguno spf - dkim ninguno |
bandeja de entrada |
basura |
|
|
|
| Pase SPF - Pase DKIM |
bandeja de entrada |
basura* |
| SPF fallido - DKIM aprobado |
bandeja de entrada |
basura |
| spf SoftFail - dkim pass |
bandeja de entrada |
basura* |
| SPF Neutro - DKIM Pass |
bandeja de entrada |
basura* |
| ninguno de SPF - pase DKIM |
bandeja de entrada |
basura* |
|
|
|
| Pasar spf - dkim inválido |
bandeja de entrada |
basura |
| Error de SPF: DKIM no válido |
bandeja de entrada |
basura |
| spf SoftFail - dkim inválido |
bandeja de entrada |
basura |
| SPF Neutral - DKIM inválido |
bandeja de entrada |
basura |
| spf ninguno - dkim inválido |
bandeja de entrada |
basura |
|
|
|
| Pase spf - dkim no válido - dmarc rechazado |
bandeja de entrada |
bandeja de entrada |
| Error de SPF - DKIM inválido - Rechazo de DMARC |
dsn=5.0.0, stat=Servicio no disponible |
basura |
| spf SoftFail - dkim inválido - dmarc rechazado |
dsn=5.0.0, stat=Servicio no disponible |
basura |
| spf Neutral - dkim no válido - dmarc rechazado |
bandeja de entrada |
bandeja de entrada |
| spf ninguno - dkim inválido - dmarc rechazado |
dsn=5.0.0, stat=Servicio no disponible |
basura |
|
|
|
| Pase spf - pase dkim - rechazo dmarc |
bandeja de entrada |
bandeja de entrada |
| SPF fallido - DKIM aprobado - DMARC rechazado |
bandeja de entrada |
bandeja de entrada |
| spf SoftFail - paso dkim - rechazo dmarc |
bandeja de entrada |
bandeja de entrada |
| spf Neutral - pase dkim - rechazo dmarc |
bandeja de entrada |
bandeja de entrada |
| spf ninguno - paso dkim - rechazo dmarc |
bandeja de entrada |
bandeja de entrada |
|
|
|
| spf Pass - dkim diff - dmarc rechazar |
bandeja de entrada |
bandeja de entrada |
| Error de SPF - diferencia DKIM - rechazo de DMARC |
dsn=5.0.0, stat=Servicio no disponible |
basura |
| spf SoftFail - diferencia dkim - rechazo dmarc |
dsn=5.0.0, stat=Servicio no disponible |
basura |
| spf Neutral - dkim diff - dmarc rechazar |
bandeja de entrada |
bandeja de entrada |
| spf ninguno - dkim diff - dmarc rechazar |
dsn=5.0.0, stat=Servicio no disponible |
basura |
Notas:
- La dirección del remitente (remitente visible) y la del sobre (ruta de retorno) pertenecen al mismo dominio
- “dkim pass”: el dominio de firma dkim es el mismo que el de la dirección de origen.
- “dkim diff”: el dominio de firma dkim es diferente al de la dirección de origen.
- Los asteriscos en el segundo grupo significan que los resultados no han sido consistentes a lo largo del tiempo