Tiago Guedes, Autor em E-goi

PHP2Shell: el descubrimiento que rompió media internet

Tiago Guedes — Fri, 23 Oct 2026 07:09:39 +0000

No se trató de un pequeño bug en un sitio web cualquiera, sino de dos vulnerabilidades críticas que permanecieron dormidas durante más de una década, desde 2011/2012, en el corazón de PHP, el lenguaje y el motor que sirven de base a gran parte de los sitios web de internet, desde blogs en WordPress hasta plataformas de comercio electrónico.

Queremos compartir contigo lo que ocurrió, cómo respondimos y lo que este episodio nos enseña sobre el futuro de la seguridad digital.

Para quien no es de código: ¿qué es, en realidad, “PHP2Shell”?

Para entender la gravedad de esto sin necesitar un curso de ingeniería de software, piensa en PHP como el motor de un coche y en internet como una autopista.

Hace unos 15 años, los creadores de PHP añadieron una funcionalidad llamada session.upload_progress, cuyo objetivo era sencillo: cuando un usuario envía un archivo pesado, como una fotografía o un vídeo, a través de un formulario web, el servidor calcula el porcentaje del envío para poder mostrar la clásica barra de progreso: 20%, 50%, 100%.

¿El problema? En el código interno en C, el lenguaje con el que se construye el propio motor de PHP, había un fallo sutil en la forma en que se liberaba la memoria cuando se producía un error.

Si un atacante enviaba una petición web malformada a propósito, con miles de cabeceras falsas o datos desordenados, el servidor podía agotar la memoria y entrar en un estado llamado Out of Memory.

En lugar de cerrar la puerta y bloquearlo todo de forma segura, el motor dejaba referencias de memoria “fantasma” colgadas y perdidas. En una segunda petición, el atacante podía aprovechar ese espacio de memoria para introducir sus propias instrucciones.

¿El resultado práctico? Lo que en seguridad se denomina RCE, o ejecución remota de código: el intruso obtiene la capacidad de ejecutar comandos en el servidor con los permisos del proceso afectado.

Un simple formulario web público podía convertirse en una puerta de entrada para controlar un servidor.

¿Por qué no se descubrió hasta 15 años después?

Esta es una de las partes más fascinantes y preocupantes de este episodio.

El código de PHP es open source. Está disponible públicamente desde hace décadas. A lo largo de 15 años, esas líneas pasaron por revisiones, auditorías y pruebas de seguridad sin que se identificaran estos fallos.

¿Qué ha cambiado? La inteligencia artificial y la potencia computacional puestas al servicio del análisis de código están ampliando la capacidad de encontrar problemas que antes exigían mucho más tiempo y trabajo humano.

Los modelos de lenguaje avanzados, combinados con herramientas automáticas de análisis de código y fuzzing, que pone a prueba los programas con grandes volúmenes de datos inesperados o malformados, permiten explorar comportamientos complejos a otra escala.

La IA está acelerando la lectura, el análisis y la correlación de flujos de ejecución. Eso ayuda a quienes protegen los sistemas, pero también puede dar más capacidad a quienes intentan atacarlos.

Un cambio de paradigma: el código cerrado no garantiza la seguridad

Durante décadas, parte de la industria se apoyó en una idea cómoda: la llamada security through obscurity, o seguridad por oscuridad.

La lógica era sencilla: “Si nuestro código está cerrado o compilado, a los atacantes les costará más entender cómo funciona.”

Pero un programa compilado o de código cerrado, por sí solo, no constituye una garantía de protección. Las herramientas de análisis e ingeniería inversa siguen evolucionando, y la IA está acelerando ese proceso.

Ya no podemos dar por hecho que algo es seguro solo porque siempre ha funcionado de la misma manera.

La seguridad exige varias capas de protección, una arquitectura resiliente, monitorización activa y la capacidad de responder rápidamente cuando surge una nueva amenaza.

¿Cómo respondió E-goi?

En cuanto se lanzó la alerta internacional, nuestro equipo de Ingeniería y Seguridad entró en acción.

La prioridad estaba clara: proteger los servicios y los datos de nuestros clientes, manteniendo la operación en funcionamiento.

La respuesta combinó mitigación inmediata, refuerzo de los filtros de entrada, aplicación de correcciones y auditoría de la infraestructura.

Nuestra respuesta en las primeras 24 horas

