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

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 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.

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?

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