Victor Arias
El correo transaccional de una empresa de transporte dejó de entregarse el 30 de septiembre: la cuenta de SendGrid estaba suspendida porque alguien había usado la clave de la API —escrita en el código— para enviar phishing. El DNS estaba bien. En tres días se autenticó el dominio en SendGrid (firma DKIM por CNAME, remitente verificado y DMARC en modo monitorización), se revocó la clave comprometida y se sustituyó por una restringida solo a envío en los tres componentes, y el cliente cambió la contraseña y activó la verificación en dos pasos. La cuenta se reactivó y la entrega se verificó con Delivered y DKIM y DMARC en pass; los correos que no salieron se reenviaron.
| Cliente | Empresa de transporte de carga |
| Confidencialidad | Se omiten el nombre del cliente, las capturas y los enlaces por acuerdo de confidencialidad. Los diagramas describen la solución y las técnicas aplicadas. |
| Sector | Transporte de carga |
| Servicio | Ciberseguridad |
| Tecnologías | PHP, SendGrid, DKIM, SPF, DMARC, Claves de API restringidas a envío, Verificación en dos pasos (2FA) |
| Duración | 3 días |
| Nuestro rol | Análisis de los puntos críticos del sitio, corrección de los fallos que bloqueaban el envío, autenticación del dominio en SendGrid, revocación y rotación de la clave comprometida, y documentación del incidente para el proveedor. |
| Publicado | 19 de octubre de 2026 |
Una empresa de transporte de carga envía con su plataforma los correos que sostienen la operación: cotizaciones, avisos y notificaciones a clientes. El 30 de septiembre dejaron de llegar. La web seguía funcionando y generaba cotizaciones con normalidad, pero ningún mensaje aparecía en la bandeja de producción, ni en la de los clientes, ni en Gmail.
La primera sospecha fue el DNS, que es donde suele estar el problema cuando un dominio deja de entregar. No era el DNS: la cuenta del proveedor estaba suspendida y nadie lo sabía. Este caso cuenta qué había pasado, qué se hizo para contenerlo y cómo volvió a salir el correo. Por acuerdo de confidencialidad no se publica el nombre del cliente; los dos diagramas resumen el diagnóstico y el procedimiento.
El reto: un correo que sale del sistema y no llega a nadie
La plataforma está hecha en PHP y envía a través de la API de SendGrid. Cuando la entrega se corta, el síntoma aparece lejos de la causa: las cotizaciones se generan y se guardan, el formulario responde y la aplicación no se cae. El fallo no está donde se busca.
El síntoma: todo funcionaba menos lo importante
Desde fuera, la operación parecía intacta: la web generaba cotizaciones y el equipo seguía trabajando. Lo que no ocurría era lo único que el cliente final percibe: el mensaje llegando a su bandeja. Un fallo sin error visible es el peor de los diagnósticos, porque cada día que pasa el problema crece sin hacer ruido.
El alcance: ni producción, ni clientes, ni Gmail
No era un problema de un destinatario concreto: no llegaba nada a ninguna parte. Durante la incidencia se quedaron sin salir más de cien correos, y cada uno de ellos era una cotización, un aviso o una respuesta que alguien esperaba. La lista de pendientes crecía mientras la causa seguía oculta.
El diagnóstico: una cuenta suspendida y una clave filtrada
El dominio resolvía bien y los registros de correo no explicaban una interrupción total. La pista estaba en otro sitio: en el estado de la cuenta con el proveedor de envío.
30 de septiembre: la cuenta dejó de estar activa
SendGrid había suspendido la cuenta ese mismo día por un uso indebido: se había enviado phishing con ella. Una cuenta suspendida rechaza los envíos, así que el correo de la plataforma dejó de salir aunque el código no hubiera cambiado. El DNS no tenía nada que ver.
Una clave de API con permiso de envío, escrita en el código
La clave que se usó para el envío fraudulento estaba escrita en el código de la plataforma. Cualquiera con acceso al repositorio, a una copia del proyecto o a un respaldo podía leerla y enviar correo en nombre de la empresa, sin pasar por la aplicación y sin dejar rastro en ella. Ese fue el origen del incidente y también la razón por la que la solución no podía limitarse a reactivar la cuenta.
Cómo se autentica un correo: la firma DKIM, el SPF y la política DMARC son lo que distingue un envío legítimo de una suplantación.
La solución: contener, autenticar y rotar credenciales
El trabajo se organizó en tres frentes: dejar fuera de circulación la credencial comprometida, autenticar el dominio para que volviera a ser confiable y asegurar el acceso a la cuenta. En tres días la configuración quedó lista y el proveedor tenía sobre la mesa todo lo que necesitaba para evaluar la reactivación.
Autenticar el dominio en SendGrid
Se dieron de alta los tres registros CNAME de firma que el proveedor exige, se verificó el remitente y se publicó una política DMARC en modo monitorización. Con eso cada mensaje sale firmado con DKIM, el SPF declara qué servidores pueden enviar y el dominio queda preparado para que los receptores distingan lo legítimo de lo suplantado.
Revocar la clave comprometida y crear una restringida a envío
La clave antigua se revocó y se creó una nueva con el permiso mínimo: solo enviar, sin capacidad de gestionar la cuenta ni de cambiar configuraciones. Se documentó y se desplegó en los tres componentes del sistema que mandan correo, para que ninguno se quedara atrás usando la credencial muerta.
Contraseña nueva y segundo factor
El cliente cambió la contraseña de la cuenta y activó la verificación en dos pasos por SMS. A partir de ahí, el acceso a la cuenta deja de depender de una sola contraseña y el daño de una filtración futura no es el mismo.
La secuencia del incidente: primero se identifica y se corta la causa, después se autentica el dominio y se verifica la entrega.
Cómo lo hicimos en tres días
El diagnóstico, antes que la configuración
Antes de tocar nada se descartaron las causas probables: el dominio resolvía bien y los registros estaban correctos, así que el problema no estaba en el DNS. Revisar el estado de la cuenta del proveedor y después el código fue lo que puso el incidente en su sitio.
Sin detener la web
La plataforma siguió funcionando y generando cotizaciones durante toda la intervención: los cambios se hicieron sobre la configuración del envío, no sobre la aplicación. Las pruebas se hicieron con envíos controlados antes de dar el trabajo por cerrado.
Documentar y responder al proveedor
El incidente quedó documentado con su causa, las acciones tomadas y las credenciales nuevas, y se preparó el informe que el proveedor pide para reactivar la cuenta. Sin ese documento la reactivación no avanza: el proveedor necesita saber qué pasó y qué se corrigió antes de devolver el servicio.
Resultados
La cuenta volvió a estar activa y el correo regresó a las bandejas. La comprobación se hizo con los dos datos que importan: cada envío de prueba apareció como Delivered y las comprobaciones de DKIM y DMARC pasaron. Los mensajes que se habían quedado sin salir se reenviaron.
| Indicador | Antes | Después |
| Clave de API | Escrita en el código, con permiso de envío | Revocada; nueva restringida solo a envío, en los tres componentes |
| Dominio en SendGrid | Sin autenticar | Autenticado con firma DKIM por CNAME y remitente verificado |
| Acceso a la cuenta | Solo contraseña | Contraseña nueva y verificación en dos pasos por SMS |
| Causa del fallo | Atribuida al DNS | Documentada: cuenta suspendida por phishing con la clave filtrada |
| Entrega de correo | Suspendida desde el 30/09 | Restaurada y verificada: Delivered, DKIM y DMARC en pass |
El resultado que más importa no es una cifra, sino que la credencial que se usó para el phishing ya no existe: aunque se hubiera filtrado de nuevo, no habría servido para enviar en nombre de la empresa.
Qué revisar si el correo de tu plataforma deja de llegar
Estos son los puntos que, en nuestra experiencia, separan un incidente contenido de una cuenta comprometida durante semanas:
- Una cuenta suspendida no es un problema de DNS. Antes de tocar SPF o DKIM, comprueba que la cuenta del proveedor sigue activa y por qué dejó de estarlo.
- Las claves no van en el código. Una clave con permiso de envío escrita en el proyecto es una puerta abierta para cualquiera que tenga acceso al repositorio o a un respaldo.
- Cada clave, con el permiso mínimo. Si solo envía, que no pueda gestionar la cuenta ni cambiar configuraciones: el daño de una filtración es mucho menor.
- El dominio autenticado. Firma DKIM por CNAME, remitente verificado y DMARC en modo monitorización con el campo rua para recibir los informes.
- Segundo factor en la cuenta. Contraseña nueva y 2FA por SMS o, mejor, con aplicación de autenticación.
- Un informe del incidente que el proveedor pueda evaluar. La reactivación no se pide por teléfono: se responde un RCA con qué pasó, cuándo y qué se corrigió.
Si tu plataforma envía correo y no sabes con qué credencial lo hace, en la página de ciberseguridad contamos cómo trabajamos, y si prefieres revisar tu caso concreto puedes escribirnos.
Preguntas frecuentes
¿Por qué dejaron de llegar los correos si el DNS estaba bien?
Porque el DNS resuelve el dominio, pero no autoriza a enviar. El dominio resolvía bien y el problema estaba en la cuenta del proveedor, que estaba suspendida: una cuenta suspendida rechaza los envíos aunque los registros estén perfectos. Por eso el primer paso de un diagnóstico serio es separar las dos cosas: la entrega (DNS y autenticación) y la cuenta (estado y credenciales).
¿Qué pasa cuando una clave de API queda escrita en el código?
Que cualquiera con acceso al código —o a una copia del repositorio, o a un respaldo— puede enviar correo en nombre de la empresa sin pasar por la plataforma. En este caso se usó para phishing, y la consecuencia no fue solo el envío fraudulento: el proveedor suspendió la cuenta y con ella se cayó todo el correo legítimo. Una clave restringida a envío reduce el daño, porque no permite gestionar la cuenta ni cambiar configuraciones.
¿Qué es autenticar el dominio y para qué sirven DKIM, SPF y DMARC?
Autenticar el dominio es demostrar que quien envía en su nombre está autorizado. DKIM firma cada mensaje con una clave publicada en el DNS; SPF declara qué servidores pueden enviar; y DMARC le dice al receptor qué hacer si el mensaje no pasa esas comprobaciones y a dónde mandar los informes. Con las tres, el correo legítimo deja de confundirse con el suplantado.
¿Se pueden recuperar los correos que no se enviaron?
Los que no llegaron a salir sí: se reenvían desde la plataforma una vez restaurada la entrega, con la precaución de no duplicar los que sí salieron y de revisar si alguno ha caducado. Los que el proveedor rechazó no están en ninguna cola: hay que regenerarlos. Por eso el reenvío se planifica con el listado de mensajes del periodo, no a ciegas.
¿Qué evita que vuelva a pasar?
Tres cosas. Sacar las credenciales del código y guardarlas en un gestor o en variables de entorno; restringir cada clave a lo mínimo que necesita; y poner segundo factor en la cuenta del proveedor. Ninguna es cara. Las tres juntas habrían cambiado el incidente: una clave que no está en el código no se puede leer desde un repositorio, y una clave que solo envía no sirve para tocar la configuración de la cuenta.