21 de octubre: evaluación de los servicios y servidores potencialmente afectados.
21 de octubre, por la tarde: desactivación preventiva de la funcionalidad vulnerable, sin interrupción de los servicios.
21 de octubre, por la tarde: refuerzo de los filtros de entrada para bloquear peticiones malformadas antes de que lleguen a las aplicaciones.
21 de octubre, por la noche: aplicación de las actualizaciones de seguridad publicadas.
22 de octubre, por la mañana: pruebas para verificar la eficacia de las medidas y auditoría de 369 servidores.
22 de octubre, a lo largo del día: continuación de la aplicación de las correcciones y de la verificación de los servicios.

Mitigación inmediata sin detener el negocio

Antes de actualizar toda la infraestructura, aplicamos una medida preventiva: desactivamos la funcionalidad vulnerable y recargamos los servicios de forma controlada.

Nuestros clientes siguieron enviando campañas sin interrupciones causadas por esta intervención.

Protección desde la entrada

Reforzamos los filtros en los puntos de entrada de la infraestructura para bloquear peticiones anómalas.

Si una petición con miles de cabeceras falsas intentaba entrar, se bloqueaba antes de llegar a los servidores de aplicaciones.

Auditoría y búsqueda de indicios de intrusión

Durante este proceso, auditamos los servidores y el resto de componentes de la infraestructura. Cruzamos registros y buscamos archivos sospechosos, conexiones anómalas y otros indicios de intrusión.

La auditoría realizada confirmó que todo estaba limpio, como debía ser.

Lo que este episodio enseña sobre la transparencia

Cuando una vulnerabilidad de esta magnitud se hace pública, evaluar el impacto puede llevar tiempo. Las organizaciones necesitan identificar los sistemas afectados, aplicar medidas de protección e investigar posibles indicios de explotación.

En E-goi creemos en la transparencia, en el rigor técnico y en la responsabilidad de proteger los datos y la confianza de nuestros clientes todos los días.

Contar con un equipo capaz de seguir los acontecimientos, evaluar el riesgo y aplicar medidas de protección en las primeras horas tras una alerta es esencial para responder a situaciones como esta.

¿Qué puedes hacer para proteger tus cuentas y tu negocio?

Los momentos de mayor atención mediática también pueden aprovecharse para intentos de phishing e ingeniería social. Un email que parece una alerta de seguridad puede ser, en realidad, la propia trampa.

Por eso, te dejamos algunas recomendaciones prácticas:

Revisa la seguridad de tus contraseñas: si alguna es débil, está reutilizada o sospechas que ha quedado expuesta, cámbiala. Un gestor de contraseñas puede ayudarte a crear y guardar credenciales seguras.
Nunca reutilices contraseñas: la contraseña de tu email no debe ser la misma que usas en las redes sociales o en una tienda online. Si uno de esos servicios se ve comprometido, el resto de tus cuentas puede quedar en riesgo.
Activa la autenticación de dos factores: siempre que sea posible, utiliza una aplicación de autenticación o configura passkeys, cuando estén disponibles.
Presta especial atención a los emails y enlaces sospechosos: si recibes un email que te pide cambiar la contraseña con urgencia, te avisa de que tu cuenta va a caducar o te solicita abrir archivos adjuntos inesperados, detente y confirma su origen. Accede al servicio a través de la dirección habitual.
Mantén tus dispositivos actualizados: instala las actualizaciones de seguridad del sistema operativo, del navegador y de las aplicaciones que utilizas.

La seguridad es un trabajo diario

La seguridad de la información exige atención, mejora continua y trabajo en equipo.

La inteligencia artificial está dando nuevas capacidades a quienes desarrollan y protegen la tecnología, pero también a quienes intentan explotar sus fallos. La capacidad de detectar, corregir y responder tiene que seguir el ritmo de esa evolución.

En E-goi seguimos atentos y trabajando para proteger los servicios, los datos y la confianza de quienes cuentan con nosotros.

Tiago Guedes

Chief Information Security Officer & Senior SysAdmin na E-goi

Desmitificando las “spamtraps” y cómo afectan a tu reputación

Tiago Guedes — Wed, 10 Sep 2025 07:00:00 +0000

