Email Security • DeliveryLocation • Microsoft Defender XDR

The Email Was Delivered — But Nobody Ever Saw It

The sender swore they sent it.

The recipient swore they never received it.

Message tracing showed the email had been delivered. Agent Foskett wanted to know where it really went.

Discuss your email security Back to briefings

Agent Foskett Microsoft Defender XDR DeliveryLocation email investigation

Briefing summary

An executive reported that an important email never arrived. Initial checks confirmed the message had successfully passed through Microsoft 365 and was marked as delivered. The investigation ultimately revealed that delivery does not always mean the message reached the inbox.

Message Delivered = Yes

Inbox Delivery = No

DeliveryAction = Delivered

DeliveryLocation = JunkFolder

What is DeliveryLocation?

DeliveryLocation records where Microsoft ultimately placed the message, not just whether the message was accepted.

DeliveryAction says what happened DeliveryAction may show that the message was delivered, blocked, quarantined or otherwise acted on by Microsoft 365 filtering.

DeliveryLocation says where it went DeliveryLocation helps explain whether the email reached the Inbox, Junk Email, Quarantine, Deleted Items or another final location.

Delivered does not always mean Inbox A message can be accepted by Microsoft 365 and still never appear where the user expected to see it.

The investigation begins

The first evidence seemed to support both sides of the story.

The sender had proof The sender supplied the exact subject line, approximate delivery time and recipient address. From their side, the message had definitely been sent.

Message trace looked clean No bounce message appeared. No transport rule blocked the email. No obvious malware verdict explained the missing message.

The user still could not find it The recipient checked the Inbox and insisted the message was not there. The investigation needed a more precise answer than delivered.

The KQL investigation

Agent Foskett queried EmailEvents to compare DeliveryAction with DeliveryLocation.

EmailEvents
| where TimeGenerated > ago(30d)
| where Subject contains "Invoice"
| project
    Timestamp,
    SenderFromAddress,
    RecipientEmailAddress,
    Subject,
    DeliveryAction,
    DeliveryLocation

What the logs revealed

The email had been delivered. It had not been delivered to the Inbox.

DeliveryAction = Delivered Microsoft 365 accepted the email and completed delivery. That confirmed the sender was not imagining the event.

DeliveryLocation = JunkFolder The message was not sitting in the Inbox. Microsoft filtering had placed it into Junk Email based on the final delivery decision.

Both people were right The sender was right that the message was delivered. The recipient was right that it never appeared in the Inbox.

Common DeliveryLocation values

DeliveryLocation helps analysts explain where the message actually landed.

Inbox The message was delivered directly into the user's mailbox where they would normally expect to see it.

JunkFolder The message was considered suspicious, unwanted or lower confidence and was moved away from the Inbox into Junk Email.

Quarantine The message was isolated before reaching the user's mailbox, often due to policy, threat verdicts or filtering configuration.

DeletedItems The message was routed to Deleted Items, which may happen through rules, policy, user action or automated processing.

HostedContentFilterPolicy The message was processed according to filtering policy before the final handling decision became visible in the investigation.

OnPremises The message was routed into an on-premises mail environment, which may require hybrid investigation outside Defender alone.

Why this matters

Missing email investigations often fail because analysts stop at the word delivered.

Delivered does not mean Inbox Security investigations frequently stop once DeliveryAction reports Delivered. DeliveryLocation often reveals a different story.

User reports can be accurate The sender may be correct. The recipient may also be correct. DeliveryLocation helps explain why both perspectives can be true.

Email security tuning Repeated JunkFolder or Quarantine placements can indicate filtering issues, reputation concerns, sender alignment problems or policy tuning opportunities.

Agent Foskett moment

The investigation was not about whether delivery occurred. It was about where the message actually ended up.

The sender was right The message had been sent and Microsoft 365 had accepted it. There was no bounce and no obvious transport failure.

The recipient was right The message was not in the Inbox. From the user's perspective, it had never arrived where they expected it.

One field changed the story DeliveryLocation turned a missing email dispute into an evidence-based explanation of final message placement.

How defenders can investigate

Use DeliveryLocation as part of the email investigation timeline, not as an afterthought.

Compare action and location Always review DeliveryAction and DeliveryLocation together. One explains the decision, the other explains the final destination.

Check authentication and sender evidence Review EmailAuthenticationResults, AuthenticationDetails, SenderFromAddress and SenderMailFromAddress when messages are repeatedly sent to Junk or Quarantine.

Pivot into user impact After locating the message, check whether the user opened it, clicked links, downloaded attachments or reported the message.

Questions every analyst should ask

When a user says an email never arrived, the first question should not only be whether it was delivered.

Where did Microsoft place it? Was the message delivered to Inbox, JunkFolder, Quarantine, DeletedItems or another location?

Why was it placed there? Was the placement caused by policy, reputation, authentication, content filtering, user action or mailbox rules?

Did the user interact with it? The final location matters, but the investigation should continue if the user opened, clicked or acted on the message.

Related investigations

The Email Passed SPF, DKIM and DMARC — Why Did Composite Authentication Still Fail? Understand why email authentication passing does not always mean the message deserves trust. Read more →

Investigating EmailAuthenticationResults in Microsoft Defender XDR Understand the authentication evidence stored in Defender email telemetry. Read more →

Microsoft Defender Email Security KQL Queries Use Defender XDR telemetry to investigate spoofing indicators and suspicious sender behaviour. Read more →

Detect DMARC Fail Emails in Microsoft Defender Find and investigate messages where DMARC failures may indicate spoofing or alignment problems. Read more →

SenderFrom vs SenderMailFrom Compare visible sender identity with envelope sender evidence during email investigations. Read more →

AuthenticationDetails Explained Learn how authentication details help explain why a message passed, failed or deserved further review. Read more →

Final thought

Email delivery investigations are rarely solved by one field alone.

At GEMXIT We help organisations investigate Microsoft Defender XDR, email security, phishing, spoofing, Microsoft 365 security and practical threat hunting. If you want to understand how this applies to your environment, see our Microsoft Security services.

Agent Foskett mindset Do not stop at Delivered. Ask where the message went, why it landed there and whether the user ever interacted with it.

The sender was right. The recipient was right. The email was delivered, but not to the Inbox. Explore related investigations including Composite Authentication, Investigating EmailAuthenticationResults, and SenderFrom vs SenderMailFrom.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD