Análisis profundo de la entregabilidad del correo electrónico
- En octubre de 1971, Ray Tomlinson, egresado del MIT, envió el primer correo electrónico a través de una red.
- El año pasado se enviaron alrededor de 121 billones de correos electrónicos entre aproximadamente 4.3 mil millones de personas.
- El correo electrónico es el medio de comunicación escrita más importante del planeta, y seguirá siéndolo en el futuro cercano.
Resumen general
- El 3 de octubre de 2023, Google y Yahoo anunciaron nuevos estándares de seguridad de correo electrónico para prevenir intentos de spam, phishing y malware.
- A medida que los proveedores de servicios de correo implementan estas políticas, es indispensable cumplir con las directrices de entregabilidad del correo electrónico.
- El cambio más importante es la implementación de estándares de autenticación de correo como SPF, DKIM y DMARC.
- En el caso de Gmail, los correos no autenticados son bloqueados.
Quiénes se ven afectados
- Los remitentes masivos son los principales afectados y deben activar SPF, DMARC y DKIM en sus dominios.
- Incluso si no eres un remitente masivo, podrías verte afectado si no cumples con las directrices.
Cronograma
- Google exige desde febrero de 2024 que los remitentes masivos autentiquen sus correos electrónicos.
- Yahoo también aplica los mismos requisitos desde el primer trimestre de 2024.
Directrices
- Autenticación del remitente: implementar protocolos de autenticación de correo como SPF, DKIM y DMARC.
- Requisitos para remitentes masivos: evitar el envío innecesario de grandes volúmenes de correo para no caer en filtros de spam ni dañar la reputación.
- Cancelación de suscripción sencilla: implementar fácilmente una opción para darse de baja.
- Interacción: evitar asuntos engañosos, personalización excesiva y contenido promocional que active filtros de spam.
Autenticación del remitente
- SPF, DKIM y DMARC son tres estándares de autenticación que ayudan a proteger el correo electrónico de una organización.
- Una configuración adecuada de estos estándares protege contra ataques y mejora la entregabilidad para que los correos lleguen a la bandeja de entrada y no a la carpeta de spam.
Impacto
- Google actualiza continuamente sus algoritmos y los datos de reportes de usuarios para mejorar el filtrado de correos y la experiencia del usuario.
- Se muestra el impacto que las nuevas directrices de seguridad tienen sobre la entregabilidad y la interacción.
Herramientas
- Se ofrece una lista de recursos en línea gratuitos que ayudan a configurar, verificar y mantener la higiene del correo electrónico.
Implementación
- Implementar estas directrices puede ser un reto para organizaciones pequeñas con recursos limitados.
- Para implementar la autenticación del correo, se recomienda consultar los recursos o el soporte del proveedor de servicios.
Bonus
- Se presentan varias formas en que los hackers explotan vulnerabilidades de seguridad del correo electrónico.
Opinión de GN⁺
- Este artículo destaca la importancia de cumplir con los estándares más recientes relacionados con la seguridad del correo electrónico. Esto contribuye a aumentar la confiabilidad de la comunicación por correo y a proteger a los usuarios frente a amenazas como el spam o el phishing.
- A medida que los proveedores de servicios de correo aplican nuevos estándares de seguridad, las organizaciones deben esforzarse por adaptarse a estos cambios y cumplirlos. Esto es aún más importante en una época especialmente sensible a la privacidad y la seguridad de los datos.
- Este artículo puede ser especialmente útil para empresas que operan negocios relacionados con el email marketing. Como el email marketing sigue siendo un canal importante para muchas empresas, mantener la entregabilidad del correo es esencial para campañas exitosas.
- Implementar estándares de autenticación de correo puede ser un desafío técnico, especialmente para organizaciones que se enfrentan por primera vez a protocolos como SPF, DKIM y DMARC. Al adoptar estos estándares, puede ser necesario contar con soporte técnico y recursos, lo que puede requerir tiempo y costos.
- Este artículo puede ayudar a las organizaciones que buscan reforzar la seguridad del correo electrónico al ofrecer directrices y herramientas útiles para corregir vulnerabilidades en sus sistemas de correo y mejorar la experiencia del usuario.
1 comentarios
Opiniones de Hacker News
Viendo la influencia que tienen proveedores de correo como “Gmail”, “Outlook” y “Yahoo”, siempre me pregunté si no sería posible provocar fallas de entrega dirigidas como otro tipo de ataque contra empresas.
Hacer que la víctima, especialmente una empresa, lista de correo u ONG, envíe correos masivos a direcciones controladas por el atacante, y que luego el atacante marque esos correos como spam en Gmail/Yahoo/Outlook.
Entonces el filtro de spam con IA podría aprenderlo como nueva actividad de spam y, después, tratar como spam incluso los correos enviados a clientes reales, o eliminarlos antes de que lleguen.
Al cabo de más o menos un año, la empresa podría estar perdiendo dinero cada trimestre, el departamento de publicidad preguntándose por qué cae la participación por email, y el área técnica sumida en la confusión.
Una empresa grande podría resistirlo o abandonar por completo el email, pero una empresa pequeña, una ONG o una lista de correo política podría sufrir impactos como una caída en las donaciones.
Sinceramente, como vía de ataque probablemente sea poco probable, pero es una idea que se me quedó dando vueltas.
Los spammers metían la plantilla legítima de forma invisible dentro del email y dejaban visibles solo unas pocas líneas del texto real de la estafa.
La idea era que el filtro viera la mayor parte del email como legítima y lo dejara pasar; al final, si suficientes usuarios lo reportaban como spam, la propia plantilla terminaba provocando bloqueos.
Entonces el spammer se pasaba a la plantilla de email de la siguiente víctima que aún atravesaba los filtros, y la primera víctima quedaba con el problema de limpiar el desastre de que sus correos ya no llegaran a ninguna parte.
Tuve una experiencia tan mala con una gran empresa que se escuda en maximizar el valor para los accionistas, que busqué en mis registros de email antiguos y marqué como spam todas las comunicaciones de esa empresa.
Puede ser apenas una gota de agua, pero en el mundo del spam quizá no hagan falta tantos votos.
Creo que la entrega de email evolucionará hacia un modelo de pase pago más descarado, y quizá ya existan acuerdos entre bambalinas.
Aunque ese dominio reciba reportes, los emails transaccionales se pueden seguir enviando desde el dominio principal.
Claro que esto requiere asumir que los dos servidores de correo están en IPs distintas.
Se puede cancelar la suscripción desde el sitio, pero piden no marcarlas como spam desde el cliente de correo.
Para una organización pequeña puede ser un riesgo bastante realista.
No sé bien cómo lo mitigan las organizaciones grandes.
Si los emails enviados por el atacante fallan SPF/DKIM, se puede configurar una política DMARC para que Gmail ni siquiera entregue esos correos falsos.
Entonces ese tipo de ataque no funciona.
Este cambio era necesario y llegó demasiado tarde.
Si se exige correctamente a los propietarios de dominios que envían grandes volúmenes de email que firmen los mensajes, los receptores pueden distinguir con más claridad el correo bueno del malo con base en la reputación del dominio, no en la reputación de la dirección IP.
En un contexto en el que cada vez más dominios envían email a través de espacios de IP compartidos de servicios transaccionales y de marketing, la capacidad de asociar la reputación de forma estable al dominio remitente es muy útil para reducir abusos.
Google dice que los nuevos requisitos solo son obligatorios cuando se envían más de 5,000 correos al día, pero eso es falso.
Yo enviaba como mucho unos pocos al día, normalmente ni siquiera uno diario a cuentas de Gmail, e implementé solo parte de los requisitos; aun así, Google empezó a rechazar mis mensajes.
Al final tuve que perder tiempo implementando incluso requisitos bastante redundantes.
En general estoy de acuerdo en que es un cambio positivo, pero es realmente frustrante cuando la razón por la que el email termina en la carpeta de spam es un error de configuración del lado del destinatario.
Por ejemplo, hay casos en los que SPF se rompe durante el reenvío.
Si un remitente malicioso puede enviar cada email desde una dirección IPv6 distinta, quizá haya que desconfiar por defecto de todas las direcciones IPv6 que parezcan nuevas.
Aunque haya molestias, espero que este cambio ayude a ordenar el ecosistema del email.
El spam no se puede distinguir del contenido malicioso.
Nunca te suscribiste a ese “newsletter”, y tu dirección de email fue recolectada y entregada a un actor malicioso que quiere molestarte.
Si haces clic en cualquier cosa, terminarás en un sitio web de una empresa que tiene tu información y que no va a tener en cuenta tus intereses en absoluto.
En el mejor de los casos, solo podrás eliminar una fuente de basura de tu bandeja de entrada; en el peor, harás clic en algo que instala malware en tu computadora.
Por eso no hagas clic en enlaces para cancelar la suscripción: usa el botón de reportar spam y deja de usar grandes servicios de email que ignoran los reportes de spam.
Gmail deja que otras grandes empresas te envíen spam y ni siquiera te da la opción de bloquear dominios completos directamente.
Hasta que te mudes a un proveedor de email que se tome en serio la privacidad y la seguridad, el contenido malicioso seguirá llegando a tu bandeja de entrada.
Me da curiosidad qué proveedor de email usas.
Sorprende que tantas grandes empresas no pasen la prueba de cancelación de suscripción con un clic.
Cloudflare o Akamai bloquean la conexión, la página tarda más de 5 segundos en cargar, o exigen iniciar sesión o volver a ingresar la dirección de correo.
Y aun así no deberían sorprenderse de que el cliente haga clic en el botón de reportar spam.
Por eso hago clic en reportar spam.
Lo más molesto es que los remitentes de correo hacen seguimiento de clics con dominios que quedan bloqueados por las listas de anuncios.
Tengo una instancia separada del navegador para copiar y pegar esos enlaces, pero entonces toca iniciar sesión otra vez.
Prefiero enviar un correo para cancelar la suscripción antes que hacer clic en el enlace, y Gmail puede automatizar eso.
Si me vuelve a llegar un correo en unos días, lo marcaré como spam.
Si TripAdvisor puede crear itinerarios de viaje generados por IA, también debería poder averiguar cómo no enviarlos por correo.
El cliente elige lo que sea más cómodo, ya sea cancelar la suscripción o reportar spam.
Una de las cosas que rompen los cambios de abril es el reenvío entre servicios de correo.
Por ejemplo, si estás reenviando desde una antigua dirección universitaria foo@school.edu a tu cuenta personal de Gmail bar@gmail.com, ya no funcionará.
Por cómo lo están impulsando los principales proveedores, probablemente sea un caso de uso relativamente poco común, pero para las personas afectadas es un cambio bastante molesto.
Al reenviar un correo, mientras quien reenvía no modifique el contenido del mensaje, seguirá coincidiendo con la firma DKIM, así que debería pasar.
SPF siempre rompió a los reenviadores que no modificaban la dirección del remitente del sobre, y eso es correcto y adecuado.
Reenviar correo sigue siendo posible, pero quien reenvía debe reescribir el return path.
Sorprende que alguien estuviera dejando pasar correos aunque SPF, DKIM y DMARC no estuvieran configurados perfectamente.
Yo operé durante años un servidor personal de correo autohospedado bien configurado y aun así a veces me costaba lograr que pasaran, aunque parece que poco a poco va mejorando.
En particular, los servidores de Microsoft suelen marcar como fallida, sin razón y de forma aleatoria, una configuración DKIM perfectamente válida.
Si el volumen de envío es bajo, corres el riesgo de que te descarten solo por no ser un remitente conocido.
Como los 3 grandes publicaron estas directrices y las hicieron transparentes, espero que el comportamiento sea más consistente.
Los spammers también pueden hacer lo mismo, porque la barrera de entrada es baja.
Es importante, pero tiene muy poca relación con la entregabilidad en el mundo real.
Lo más difícil de DMARC es que falla con frecuencia, especialmente en Microsoft.
Y también causa problemas en todos los casos de uso en los que el destinatario reenvía el correo, porque ahí se rompe la alineación SPF.
Como quería seguir las mejores prácticas, hace poco cambié p=quarantine a p=none.
Fue porque temía que correos legítimos no pasaran DMARC aunque DKIM y SPF estuvieran bien configurados.
Realmente quisiera usar p=reject, pero no puedo hacerlo hasta que los destinatarios arreglen sus servidores de correo entrante para manejar esos casos excepcionales en los que DMARC se rompe por el reenvío de correos.
Reenviar un mensaje firmado con DKIM no rompe DMARC en absoluto.
Lo peor es recibir el correo, marcarlo silenciosamente como spam y meterlo en un lugar donde el destinatario previsto nunca lo verá.
Gmail de Google es el que más hace esto.
El correo corporativo ya no es correo: es un jardín amurallado y un silo, como Facebook.
Si no, estaríamos ahogados en spam de cold emails.
Hablando en serio, en todas las empresas uso Gmail porque renuncié a operar y administrar servidores propios.
Es una tragedia que esto se haya vuelto tan difícil.
Si no estás sobre un Gmail Workspace bien configurado, se siente como si ni siquiera los correos legítimos tuvieran posibilidades de pasar.
Según entiendo, no quieren darle al spammer una señal de que el mensaje fue clasificado como correo normal o como spam.
Me gustaría saber qué tan inteligentemente usan realmente los spammers esa información.
La mayoría del spam parece un intento de golpear sin considerar la retroalimentación de fallos.
En mi servidor de correo, los mensajes clasificados como basura siguen siendo rechazados temporalmente con un mensaje de error común.
Al menos los remitentes legítimos mal clasificados reciben un DSN de retraso y, finalmente, retroalimentación de que el mensaje no fue recibido.
Muchos servidores y servicios de correo parecen darle más importancia a no dar señales a los spammers que a dar señales útiles a usuarios legítimos mal clasificados.
Quizá creen que su clasificación es tan excelente que no cometen falsos positivos.
Los filtros de spam y promociones de Gmail son confiables en más del 99% desde el punto de vista del usuario, y los falsos positivos son realmente pocos.
En B2B, si un marketer puede conocer tu dirección de correo, en la práctica tiene derecho a enviarte tantos mensajes como quiera.
Sin ese muro, sería completamente inutilizable.
Mi VM personal terminó en alguna RBL porque todo el espacio de direcciones /24 quedó en lista negra.
Dicen que alguien envió spam, y ahora mi máquina, que manda unos tres correos por semana, también está bloqueada.
Puede que el spammer haya usado una dirección cualquiera dentro de ese rango, o que alguien haya levantado un servidor SMTP mal configurado que permite relay.
Operar un servidor SMTP saliente desde un rango de IPs de clientes de todos modos suele ser propenso a problemas.
Esos rangos pueden verse todos como sospechosos porque los spammers los usan sin preocuparse por la reputación.
Parece que los operadores de listas de bloqueo no verifican bien los reportes de abuso, o que causan daños colaterales para forzar a los operadores de red a tomar medidas.
No me gusta terminar en una lista de bloqueo, pero quizá tenga un efecto neto positivo para Internet en general.
Creo que los servidores y servicios de correo están usando mal las listas de bloqueo basadas en IP.
Pueden usarlas como una señal entre varias, y darles más peso con remitentes desconocidos.
Pero si una IP con la que se venía intercambiando tráfico y mensajes autenticados con SPF/DKIM/DMARC de pronto aparece en una lista de bloqueo, la reputación positiva previa debería pesar más que ese bloqueo.
Debería seguir siendo posible comunicarse con contactos conocidos, y recién después de que ellos marquen algo como spam se podría rechazar la entrega posterior o mandarla a correo no deseado.
Hoy parece que muchos servidores y servicios de correo aplican listas de bloqueo de IP temprano en el proceso SMTP para reducir la carga del sistema.
Es bueno para la carga del sistema, pero malo para la calidad del análisis.
En general, incluso los grandes servicios gratuitos de correo parecen poco capaces de aprovechar la reputación existente para decidir si algo es legítimo o spam.
Hace poco cambié un servicio web en línea que creé a un registro basado en email: como en una suscripción a una lista de correo, uno se registra enviando un email a una dirección específica.
La idea es que, si el usuario le envía un email a mi servicio, yo entro en la lista de contactos conocidos del usuario.
Entonces la respuesta de confirmación alineada con SPF/DKIM/DMARC que envía mi servidor de correo debería aceptarse, obviamente.
Me pregunto cuánto más explícito tendría que ser el opt-in que eso.
Lo probé con algunos grandes servicios gratuitos de correo, y Yahoo mandó a la carpeta de correo no deseado incluso la respuesta de confirmación que hacía referencia al mensaje original.
Para quienes creen que no se puede competir con los grandes servicios de correo: la vara no es tan alta como parece.
Arreglar la reputación es, en el mejor de los casos, casi una pesadilla.
También vi la sugerencia de comprar otro dominio para proteger el dominio principal y enviar emails desde ahí, pero no me dan muchas ganas de hacerlo.
Parece que en el texto mezclaron el sobre (RFC5321) y los encabezados (RFC5322).
Decía que “se inspecciona el nombre de dominio en el campo From: del encabezado del sobre del email y se alinea con otro dominio autenticado por SPF o DKIM”, pero el sobre no tiene encabezados, y los encabezados están dentro del contenido/cuerpo del email.
La captura titulada “ejemplo de sobre de email de una organización que cumple todas las directrices de seguridad de email” tampoco muestra información del sobre, sino encabezados del correo.
Hay una buena presentación de dmarc.org sobre este tema.
https://dmarc.org/presentations/Email-Authentication-Basics-...