Soy especialista en entregabilidad de correo electrónico y, desde que trabajo en esta área, una de las mayores dificultades que he observado es la comprensión incorrecta y persistente de algunos conceptos básicos de entregabilidad. No sé si esto pasa porque el material disponible no es lo bastante claro o si simplemente no se le da la importancia debida a estos temas (personalmente, creo más en lo segundo: todos queremos la solución más simple y rápida, pero cuando se trata de entregabilidad… eso no existe).

Por eso, decidí hacer este post para intentar, por fin (¡eso espero!), desmitificar no solo las spamtraps, sino también otros conceptos relacionados con la entregabilidad.

¿Spamtraps: qué son en realidad?

Puede que nunca hayas oído hablar de las spamtraps. ¿Qué significa exactamente?

Las spamtraps son, como indica el nombre, direcciones de correo “trampa” que no pertenecen a un suscriptor real. Pueden ser direcciones totalmente falsas creadas por proveedores de correo (ESPs) como Google, Microsoft o Yahoo, o incluso direcciones gestionadas por servicios antispam como Spamhaus, SORBS o Spamcop.

Por tanto, son direcciones que nunca se inscribieron para recibir comunicaciones y mucho menos confirmaron una suscripción mediante Double Opt-In (doble confirmación). Se crean para parecer lo más reales posible, son indetectables por servicios de “limpieza” y existen para que ESPs y RBLs identifiquen fallos en la validación de suscripciones/consentimiento por parte de quien envía. Si yo nunca pedí recibir comunicaciones y aun así me llegan, algo está mal en tu captación… ¡o simplemente eres un spammer!

Pero no soy spammer y no hice nada malo, ¿cómo llegaron ahí?

En la mayoría de los casos, las spamtraps acaban en una base de contactos por falta de validación adecuada del correo o de la suscripción. Puede suceder de varias formas; las más comunes son:

Falta de validación del correo/consentimiento (Double Opt-In)

Si creas un formulario de suscripción para una newsletter pero no envías un correo de confirmación (Double Opt-In) antes de empezar a comunicar, no tienes ninguna garantía de que esa dirección realmente pidió recibir tus mensajes. Piénsalo: cualquiera puede enviar lo que quiera. Estos formularios son públicos y, si algo está en Internet, será atacado.

Los formularios recibirán envíos falsos: es lo que se llama mail bombing (ojo: no digo que “puede” pasar; digo que va a pasar). Además, están los errores tipográficos (typos): quieres poner tu correo y envías el de otra persona, o uno inválido que después provoca un rebote (bounce).

Con el Double Opt-In, sabes que el correo es válido (porque llegó a un destino) y que hubo una persona real (o no, si la suscripción no fue genuina) que confirmó la suscripción y, muy importante, el consentimiento. El Double Opt-In es, de lejos, la forma más eficaz de evitar la mayoría de los problemas de entregabilidad y debería usarse siempre.

Listas compradas

Ni debería decirlo: si estás usando listas compradas, para. Una lista comprada no contiene contactos que hayan dado su consentimiento ni garantiza la validez de las direcciones. Por eso, las spamtraps son frecuentes en esas listas. Usarlas es pedir problemas de entregabilidad y daños graves en tu reputación como remitente.

Listas antiguas

Muchas spamtraps son direcciones reales reaprovechadas. Cuentas inactivas (como un Gmail u Outlook que dejaron de usarse) acaban desactivadas y pueden convertirse en spamtraps. Sirven para identificar a quien no mantiene su base y sigue enviando a los mismos contactos años después de que dejaran de abrir los correos. Golpear spamtraps no siempre significa que tu base tiene direcciones inválidas, pero sí puede indicar que contiene contactos muy antiguos y desinteresados.

Estos ejemplos también se aplican a cualquier base importada a E-goi cuyos contactos hayan entrado sin los debidos cuidados. Ninguna “limpieza” automática detecta spamtraps y, como cualquier otro residuo, acaban entrando en las listas.

Vale, ¡lo pillé! ¿Entonces puedes limpiar las spamtraps de mi lista?

Mi primera reacción ante esta pregunta es sentir un hormigueo por el cuerpo (), pero respiro hondo e intento explicar por qué la pregunta ni siquiera tiene sentido.

Lo oigo muchas veces, casi siempre sin considerar lo que la existencia de spamtraps realmente implica. Tal vez ocurra porque se malinterpreta su verdadera función. No, no existen para arruinar la reputación de quien envía: existen para ayudarnos. Deberías verlas como una herramienta muy útil para el responsable de los envíos; los ESPs nos están ayudando a detectar fallos en la captación. La pregunta correcta no es “¿Cómo elimino las spamtraps?”, sino “¿Cómo llegaron aquí?”.

