¿Ves cientos de registros en el Message Trace con el remitente ttsender@microsoft.com y estado GettingStatus, sin IP ni encabezados y sin correos reales en buzones? Aquí tienes la explicación breve, el impacto real y pasos prácticos para ocultarlos de tus reportes.
Resumen del problema
Administradores de Exchange Online y Microsoft 365 reportan múltiples entradas en el Message Trace del Centro de administración de Exchange (EAC) con remitente ttsender@microsoft.com y estado GettingStatus. Estas entradas no muestran IP de origen ni encabezados SMTP y no se corresponden con mensajes reales entregados a los usuarios. El volumen puede “ensuciar” informes, auditorías y paneles internos.
Conclusión rápida
- No es spam ni phishing: no hay entrega a usuarios.
- No afecta la entrega: es telemetría interna asociada al análisis de adjuntos de Microsoft Defender para Office 365 (p. ej., Safe Attachments con Dynamic Delivery).
- Es un fallo de visibilidad en la interfaz de Message Trace (un “GUI glitch”).
- Solución operativa: filtra/excluye estas entradas en vistas, búsquedas y reportes. No las bloquees.
Qué está pasando (explicación técnica breve)
Cuando Microsoft Defender para Office 365 analiza adjuntos —especialmente con Safe Attachments (Dynamic Delivery)— se generan eventos internos de procesamiento. Algunos de esos eventos se reflejan en el Message Trace como si fuesen mensajes con remitente ttsender@microsoft.com y estado GettingStatus. En realidad, no hay un correo que viaje por el flujo habitual ni una entrega a un buzón; se trata de telemetría interna expuesta por error en la interfaz de rastreo.
Microsoft reconoció que ver estos eventos internos en el trace es un problema de visualización en el portal (no deseado). Son inofensivos para la seguridad y la entrega. En su momento, comunicaron que estaban trabajando en la corrección, sin comprometer fecha.
Evidencias prácticas que observarás
- Correlación temporal: es habitual que, cuando un adjunto termina el escaneo y se libera a los destinatarios, aparezca casi en ese mismo momento una entrada de
ttsender@microsoft.comconGettingStatusen el trace. - Aparición sin correos nuevos: algunos inquilinos observan estas entradas incluso cuando no ha llegado un nuevo correo a un buzón. Sigue tratándose de eventos internos de Defender que no impactan la bandeja de entrada.
- Sin IP ni encabezados: a diferencia de un mensaje SMTP normal, no encontrarás cabeceras completas ni la IP de origen, precisamente porque no es un correo que haya recorrido el transporte convencional.
Impacto operativo
| Área | Impacto | Cómo mitigarlo |
|---|---|---|
| Entrega de correo | Sin impacto en usuarios ni pérdida de mensajes. | No actuar; validar entregas reales con Message Trace filtrado. |
| Seguridad | No introduce riesgo adicional; son eventos internos de análisis. | Continuar con políticas de Defender for Office 365 vigentes. |
| Reporting / Métricas | Añade “ruido” y distorsiona conteos de volumen. | Aplicar filtros por remitente y/o estado. Guardar vistas. |
| Auditoría | Puede dificultar revisiones rápidas. | Excluir ttsender@microsoft.com y GettingStatus en búsquedas. |
Qué hacer (recomendado)
- No tratarlo como amenaza: no es spam ni phishing; no genera entregas a usuarios.
- Filtra/oculta en el portal:
- En el Centro de administración de Exchange > Flujo de correo > Rastreo de mensajes, guarda una vista que excluya el remitente
ttsender@microsoft.comy/o el estadoGettingStatus. - En tus reportes o búsquedas avanzadas, aplica filtros equivalentes para no contaminar métricas.
- En el Centro de administración de Exchange > Flujo de correo > Rastreo de mensajes, guarda una vista que excluya el remitente
- Verificación puntual: si deseas confirmar la correlación, envía un correo de prueba a una cuenta de laboratorio con un adjunto. Cuando el adjunto sea liberado por Safe Attachments, observa que suele aparecer la entrada de
ttsenderen el trace. - Monitoreo: sigue el Centro de estado del servicio de Microsoft 365. Si el volumen de “ruido” dificulta auditorías, abre o mantiene un ticket con soporte indicando que es un problema conocido de visibilidad en Message Trace.
Qué NO hacer (ineficaz o contraproducente)
- No bloquees
ttsender@microsoft.comen Tenant Allow/Block List ni crees reglas de transporte (mail flow rules) para “detenerlo”.- No lo evitará: se trata de telemetría interna y no de correo real cursado por el transporte.
- Podrías interferir con procesos legítimos de seguridad o acciones post-entrega.
- No lo escales como incidente de phishing salvo que tengas otros indicios independientes (correos en buzones, clics, etc.).
Cómo ocultarlo del Message Trace (paso a paso)
Opción A: Guardar una vista filtrada en EAC
- Abre el Centro de administración de Exchange.
- Ve a Flujo de correo > Rastreo de mensajes.
- Crea una nueva búsqueda o edita tu consulta habitual.
- En los filtros, agrega:
- Remitente ≠
ttsender@microsoft.com - y/o Estado ≠
GettingStatus
- Remitente ≠
- Ejecuta la consulta para comprobar que los resultados ya no incluyen dichas entradas.
- Guarda la vista con un nombre reconocible, por ejemplo “Trace sin ttsender”.
Opción B: Exportar con PowerShell y depurar
Si trabajas con CSVs o pipelines de auditoría, excluye estos registros desde el origen:
# Ventana de 7 días como ejemplo
$start = (Get-Date).AddDays(-7)
$end = Get-Date
Get-MessageTrace -StartDate \$start -EndDate \$end `| Where-Object {
$.SenderAddress -ne "ttsender@microsoft.com" -and $.Status -ne "GettingStatus"
}`
\| Export-Csv -NoTypeInformation -Encoding UTF8 ".\MessageTrace-Limpio.csv" Para diagnósticos puntuales, puedes listar únicamente lo “ruidoso” y cuantificarlo:
Get-MessageTrace -StartDate $start -EndDate $end `
| Where-Object { $.SenderAddress -eq "ttsender@microsoft.com" -or $.Status -eq "GettingStatus" } `
| Group-Object SenderAddress, Status `
| Sort-Object Count -Descending `
| Format-Table Count, Name
Opción C: Excluir en consultas avanzadas
Si utilizas consultas avanzadas en portales de seguridad o herramientas SIEM, documenta una cláusula de exclusión permanente. Ejemplos conceptuales (ajústalos a tu sintaxis):
# Pseudoconsulta / KQL conceptual
SenderFromAddress != "ttsender@microsoft.com" and Status != "GettingStatus"
Preguntas frecuentes (FAQ)
¿Es un ataque, spam o phishing?
No. Aunque aparezca como remitente ttsender@microsoft.com en el trace, no hay un mensaje entregado a usuarios. Es telemetría interna asociada al análisis de adjuntos de Defender para Office 365.
¿Afecta la entrega de correo?
No. No bloquea, retrasa ni duplica mensajes por sí mismo. Si observas retrasos, investiga otros eventos de transporte o la fase de Dynamic Delivery de Safe Attachments por separado.
¿Por qué no veo IP ni encabezados?
Porque no es un correo que haya recorrido el transporte SMTP normal. Por eso carece de origen IP, Received: hops o cabeceras completas.
¿Cómo lo detengo?
No se “detiene” desde el lado del inquilino: es información interna que accidentalmente aparece en la interfaz. La mitigación práctica es ocultarlo con filtros hasta que Microsoft corrija la visibilidad.
¿Debo crear una regla de transporte o bloquear el remitente?
No. No lo evitará y podrías interferir con procesos legítimos de seguridad. La mejor práctica es filtrar/ignorar en reportes.
Checklist de diagnóstico rápido
- ✔️ Validar si hay correos reales en buzones correlacionados con los registros: normalmente, no.
- ✔️ Revisar si hubo liberación de adjuntos (Safe Attachments) en el mismo intervalo temporal.
- ✔️ Confirmar que los registros carecen de IP y encabezados SMTP.
- ✔️ Aplicar filtros por remitente y estado en Message Trace.
- ✔️ Documentar en runbooks y plantillas de auditoría la exclusión de
ttsender/GettingStatus.
Matriz de “síntoma → significado → acción”
| Síntoma | Significado | Acción sugerida |
|---|---|---|
Remitente ttsender@microsoft.com | Evento interno de Defender (telemetría). | Excluir en búsquedas y reportes. |
Estado GettingStatus | Evento de procesamiento, no entrega a buzón. | Excluir en búsquedas y reportes. |
| Sin IP ni encabezados | No es transporte SMTP ordinario. | No investigar como mensaje recibido. |
| Volumen elevado en ciertos intervalos | Actividad de análisis/lanzamiento de adjuntos. | Ajustar ventanas de consulta y filtros guardados. |
Buenas prácticas de reporting para no “contaminar” métricas
- Vistas persistentes: guarda en el EAC una vista de Message Trace con la exclusión aplicada para tu equipo de soporte y SOC.
- ETL/CSV limpios: al exportar trazas, aplica exclusiones en la etapa de extracción para no heredar ruido a dashboards.
- Documentación: añade una nota visible en tus runbooks: “Excluir
ttsender@microsoft.comyGettingStatusen todas las métricas de volumen y auditoría”. - Versionado de consultas: guarda plantillas de búsqueda y nómbralas de forma inequívoca (“Trace Operativo (sin ttsender)”).
Procedimiento de verificación en laboratorio
- Crea cuentas de prueba Emisor y Receptor en tu inquilino.
- Activa o verifica que Safe Attachments con Dynamic Delivery aplique al Receptor.
- Envía desde Emisor un correo al Receptor con un adjunto “no maligno” pero lo suficientemente grande para forzar análisis.
- Observa en el Receptor la llegada del mensaje sin adjunto (marcado como “está siendo analizado”), y tras la liberación, la aparición del adjunto.
- Abre el Message Trace para ese intervalo y revisa si se generó la entrada de
ttsender@microsoft.comconGettingStatusen el mismo marco temporal.
Monitoreo y comunicación
Si el ruido es significativo:
- Centro de estado: vigila avisos relacionados con rastreo de mensajes o Defender.
- Ticket con soporte: mantén un caso abierto citando que se trata de un problema conocido de visibilidad en Message Trace.
- Comunicado interno: informa a helpdesk/SOC para evitar escalados innecesarios. Ejemplo breve: Se observan entradas de
ttsender@microsoft.comcon estadoGettingStatusen Message Trace. Son eventos internos de análisis de adjuntos de Defender, sin impacto en entrega ni seguridad. Se han creado filtros para excluirlos de reportes.
Errores comunes que debes evitar
- Bloquear el remitente en listas TABL o por reglas: no soluciona el síntoma y puede afectar procesos legítimos de seguridad.
- Escalar como incidente sin verificar bandejas y cabeceras: consume tiempo y genera falsas alarmas.
- Concluir que hay “duplicados” por ttsender: si ves duplicados o fechas atípicas, investígalos por otra vía (políticas de Safe Attachments, Dynamic Delivery, y acciones post-entrega como ZAP). No hay evidencia concluyente de que
ttsenderlos provoque.
Notas complementarias
- Si en hilos o capturas aparece el texto “\\ Email address is removed for privacy \\”, normalmente se refiere a la misma dirección interna utilizada por el sistema.
- La presencia de
ttsender@microsoft.comen el trace no implica por sí misma ninguna acción manual: es un subproducto del pipeline de análisis de Defender. - Los picos pueden coincidir con ventanas de mayor volumen de adjuntos o con liberaciones masivas tras escaneo en cola.
Plantillas útiles para tu equipo
Guía rápida para L1/L2
- Si ves
ttsender@microsoft.comconGettingStatus, no lo trates como incidencia. - Confirma que no existan mensajes en buzones asociados a ese registro.
- Aplica la vista “Trace sin ttsender”.
- Escala a L3 solo si hay evidencia independiente (entregas reales o cabeceras SMTP).
Fragmento estándar de exclusión para reportes
Excluir del cómputo de volumen todos los registros con:
- SenderAddress = "ttsender@microsoft.com"
- Status = "GettingStatus"
Resumen ejecutivo para stakeholders
- Qué es: artefactos de telemetría de Defender mostrados por error en Message Trace.
- Riesgo: nulo para usuarios; solo afecta a la calidad de los reportes.
- Acción: filtrar/ocultar; mantener vigilancia del Centro de estado. No bloquear.
- Estado: Microsoft trabaja en corregir la visibilidad; sin fecha comprometida.
Conclusión
Las entradas de ttsender@microsoft.com con estado GettingStatus en el Message Trace son un artefacto de telemetría derivado del análisis de adjuntos en Microsoft Defender para Office 365. No afectan la entrega ni la seguridad, pero introducen ruido en tus trazas y métricas. La mejor práctica es excluirlas con filtros persistentes en el portal, en tus exportaciones y en tus consultas de auditoría. Evita bloqueos o reglas de transporte que puedan interferir con flujos legítimos. Documenta la exclusión en tus runbooks y comunica al equipo de soporte para reducir falsos positivos y tiempos de investigación.