ACS reports email delivered in seconds, but Outlook headers show about 11 minutes of transport latency

ACS Delivered means the message was successfully handed to the recipient’s mail transfer agent (MTA), not that it had completed Outlook.com filtering, mailbox placement, or become visible in the Inbox.^1^

Interpreting this timeline

• 15:53:04 — ACS accepted the SMTP submission: Your application-to-ACS submission completed.
• 15:53:09 — Outlook.com first accepted the message: X-MS-Exchange-CrossTenant-OriginalArrivalTime identifies when the message first entered Microsoft/Exchange transport.^2^
• 15:53:13 — ACS reported Delivered: ACS had received confirmation that the intended recipient MTA accepted the message. ACS documentation explicitly limits Delivered to successful handoff to that MTA.^1^
• 16:04:18 — later Outlook.com processing/delivery hop: The approximately 11-minute X-MS-Exchange-Transport-EndToEndLatency aligns closely with the interval from Outlook.com’s original arrival at 15:53:09 to this later stamp.

Therefore, the evidence places the unexplained interval after Outlook.com accepted the message, inside the recipient service’s processing path. It does not show an 11-minute ACS queue.

Microsoft’s public documentation identifies OriginalArrivalTime, but does not publish a sufficiently precise Outlook.com definition of the start and end boundaries of X-MS-Exchange-Transport-EndToEndLatency to attribute the interval to one internal component. Plausible stages include protection evaluation, internal transport queuing, mailbox delivery, and final folder-placement processing, but the headers alone cannot establish which one caused this instance.

The later availability of ACS records in Log Analytics is separate. TimeGenerated is the event timestamp; _TimeReceived records when Azure Monitor received the record and can be used to diagnose late-arriving data.^3^

Authentication and filtering

No SPF, DKIM, DMARC, or composite-authentication correction is indicated. Your results show that standard and composite authentication succeeded.^4^

That does not bypass reputation or content filtering. Microsoft evaluates additional signals including sender reputation and history, recipient history, behavior, content, list quality, complaint rates, and sending IP/domain reputation.^5^^6^

Do not treat SCL: 5 alone as proof that spam processing caused the delay. In Microsoft’s cloud filtering stack, SCL no longer independently determines the spam verdict or action. Inspect these fields in the complete headers instead:

• X-Forefront-Antispam-Report: particularly CAT, SFV, IPV, and related verdict fields.
• X-Microsoft-Antispam: including bulk/reputation information.
• Authentication-Results.
• Any headers recording overrides or final delivery disposition.

Microsoft identifies CAT and SFV as more useful than SCL for determining which filtering component acted.^7^^8^

dest:I and OFR:TrustedSenderList are consistent with final Inbox placement and a trusted-sender override, but they do not identify where the preceding 11 minutes were spent.

What to check next

1. Repeat a controlled series, rather than relying on one message:
   • Same sender and recipient, several timestamps.
   • Different Outlook.com/Hotmail/Live recipients, if available.
   • A non-Microsoft recipient as a control.
   • Record message size, attachment presence, send volume, ACS message/correlation ID, ACS delivery timestamp, OriginalArrivalTime, and end-to-end latency.
2. Review ACS status details, especially SmtpStatusCode and EnhancedSmtpStatusCode. ACS status-update logs expose these recipient-server responses and map CorrelationID to the message ID.^9^
3. Check whether the delay correlates with:
   • Outlook.com recipients only.
   • New sending domain/IP activity.
   • Burst volume.
   • Particular content, links, or attachments.
   • Specific CAT, SFV, IPV, or bulk verdicts.

Escalation

Because Outlook.com accepted this message around 15:53:09 and the unexplained latency followed that acceptance, Outlook.com Sender Support is the primary route. The sender-support form explicitly covers @live.com deliverability cases.^6^

Provide privately:

• Full original, unmodified MIME headers.
• UTC timestamps and time zone.
• Recipient domain and affected mailbox address.
• Internet Message-ID.
• ACS operation/message/correlation ID.
• ACS recipient delivery event, SMTP status codes, and enhanced status codes.
• Sending domain and the observed outbound IP from the headers.
• Reproduction frequency and comparison results.
• Confirmation that SPF, aligned DKIM, DMARC, and compauth passed.

Open an ACS support case as a secondary route if ACS cannot supply the recipient SMTP response, its timestamps conflict with the handoff evidence, or the same pre-handoff delay occurs across unrelated recipient providers. ACS troubleshooting uses the email operation/message ID to locate send-status records.^10^

Do not publish recipient addresses, tenant/resource identifiers, message IDs, opaque anti-spam fields, or complete headers; supply them only through the official private case.

References

1. Azure Communication Services - Email events
2. Header firewall
3. Analyze usage in a Log Analytics workspace
4. Security Operations guide for email authentication in Microsoft 365
5. Email authentication in cloud organizations
6. Sender Support in Outlook.com | Microsoft Support
7. Troubleshoot common anti-spam policy issues
8. Spam confidence level (SCL) in Microsoft 365
9. Email logs
10. Troubleshooting in Azure Communication Services