Si sabemos que una lista contiene spamtraps, debemos asumir que el origen de la captación es problemático, y todos los demás contactos que entraron por la misma vía quedan en entredicho. Mientras no se resuelva, detén los envíos a esa base. Luego revisa el origen de la captación y protégelo: activa el Double Opt-In (solución infalible y que siempre debe usarse), añade CAPTCHA en los formularios, utiliza todos los validadores de correo posibles (y disponibles en tu cuenta de E-goi), etc.

¿Entonces debo descartar y eliminar todo lo que ya tengo en la base?

Si el origen de la lista es dudoso, ese es el mejor camino (aunque no el único). Sé que no es la solución que te gustaría oír, pero si quieres mantener buena reputación como remitente y seguir las mejores prácticas de entregabilidad, cualquier contacto sin registro CONFIRMADO de consentimiento debe descartarse.

Ahora bien, no siempre significa borrarlo todo y empezar de cero. Puede haber datos adicionales que permitan “salvar” algunas direcciones. Por ejemplo, si en tu web tienes un área de usuario donde el alta exige confirmación de correo, ya sabemos que cualquier cuenta activa tiene una dirección válida; eso puede usarse para reactivar contactos.

Del mismo modo, datos como la fecha del último login o de la última actividad ayudan a segmentar e identificar suscriptores aún relevantes.

Otra buena práctica es inactivar contactos sin interacción reciente (aperturas y clics) o, mejor, crear flujos específicos para suscriptores inactivos.

Una inactivación masiva quizá sea demasiado (salvo que la lista sea muy antigua y sin mantenimiento), pero sí conviene un flujo distinto: reducir sustancialmente la frecuencia para quien no abre/interactúa, usar campañas diferentes con más incentivos y terminar con un último envío preguntando si quiere seguir recibiendo. Después, sí, inactivar. Cabe destacar que estas spamtraps “reaprovechadas” suelen activarse tras LARGOS (años) periodos de inactividad de la dirección; no tiene sentido que sigan recibiendo comunicaciones.

En último caso, puedes, de forma muy gradual, lanzar campañas de reactivación: una campaña para confirmar si el suscriptor quiere seguir recibiendo comunicaciones, que puede funcionar como un Double Opt-In tardío. Es una gran táctica para aprovechar una lista dudosa. Eso sí: hazlo con cuidado, gradualmente y preferiblemente diluido entre otras comunicaciones, para no disparar una campaña masiva a toda la base problemática de una sola vez, lo que solo traerá problemas de reputación.

¿Y las direcciones no confirmadas pero que pertenecen a clientes con los que tengo una relación comercial activa?

Si no hubo doble confirmación, no hay garantías de que la dirección exista, de que pertenezca a la persona con la que quieres comunicar, etc. Por tanto, el problema sigue ahí. Siempre puedes realizar un Double Opt-In posterior: no tiene por qué ser cuando captaste la dirección; incluso puede ir “camuflado” dentro de una campaña normal. Solo hay que ser creativo: lo importante es provocar una acción humana que confirme la dirección y el consentimiento (esta parte del consentimiento no aplica si existe una relación comercial activa, pero la confirmación de la dirección sigue siendo importante).

Resumiendo

Las spamtraps no son enemigos a eliminar, sino señales claras de que algo falla en la captación o en el mantenimiento de las listas, y ahí es donde debes actuar. Lo mismo ocurre con las inclusiones en listas negras (blacklists). De nada sirve pedir la eliminación si no haces nada más. Al contrario: volverás a quedar bloqueado y, en cierto punto, los ESPs dejarán de atender esas solicitudes. El foco debe estar siempre en corregir la raíz del problema y, cuando eso esté resuelto, entonces sí, solicitar la eliminación de las blacklists.

En entregabilidad, quien solo trata los síntomas tendrá problemas recurrentes, una reputación débil y nunca logrará buenos resultados en sus envíos. Solo quien trata la causa construye y mantiene una reputación sólida y sostenible.

Espero que ahora entiendas mejor qué son las spamtraps y, sobre todo, que el verdadero foco debe estar en prevenir su origen y no solo en lidiar con las consecuencias.

Tiago Guedes

Chief Information Security Officer & Senior SysAdmin na E-goi

