Correo corporativo y protección de pagos
Un proveedor pide por correo que la próxima transferencia se haga a otra cuenta. El mensaje incluye una factura conocida, conserva la conversación anterior y parece urgente. Antes de pagar, hace falta verificar la instrucción fuera de ese hilo.
El fraude por compromiso del correo empresarial, conocido como BEC, no depende siempre de archivos infectados: puede aprovechar una cuenta legítima intervenida para desviar dinero. La alerta del FBI/IC3 de septiembre de 2024 describe este mecanismo y recomienda usar un canal secundario para confirmar cambios de información bancaria. No se trata de un anuncio nuevo de octubre de 2026, sino de una recomendación vigente que conviene convertir en un procedimiento cotidiano.
La factura puede ser real; la cuenta de destino, no
Piensa en este ejemplo hipotético: administración espera pagar a un proveedor habitual. Dentro de una conversación reconocible aparece un aviso de “actualización de datos” con otra CLABE. Si quien controla el buzón es un intruso, puede conocer importes, nombres y fechas suficientes para que la solicitud resulte convincente.
También existen mensajes enviados desde dominios parecidos o con un nombre visible que imita al contacto. Revisar la dirección completa ayuda a detectar esas diferencias, pero no resuelve el caso de una cuenta auténtica comprometida. Responder “¿confirmas?” al mismo correo no crea una verificación independiente.
Detener
Deja pendiente el cambio de beneficiario hasta comprobarlo.
Confirmar
Llama a un número que ya esté registrado, no al del mensaje sospechoso.
Documentar
Registra quién validó el cambio, cuándo y quién autorizó el pago.
Qué protegen SPF, DKIM y DMARC, y qué no
Las directrices de Google para remitentes recomiendan autenticar los dominios con SPF, DKIM y DMARC. SPF declara servidores autorizados para enviar; DKIM permite comprobar una firma asociada a un dominio; DMARC evalúa la alineación con el dominio visible del remitente y permite publicar una política para los mensajes que no superan esa comprobación.
Estos mecanismos ayudan frente a la suplantación del dominio y a la entrega del correo legítimo. Sin embargo, no certifican que una CLABE pertenezca al proveedor ni que el titular del buzón haya autorizado la operación. Un mensaje enviado desde una cuenta comprometida puede superar la autenticación; un dominio parecido también puede autenticar sus propios mensajes.
Por eso conviene separar dos controles: el técnico, que protege cuentas y dominios, y el administrativo, que valida beneficiarios y pagos. La autenticación multifactor reduce riesgos de acceso, pero tampoco reemplaza la aprobación de una transferencia.
Un procedimiento breve para compras y administración
- Conserva un directorio confiable: registra los contactos y teléfonos de proveedores mediante el proceso de alta. No sustituyas esos datos automáticamente con los que llegan en una solicitud de cambio.
- Separa el cambio del pago: recibe la nueva cuenta, pero no la actives mientras se valida. La urgencia comercial no debe eliminar este paso.
- Confirma por otro canal: llama al contacto autorizado usando el directorio existente. Comprueba la solicitud, la identidad del beneficiario y los datos bancarios conforme a tu procedimiento interno.
- Aplica doble revisión: como control propuesto para la pyme, pide que una segunda persona apruebe el cambio de beneficiario. Evita que un solo usuario modifique la cuenta y libere el pago sin revisión.
- Deja evidencia mínima: anota fecha, responsable, canal de confirmación y autorización. Restringe el acceso a esos datos; no los distribuyas a todo el equipo.
- Revisa el correo: mantén MFA, cuentas individuales y seguimiento de accesos. Incluye reglas de reenvío, delegaciones y aplicaciones autorizadas cuando investigues un posible compromiso.
Al configurar DMARC, identifica primero los servicios que envían en nombre de la empresa: facturación, formularios, CRM y plataformas comerciales. Revisa los informes y prueba la entrega antes de endurecer la política. Publicar una política restrictiva sin ese inventario puede afectar mensajes legítimos.
Si la transferencia ya se realizó
Contacta de inmediato al banco por sus canales oficiales para reportar el posible fraude y solicitar las medidas disponibles para intentar detener o recuperar los fondos. El IC3 subraya que el tiempo es importante; ninguna gestión garantiza recuperar el dinero.
Avisa al responsable de seguridad o soporte y conserva el mensaje original con encabezados, los comprobantes y una cronología. Una captura puede servir como referencia, pero no sustituye el correo original. Coordina la contención del buzón y la preservación de evidencia; no borres la conversación ni formatees el equipo como primera respuesta. En México, realiza también el reporte ante la autoridad competente.
Para una pyme de CDMX, Querétaro o Celaya Guanajuato, la mejora más útil esta semana puede ser sencilla: que nadie cambie un beneficiario bancario basándose únicamente en un correo, aunque parezca venir de un contacto conocido.
Cómo puede ayudar Tiser: revisamos la configuración del correo corporativo, la autenticación del dominio y los accesos, y ayudamos a documentar un flujo de verificación y atención de incidentes.
Consulta nuestros servicios de correo e infraestructura empresarial, solicita una revisión de seguridad del correo o registra una incidencia en Soporte Tiser.
Fuentes consultadas
- FBI/IC3: Business Email Compromise, alerta del 11 de septiembre de 2024. Explica el compromiso de cuentas, la verificación por canales secundarios y la respuesta rápida ante transferencias fraudulentas. Sus estadísticas históricas no se presentan aquí como cifras de 2026.
- Google: directrices para remitentes de correos. Referencia para SPF, DKIM, DMARC y entrega a cuentas personales de Gmail; no constituye una obligación legal general para todas las empresas. Fuentes consultadas el 13 de octubre de 2026.
- Fotografía: Phones for GOP Victory Center, de wmrice, con licencia CC BY 2.0. Recorte horizontal realizado por Tiser. Imagen ilustrativa de equipo telefónico; no muestra instalaciones de Tiser ni un incidente real.