ACSC Logo
© GEMXIT
GEMXIT Logo
Email Security • DMARC • SMTP Identity

The Email Came From Me

The message looked legitimate. It came from the same address it was sent to. But there was no breach, no suspicious login and no mailbox compromise. It was identity spoofing at protocol level — and a reminder that trust without verification is exactly what attackers exploit.

This is why stronger identity and access enforcement matters beyond sign-ins alone. Email trust is part of identity too.

Discuss your environment Back to briefings
Agent Foskett Friday Cyber Briefings
Briefing summary

The email appeared to come from the same address it was sent to. But no account had been breached. The real issue was spoofing — a forged identity being trusted because email authentication and enforcement were not strong enough.

No unusual sign-ins
No mailbox compromise
Spoofed domain identity

What you'll learn on this page

This investigation explains how an email can appear to come from your own address without a mailbox breach, and how to prove the difference between account compromise and domain spoofing.
1. What happened The email looked internal, but the identity was forged. 2. What we checked first Validate sign-ins, mailbox rules and Defender evidence before assuming breach. 3. Why spoofing works Attackers borrow identity and rely on user trust. 4. SPF, DKIM and DMARC Understand the controls that prove or reject sender identity. 5. Continue the investigation Follow related EmailEvents, DMARC and sender alignment guides. 6. FAQ Answer common Microsoft 365 email spoofing questions.

What happened

The message looked legitimate, but the trust behind it was fake.
The email looked real It appeared to come from the same address it was delivered to. It looked like a normal DocuSign-style notification with a button inviting a click.
The hidden clue The link behind the button redirected through unrelated domains. That was the giveaway. The visible identity looked safe, but the path behind it did not.
What it was not No breach. No suspicious mailbox access. No login alert. No account compromise. The correct conclusion was impersonation, not intrusion.

What we checked before panicking

Good investigations verify signals first, then decide whether the issue is compromise or impersonation.
identity-and-email-checks.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
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
let TargetUser = "user@yourdomain.com";
let RecentSignins =
SigninLogs
| where UserPrincipalName =~ TargetUser
| where TimeGenerated > ago(7d)
| project
                            TimeGenerated,
                            UserPrincipalName,
                            IPAddress,
                            AppDisplayName,
                            ResultType,
                            Location = strcat(tostring(LocationDetails.city), ", ", tostring(LocationDetails.countryOrRegion));

let InboxRuleActivity =
OfficeActivity
| where UserId =~ TargetUser
| where Operation in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox")
| project
                            TimeGenerated,
                            UserId,
                            Operation,
                            ClientIP;

let MailboxSuspicion =
EmailEvents
| where RecipientEmailAddress =~ TargetUser
| where SenderFromAddress =~ TargetUser
| project
                            Timestamp,
                            SenderFromAddress,
                            RecipientEmailAddress,
                            Subject,
                            AuthenticationDetails,
                            ThreatTypes,
                            UrlCount;

RecentSignins
| union InboxRuleActivity
| order by TimeGenerated desc
Identity checks No unusual Microsoft Entra ID sign-ins, no suspicious IP pattern and no sign that the account itself had been used to send the message.
Mailbox checks No forwarding rules, no inbox tampering, no hidden mailbox persistence. The mailbox was not the attack path.
Mindset shift That is the key investigation moment: stop chasing compromise and start testing whether the identity was simply forged.

Why this works

Attackers do not always need to hack accounts. Sometimes they just need to borrow your identity.
SMTP trust is easy to abuse Attackers can forge a sender address and borrow the appearance of your identity. That is enough to trigger trust in people who think familiar means safe.
The instinct attackers rely on “If it came from me, it must be safe.” That split-second assumption is often enough to get a click.
Headers matter When the message headers, sending infrastructure and redirect chain do not align with the claimed sender, the email is telling you the identity is fake even if the From field looks correct.

The controls that actually matter

This is where most environments fall short: authentication without enforcement is not enough.
SPF SPF defines which mail servers are authorised to send on behalf of your domain. It helps, but by itself it does not guarantee trust or stop spoofing cleanly.
DKIM DKIM cryptographically signs outbound mail to prove authenticity and protect message integrity. It is a strong signal, but not the final enforcement layer.
DMARC DMARC is the policy control that tells the receiving system what to do when SPF or DKIM alignment fails. This is where trust enforcement actually happens.
Without enforcement If SPF fails but DMARC is not enforced, spoofed messages can still land. If DKIM is missing but policy is weak, the receiver may still trust what it should not.
Security is trust enforcement Email security is no longer just about spam filtering. It is about proving identity properly and defining what happens when identity fails verification.
The real test If an email came from your own domain today, would your environment trust it automatically — or reject it because the identity could not be verified?

Email spoofing investigation workflow