Los detalles de las nuevas directrices de Google para remitentes de email

Tiago Guedes — Thu, 01 Feb 2024 07:00:00 +0000

Google anunció que, a partir de febrero de 2024, aplicará requisitos más estrictos para la autenticación, exigirá un método de eliminación fácil y la obligación de mantener bajas las tasas de spam.

Estas nuevas prácticas, de hecho, siempre se consideraron positivas para la entregabilidad. La diferencia es que ahora, el incumplimiento hará que sus comunicaciones puedan ser rechazadas.

Para asegurarse de estar preparado para estos cambios, en este artículo proporcionaremos los detalles completos de las nuevas directrices.

Aquí, hablaremos sobre los cambios de Google, pero los mismos principios se aplican a Yahoo. Por lo tanto, simplemente siga las soluciones a continuación para garantizar la entregabilidad de sus comunicaciones (¡tanto para Google como para Yahoo!).

¿Por qué Google está implementando estos cambios?

Aunque durante mucho tiempo estos requisitos han sido prácticas recomendadas para la entregabilidad de email, muchos remitentes masivos aún no los siguen.

Con los cambios, Google ahora desea ampliar su adopción, convirtiendo las buenas prácticas en directrices a seguir.

Las nuevas directrices de Google (y Yahoo) vienen a enfatizar la importancia del email y a crear medidas para hacerlo más seguro. Este enfoque busca evitar el envío de spam no deseado e impide que posibles actores malintencionados alcancen las bandejas de entrada de sus clientes.

¿Qué va a cambiar?

Ahora que conocemos el porqué de estos cambios, hablemos sobre lo que realmente va a suceder. Para esto, es necesario entender que los cambios ocurren principalmente en tres enfoques:

Autenticación de email: busca garantizar que sus usuarios no sean engañados y puedan confiar en la supuesta procedencia del email. Con los nuevos cambios en sus políticas DMARC y al exigir que todos los remitentes masivos tengan un registro DMARC, será más fácil cerrar posibles brechas de seguridad que podrían ser explotadas para engañar a los usuarios sobre la autenticidad del email.
Eliminación fácil: busca que los suscriptores siempre tengan la opción de dejar de recibir newsletters si ya no están interesados. Por lo tanto, ahora será necesario asegurarse de que sus comunicaciones tengan un proceso de eliminación simple y con solo un clic. Además, esta solicitud debe procesarse en un plazo de dos días.
Límites más estrictos para tasas de spam: pretende evitar la recepción de spam. De hecho, Gmail siempre ha tenido filtros antispam muy efectivos; sin embargo, ahora va un paso más allá al aplicar límites más estrictos con respecto a la tasa de spam que todos los remitentes deben obedecer. En caso de incumplimiento de estas tasas, existe el riesgo de dañar su reputación como remitente y de que todas sus comunicaciones sean rechazadas o enviadas a la carpeta de spam.

¿Cuándo ocurrirán estos cambios?

Los cambios serán progresivos, con el objetivo de dar a los remitentes de email la oportunidad de adaptarse a las nuevas directrices. Entienda mejor:

A partir de febrero de 2024: Google rechazará un pequeño porcentaje del tráfico de remitentes masivos que no cumplan con los requisitos de las nuevas directrices. La pequeña tasa de rechazo busca ayudar en la identificación del tráfico de email que no cumple con las nuevas reglas. Durante esta fase, es posible que los mensajes se retrasen con errores temporales.
En abril de 2024: Google rechazará un mayor porcentaje del tráfico de email que no cumple con las nuevas directrices y aumentará gradualmente la tasa de rechazo.
Hasta junio de 2024: Google requerirá un método de eliminación con un clic en todos los mensajes comerciales y promocionales. Si utiliza E-goi, nuestro enlace de eliminación es ideal para cumplir con esta medida. Sin embargo, evite editar este enlace para evitar dificultades en la eliminación (como usar letras pequeñas o colores que dificulten la lectura).

Vamos a entrar en detalles: DMARC, ¿qué es? ¿Qué va a cambiar?

DMARC es una técnica de autenticación de correos electrónicos que guía a los proveedores sobre las acciones a tomar en caso de que los mensajes recibidos no cumplan con los criterios de verificación de SPF y DKIM.

