Cómo comprobar la autenticidad de alertas por email de una flota
El nombre y el logo del remitente se pueden imitar. SPF, DKIM y DMARC aportan señales distintas en los encabezados y deben combinarse con enlaces, contexto y un canal alternativo.
Por Marco Ferreiro ·
Una alerta de flota puede mostrar el nombre correcto, un logo convincente y un asunto urgente sin haber sido enviada por el sistema esperado. El campo “De” que ve una persona es una presentación; los controles técnicos viven en la conversación entre servidores y en los encabezados originales.
SPF, DKIM y DMARC no son tres sellos equivalentes. Cada uno responde una pregunta distinta. Leerlos juntos permite detectar muchas suplantaciones, pero ningún “pass” convierte un mensaje en una orden de pago confiable por sí solo.
Empezar por un canal que el email no controle
Si la alerta pide iniciar sesión, descargar un archivo o pagar, la primera medida es no usar sus enlaces. Abrí la plataforma desde un marcador conocido, escribí el dominio habitual o usá la aplicación oficial. Buscá el mismo evento dentro de la cuenta.
Una alerta auténtica debería poder correlacionarse con un identificador interno, vehículo o evento sin revelar de más en el email. Si no aparece, contactá a una persona o canal ya registrado. Responder al remitente no es una confirmación independiente.
Este paso sigue siendo necesario aunque la autenticación técnica pase. Un proveedor legítimo puede ser comprometido o enviar un contenido erróneo.
El From visible no prueba origen
El correo de internet utiliza varias identidades. El usuario suele ver el campo From del contenido. El protocolo SMTP también maneja una identidad de sobre, conocida como MAIL FROM, y la sesión presenta un HELO o EHLO.
RFC 7208 explica que SPF permite a un dominio autorizar hosts para usar identidades MAIL FROM o HELO. Por eso un SPF pass puede pertenecer a un dominio de rebotes distinto del que aparece a simple vista. No debe leerse como “la dirección visible fue verificada”.
Para evaluar esa relación existe la alineación que usa DMARC.
SPF: servidor autorizado para una identidad
SPF consulta una política publicada en DNS y evalúa si el servidor que entregó el mensaje estaba autorizado para usar la identidad correspondiente. Resultados habituales incluyen pass, fail, softfail, neutral, none, temperror y permerror.
Un pass es evidencia positiva para esa identidad. Un none puede significar que no había política. Un temperror indica una falla temporal, no fraude confirmado. La hora importa: RFC 7208 advierte que las políticas DNS pueden cambiar y que una comprobación tardía puede no reproducir la intención al momento del envío.
Además, reenvíos y listas pueden afectar SPF. Por eso no se usa como veredicto aislado.
DKIM: una firma sobre partes del mensaje
DKIM agrega una firma criptográfica en el encabezado. El receptor obtiene una clave pública desde DNS y verifica que los campos cubiertos y el cuerpo canónico coincidan. El parámetro de dominio firmante se identifica como d=.
Un DKIM pass indica que la firma verificó para ese dominio. No exige por sí solo que sea el mismo dominio visible en From. Un atacante puede firmar correctamente con su propio dominio y escribir otro nombre en pantalla. También puede haber varias firmas, por ejemplo del sistema emisor y de un intermediario.
La revisión debe registrar qué dominio firmó, qué resultado informó el receptor y si ese dominio está alineado con el From.
DMARC: autenticación más alineación
RFC 7489 define alineación entre el dominio visible y el autenticado por SPF o DKIM. En modo estricto requiere coincidencia exacta; en modo relajado puede aceptar una relación dentro del mismo dominio organizacional.
DMARC pasa cuando al menos un mecanismo válido está alineado. Una firma DKIM válida de un dominio sin relación no alcanza. El estándar destaca esta razón: cualquier actor puede firmar con un dominio que controla.
La política DMARC también indica qué tratamiento solicita el dueño del dominio para mensajes que fallan, como monitorear, poner en cuarentena o rechazar. El receptor conserva sus propias decisiones operativas.
Dónde mirar en los encabezados
Los clientes de correo suelen ofrecer “Mostrar original” o “Ver encabezados”. La línea Authentication-Results añadida por la infraestructura receptora puede resumir SPF, DKIM y DMARC. Hay que preferir el resultado generado por el servidor de confianza más cercano al buzón.
Una cabecera pegada dentro del cuerpo puede ser inventada. También existen múltiples Received y Authentication-Results por el recorrido. El análisis debe respetar el orden y no confiar en campos agregados antes de entrar al proveedor receptor.
Para soporte, conviene exportar el mensaje original con acceso restringido. No reenviar capturas que exhiban direcciones, patentes o enlaces con tokens.
Tres mensajes sintéticos de laboratorio
En el caso A, un servidor autorizado envía desde un dominio de rebotes, DKIM firma con el dominio visible y DMARC pasa por alineación DKIM. Es compatible con una configuración legítima.
En el caso B, SPF pasa para dominio-atacante.example y DKIM también firma con ese dominio, pero From muestra [email protected]. DMARC falla porque no hay alineación. Los mecanismos funcionaron; la identidad visible no quedó autenticada.
En el caso C, SPF falla, DKIM pasa y está alineado. DMARC puede pasar por DKIM. Esto demuestra por qué contar dos verdes de tres sin entender la relación produce falsos diagnósticos.
Los dominios son reservados y los mensajes sintéticos. El experimento no usa correos reales de clientes.
Revisar enlaces y contexto después de autenticar
Un mensaje autenticado todavía puede enlazar un dominio inesperado, un acortador o una descarga. Pasá el cursor sin abrir y compará el host real con el dominio documentado. Cuidado con caracteres parecidos, subdominios engañosos y parámetros que contienen secretos.
La alerta debería evitar adjuntar información sensible. Un equipo puede definir que nunca se solicitan contraseñas, códigos o pagos desde un email. Esa regla simple ayuda incluso cuando alguien no interpreta encabezados.
También conviene comparar horario, tipo de evento y destinatario con las preferencias de la cuenta. Una alerta fuera de patrón no prueba fraude, pero justifica confirmación.
Evidencia y escalamiento para una flota
El procedimiento interno puede guardar identificador del mensaje, fecha de recepción, resultados de autenticación, dominios alineados y decisión tomada. No necesita copiar todo el contenido a una planilla ni registrar la patente completa.
Si falla DMARC o el enlace no coincide, el equipo de seguridad necesita el original, no sólo una captura. Si el mensaje es legítimo pero autentica mal, el responsable del dominio debe revisar sus proveedores, selectores DKIM y políticas SPF/DMARC antes de endurecer el rechazo.
La conclusión combina señales
La autenticidad no es un icono. Surge de una cadena: mensaje presente en el canal oficial, servidor autorizado, firma verificable, alineación con el dominio visible, enlaces esperados y contexto coherente.
SPF responde quién podía usar una identidad de envío; DKIM, quién firmó contenido; DMARC, si esa autenticación se alinea con el autor visible. Mantener esas preguntas separadas hace que una alerta de flota sea auditable y evita que un logo decida por todo el sistema.
Metodología
- Alcance
- Procedimiento de revisión de mensajes sintéticos de un dominio de laboratorio con SPF, DKIM y DMARC.
- Unidad de análisis
- Un email y sus encabezados originales, clasificado por autenticación, alineación, enlaces y confirmación en canal alternativo.
- Cobertura
- RFC 7208, RFC 6376 y RFC 7489 consultados el 14 de agosto de 2026; ejemplos sin direcciones ni dominios operativos reales.
Limitaciones
- Los encabezados pueden ser complejos y deben interpretarse desde la copia recibida por un servidor confiable, no desde texto pegado por el remitente.
- La autenticación de dominio no detecta por sí sola una cuenta comprometida, un proveedor autorizado abusado ni todo contenido malicioso.
Fuentes
- RFC 7208, Sender Policy Framework for Authorizing Use of Domains in Email — RFC Editor (consultada el )
- RFC 6376, DomainKeys Identified Mail Signatures — RFC Editor (consultada el )
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance — RFC Editor (consultada el )
Preguntas frecuentes
¿SPF pass confirma el remitente que veo en la bandeja?
No necesariamente. SPF valida una identidad del sobre SMTP o HELO. DMARC agrega la comprobación de alineación con el dominio del campo From visible.
¿DKIM pass garantiza que el email es seguro?
No. Confirma que una firma válida cubre ciertas partes del mensaje para el dominio firmante. Un dominio legítimo o una cuenta pueden ser comprometidos, y una firma no evalúa la intención de un enlace.
¿Qué hago si una alerta pide pagar o iniciar sesión con urgencia?
No uses el enlace del mensaje. Abrí el sitio desde un marcador o escribí el dominio conocido, verificá la alerta dentro de la cuenta y contactá al canal habitual si hay diferencias.
Notas relacionadas
Webhooks de nuevas multas: idempotencia, reintentos y trazabilidad
Un webhook confiable puede llegar más de una vez, demorarse o fallar después de ser procesado. El diseño debe deduplicar eventos, reintentar con límites y conservar evidencia de punta a punta.
Avisar antes de quedarse sin cuota de consultas de multas
Avisar que la cuota está por agotarse sirve sólo si queda tiempo para actuar. El nivel consumido no alcanza: hacen falta ritmo, fecha proyectada, un destinatario con nombre y una acción escrita.
Cursores estables para paginar resultados que pueden cambiar mientras se leen
Si una colección cambia entre la primera y la última página, el offset puede repetir u omitir resultados. Un cursor ligado a una revisión conserva un corte auditable.