When a user says “the email came from me,” the first job is to avoid jumping to the wrong conclusion. Prove whether this was mailbox compromise, forwarding/persistence, or spoofed sender identity.
Step 1: Check sign-ins Review Microsoft Entra ID sign-ins, unfamiliar IP addresses, impossible travel, risky locations and unexpected applications.
Step 2: Check mailbox persistence Look for inbox rules, forwarding rules, mailbox delegation and suspicious OfficeActivity events.
Step 3: Check EmailEvents Confirm sender, recipient, AuthenticationDetails, DeliveryAction, UrlCount and NetworkMessageId.
Step 4: Compare sender identity Validate SenderFromAddress, SenderFromDomain, SenderMailFromDomain and whether the message truly aligned.
Step 5: Check links and clicks Inspect the URL chain and pivot into UrlClickEvents to see whether a user interacted with the message.
Step 6: Fix trust enforcement Review SPF, DKIM and DMARC enforcement so forged identity is rejected instead of trusted.
DMARC Fail Emails Find emails where authentication failed but delivery still occurred. Read more →
AuthenticationDetails explained Detecting DMARC failures is only the first step.

Understand how SPF, DKIM and DMARC actually aligned — and why an email may still have been delivered. Read more →
EmailEvents investigation guide Understand how EmailEvents reveals sender details, authentication results and delivery behaviour behind DMARC failures.
Why it looked real The sender appeared correct — but the underlying domain told a different story.

SenderFrom and SenderMailFrom don’t always match.

Understand the difference →
Spoofed Sender Domains Detect mismatched sender domains and potential spoofing attempts. Read more →
KQL Threat Hunting Guide Full investigation playbook across Defender, identity and endpoint. Read more →

Continue with practical KQL evidence

These pages turn the story into repeatable KQL workflows for Microsoft Defender XDR and Microsoft 365 email security.
Email Spoofing KQL Investigation Use EmailEvents, AuthenticationDetails and sender alignment to investigate suspicious email in Microsoft 365. DMARC Failures KQL Investigate dmarc=fail results, delivery actions and URL click pivots in Microsoft Defender XDR. SenderFrom vs SenderMailFrom Understand why the visible sender and envelope sender can tell different stories. The EmailAuthenticationResults Looked Fine See why email authentication results still need context and investigation judgement. The Email Passed SPF But Was Still Malicious Understand why SPF alone is not the same as complete sender trust. The User Clicked The Link Three Days Later Follow the investigation from suspicious email delivery into delayed user click activity.

Learn the KQL behind this case

These Academy lessons support the operators used in this investigation and help readers move from story to repeatable hunting.
What is KQL? Start with how KQL helps analysts ask better questions of security data. Microsoft Security Tables Understand where EmailEvents, UrlClickEvents and identity data fit in the investigation. Filtering KQL Results Use where filters to focus on one user, one sender or one suspicious message. Using has_any Search AuthenticationDetails for SPF, DKIM and DMARC failure strings. Connecting Tables with join Link EmailEvents to UrlClickEvents and identity evidence using shared fields and timestamps. Building Investigation Timelines Put sign-ins, mailbox activity, delivery and clicks into one investigation story.

Frequently asked questions

Can an email really appear to come from my own address?

Yes. Email sender fields can be spoofed. A message can appear to come from your own address even when your mailbox was not breached, especially if email authentication and DMARC enforcement are weak.

Does “the email came from me” always mean my Microsoft 365 account was compromised?

No. You should check sign-ins, mailbox rules and mailbox activity first. If those are clean, the issue may be sender spoofing rather than account compromise.

What Microsoft Defender evidence helps investigate this?

EmailEvents, AuthenticationDetails, DeliveryAction, NetworkMessageId, UrlClickEvents, SigninLogs and OfficeActivity can help confirm whether the message was spoofed, delivered, clicked or connected to account activity.

How do SPF, DKIM and DMARC help stop spoofed email?

SPF defines authorised senders, DKIM signs messages, and DMARC tells receiving systems what to do when sender identity does not align. DMARC enforcement is what turns authentication into action.

If DMARC isn’t set to reject,
you don’t control your identity. Attackers do.
Contact GEMXIT

Final thought

Identity is not just about sign-ins. It is also about whether the outside world can trust your domain.
At GEMXIT We help organisations look beyond the obvious and verify whether identity, trust and enforcement are actually working the way they think they are. If you want help reviewing this properly, see our Cyber Security services.
Agent Foskett mindset The email looked legitimate because identity was not being verified strongly enough. Trust without enforcement is not security.

If your environment has Microsoft security tools but your mail identity controls are still weak, the next step is closing that trust gap properly. 👉 Review Microsoft security operations and identity protection

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

Email Spoofing and Domain Impersonation Explained

This article explains how spoofed email can appear to come from your own address even when there has been no compromise, and why identity impersonation is still highly effective.

Why SPF, DKIM and DMARC Matter

SPF and DKIM help validate email sources, but DMARC provides the enforcement layer that tells the world how to treat messages that fail identity checks.

Why DMARC Reject Protects Trust

If DMARC is not enforced, attackers can continue spoofing your domain and exploiting trust. Email security is no longer just filtering — it is trust enforcement.