Para cumplir con DMARC, sus correos electrónicos deben ser autenticados por SPF y DKIM, y el dominio debe coincidir con el mismo dominio utilizado como remitente («De:» en los encabezados de email). E-goi ya proporciona todas las instrucciones necesarias para configurar registros DMARC, SPF y DKIM.

¿Y qué va a cambiar con respecto a DMARC?

A partir de febrero de 2024, Google exigirá que todos los remitentes que envíen más de 5,000 email al día autentiquen su dominio de remitente con un registro DMARC.

No importa qué política elija para su registro DMARC, puede configurarlo con una política «ninguna» (sin acción), una política «cuarentena» (clasificando el email como basura/spam) o incluso con una política «rechazar» (rechazando completamente el email), lo importante es que lo haya configurado.

Si no envía más de 5,000 emails al día, aún recomendamos que tenga un registro DMARC. Además de proteger su dominio para futuros cambios, también mejorará la seguridad de su emails.

Otra modificación relacionada con DMARC es el cambio en la política de los dominios propios de Google, como gmail.com y googlemail.com. La política, anteriormente configurada como «ninguna» de permisividad, se ajustará a «cuarentena».

Esto significa que al enviar comunicaciones con direcciones de gmail.com, por ejemplo, desde otras plataformas como E-goi, estas fallarán en las autenticaciones SPF y DKIM, siendo entregadas en la carpeta de spam o incluso siendo rechazadas.

Por lo tanto, si está utilizando una cuenta de Gmail como remitente en otras plataformas, se recomienda considerar el uso de un dominio propio como remitente.

¿Y la eliminación fácil?

A partir de febrero de 2024, Google exigirá que todos los mensajes de marketing/promocionales o comunicaciones por suscripción admitan el método de eliminación con un clic.

Este método implica agregar dos encabezados específicos a sus mensajes:

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://solarmora.com/unsubscribe/example>

Estos encabezados permiten que los proveedores de email faciliten la eliminación para los suscriptores.Si es usuario de E-goi, no se preocupe, ya lo hacemos por usted y todos los correos electrónicos enviados desde nuestra plataforma ya tienen estos encabezados.

Además, sus mensajes también deben incluir un enlace de eliminación muy claro y visible en el cuerpo del email. Nuevamente, E-goi ya lo hace por usted.

Hacer que el proceso de eliminación sea más fácil eventualmente mejorará sus tasas de apertura, tasas de clics y reducirá su tasa de reclamaciones. Con esto, será menos probable que su dominio tenga problemas de reputación y sea filtrado por Gmail u otros proveedores.

Y finalmente, las tasas de reclamación

Google ahora recomendará que todos los remitentes mantengan una tasa de reclamación/spam por debajo del 0,1% y nunca superen el 0,3%.

Actualmente, los remitentes con una tasa de reclamación superior al 0,1% ya pueden observar un impacto negativo en su entregabilidad, pero Google comenzará a aplicar límites más estrictos a lo que consideran como spam. Si no supervisa su tasa de spam/reclamación, sus mensajes pueden comenzar a enviarse directamente a la carpeta de spam.

Si la situación empeora y su tasa de reclamación alcanza el 0,3% o más, no será elegible para la mitigación de reputación por parte de Google, lo que podría afectar permanentemente su reputación como remitente.

Además de estar atento a las tasas de reclamación en E-goi, recomendamos a todos los remitentes utilizar las herramientas de Postmaster de Google para monitorear la reputación de sus dominios.

Con ello, puede seguir todos sus dominios y recibir informes diarios sobre su reputación, reclamaciones, tasa de spam, errores de entrega y otra información útil sobre los correos electrónicos que envía a Google.

Conclusión

Las nuevas directrices de Google surgen para ayudar en la adopción de buenas prácticas de entregabilidad de email, siguiendo la lucha continua contra el spam para hacer un canal de comunicación más seguro, amigable para el usuario y libre de spam.

La implementación de estas nuevas prácticas no se limita solo a Google, Yahoo y otros proveedores también están tomando medidas similares, y muchos los seguirán pronto.

Para mantener la reputación de sus envíos de email, es esencial considerar estas prácticas como higiene básica de email, un proceso continuo para mantener las bandejas de entrada libres de correos no deseados, comunicaciones engañosas e incluso phishing o estafas.

Infórmese más sobre este tema, consulte las buenas prácticas para entregar correos electrónicos en Google y Yahoo.

Tiago Guedes

Chief Information Security Officer & Senior SysAdmin na E-goi