ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Microsoft Defender XDR • UrlClickEvents

The Link Was Clicked After The Email Was Delivered

The email was delivered. No malware alert. No quarantine action. No user complaint.

At first glance, nothing looked suspicious.

But hidden inside AuthenticationDetails was a small piece of telemetry most teams never investigate.

dmarc=fail

The message reached the mailbox. The dashboard stayed quiet. The logs already knew the sender could not be trusted.

This Agent Foskett investigation explores how defenders can use Microsoft Defender XDR, EmailEvents, NetworkMessageId, UrlClickEvents and KQL to determine whether users clicked links after suspicious emails reached the inbox.

Discuss email investigations Back to Investigation Hub
Agent Foskett investigates DMARC failures in Microsoft Defender XDR EmailEvents
Briefing summary

A delivered email is not always a trusted email. AuthenticationDetails can reveal SPF, DKIM, DMARC and composite authentication results that explain whether the sender passed the checks defenders depend on.

Find DMARC failures in EmailEvents
Review AuthenticationDetails
Use KQL to pivot from clue to context
🚨 DMARC failure is not the end of the investigation.
It is the first clue. The real question is whether the failure came from a harmless sender configuration issue or a message that should never have been trusted.
Book a security review →

Why AuthenticationDetails matters

EmailEvents can show who sent a message, who received it and what happened to it. AuthenticationDetails helps explain whether the sender authentication behind that message looked trustworthy.
SPF checks sending infrastructureSPF helps determine whether the sending server was authorised to send mail for the domain used in the message.
DKIM checks message signingDKIM helps confirm whether the message was signed by a domain that can be validated through DNS.
DMARC checks alignmentDMARC helps determine whether SPF or DKIM aligned with the visible sender domain. A failure can be an important spoofing clue.

First hunt: find DMARC failures

Start with the exact clue. This query looks for messages where AuthenticationDetails contains dmarc=fail, then projects the fields defenders need to begin reviewing the sender, recipient, subject and authentication evidence.
find-dmarc-failures.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          AuthenticationDetails
| order by Timestamp desc
What to reviewLook at the sender domain, recipient, subject, authentication details and whether the message was expected by the organisation.
Why it mattersA DMARC failure can reveal impersonation attempts, SaaS misconfiguration, third-party sender issues or spoofed mail that reached a user.
Best next pivotReview delivery action, threat type, URLs, attachments, user clicks and whether similar messages reached other recipients.

Second hunt: add delivery action and threat context

A DMARC failure becomes more useful when you can see what happened to the message. Was it delivered, junked, quarantined or blocked? Did Defender assign any threat type?
dmarc-failures-with-delivery-context.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| project Timestamp,
          SenderFromAddress,
          SenderMailFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          ThreatTypes,
          AuthenticationDetails
| order by Timestamp desc

When DMARC failure deserves deeper investigation

Not every DMARC failure is malicious. The investigator mindset is to separate expected sender issues from messages that show signs of spoofing, impersonation or business email compromise.
Look for impersonation languageUrgent payment requests, invoice changes, password prompts, document sharing themes and executive-style requests deserve extra attention.
Check sender alignmentCompare SenderFromAddress, SenderMailFromAddress and any visible sender branding. Misalignment can explain why DMARC failed.
Correlate with user actionA delivered DMARC failure becomes more serious if the user clicked a link, opened an attachment or replied to the message.

Third hunt: group DMARC failures by sender

Grouping can show whether you are dealing with a single odd message, a noisy third-party platform, a misconfigured business sender or a repeat spoofing pattern.
group-dmarc-failures-by-sender.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| summarize Messages = count(),
            Recipients = dcount(RecipientEmailAddress),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
          by SenderFromAddress
| order by Messages desc

Fourth hunt: pivot from DMARC failure to user clicks

A DMARC failure with no user interaction may still matter. A DMARC failure followed by a click deserves immediate attention. NetworkMessageId can help connect the email event to URL click telemetry.
dmarc-failure-to-url-clicks.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| project EmailTime = Timestamp,
          NetworkMessageId,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject
| join kind=leftouter (
    UrlClickEvents
    | project ClickTime = Timestamp, NetworkMessageId, Url, ActionType
) on NetworkMessageId
| order by EmailTime desc

What DMARC failure can prove

DMARC failure alone does not prove malicious intent. It proves that sender authentication did not align in the way defenders expect. That makes it a clue worth testing against context.
Possible spoofingThe visible sender may not align with the domain that actually authenticated the message.
Possible sender misconfigurationA legitimate third-party service may be sending mail without SPF, DKIM or DMARC alignment correctly configured.
Possible business riskIf the message was delivered and interacted with, the risk moves from authentication failure into incident investigation.

The Agent Foskett investigator mindset

Do not stop at dmarc=fail. Do not stop at delivery action. Do not stop at the first result. Follow the message until you understand whether it was expected, misconfigured or dangerous.
Ask why it failedWas SPF missing? Did DKIM fail? Did the domains fail alignment? Was the sender using a third-party platform incorrectly?
Follow what happened nextCheck whether the message was delivered, clicked, forwarded, replied to or connected to later endpoint or sign-in activity.
Correlate the weak signalsDMARC failure, suspicious sender, delivered action and a user click together tell a stronger story than any one field alone.

How GEMXIT approaches email investigations

GEMXIT helps organisations use Microsoft Defender XDR telemetry to move beyond surface-level email alerts and into practical investigation workflows that explain what really happened.
We review email visibilityWe help check whether Defender email telemetry is available, useful, retained and connected to wider Microsoft security operations.
We build hunting logicWe help turn EmailEvents, UrlClickEvents, EmailAttachmentInfo, identity telemetry and endpoint telemetry into real investigation workflows.
We improve response readinessWe help teams understand when to purge email, reset credentials, block senders, review user clicks and escalate suspicious messages.
The email was delivered. The authentication failed.
GEMXIT helps organisations investigate Microsoft Defender XDR email telemetry, DMARC failures, sender authentication, user clicks and KQL hunting workflows.
Contact GEMXIT

Final thought

A delivered email can still be suspicious.

A quiet dashboard can still miss the story.

A single authentication field can change the investigation.

DMARC failed.

But was it a misconfigured sender, a trusted platform, a broken marketing system or someone pretending to be a domain they did not control?

The failure was not the answer. It was the first clue.
At GEMXITWe help organisations investigate Microsoft Defender XDR, Microsoft Sentinel, Entra ID, email telemetry, sender authentication, user clicks and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Did the email get delivered?”

It is: “What did AuthenticationDetails reveal?”

Continue the investigation with The Email Came From Me, KQL Email Spoofing, EmailEvents KQL Guide, DMARC Failures KQL, Detect DMARC Fail Emails in Microsoft Defender, Microsoft Defender KQL Threat Hunting Complete Guide, Microsoft Defender and the GEMXIT Security Review.

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The Link Was Clicked After The Email Was Delivered

This Agent Foskett investigation explains how Microsoft Defender XDR EmailEvents, NetworkMessageId, UrlClickEvents and KQL can reveal whether users clicked links after suspicious emails reached the inbox.

Microsoft Defender XDR URL click investigation

GEMXIT helps organisations investigate delivered email, suspicious links, URL clicks, NetworkMessageId pivots, EmailEvents, UrlClickEvents, AuthenticationDetails and Microsoft Defender Advanced Hunting telemetry.

EmailEvents, NetworkMessageId and UrlClickEvents threat hunting

NetworkMessageId can help defenders connect delivered emails to URL click activity, user interaction, suspicious destinations and post-delivery investigation workflows in Microsoft Defender XDR.