Anatomy of an Email Spoofing Attempt
How proactive DMARC enforcement turned a regional brokerage's morning panic into a non-event, with no breach and no client exposure.
How proactive DMARC enforcement turned a morning panic into a non-event.
Client: Regional insurance brokerage (Southern California)
Environment: Microsoft 365 email, managed by Realm Defense
Service: Managed domain security and email authentication
The Situation
Early one morning, a client forwarded an urgent message. He had received several "Undeliverable" bounce notices for emails he had never sent, referencing an unfamiliar subject line and an outside recipient he didn't recognize.
His concern was immediate and reasonable: Is someone sending spam from my account? Has my email been hacked? Should I cancel my devices?
For a brokerage that handles confidential client and policy information, a compromised mailbox isn't an inconvenience. It's a regulatory and reputational threat. The clock was running.
The Investigation
Within minutes, Realm Defense:
- Ran a full message trace across the mailbox for the prior 72 hours
- Confirmed zero outbound mail matching the suspicious subject, and nothing else out of the ordinary
- Verified the account's sign-in history and registered devices (all legitimate, owner-controlled)
- Reviewed the bounce headers to trace the message's true origin
The verdict: no compromise. The mailbox was clean. A hijacked account almost always leaves a trail of sent mail, and there was none.
The Root Cause
The bounce was the symptom of a spoofing attempt, not a breach. A spammer had forged the client's domain in the "From" field of a message sent to an external recipient, and listed the client's address as the return path. When the receiving provider refused the forged message, the failure notice routed back to the client, a phenomenon known as backscatter.
The key point: none of this required any access to the client's account. Forging a "From" address is trivial. The real question is whether the rest of the world's mail servers will accept the forgery, and that comes down to how the domain is configured.
Why It Was a Non-Event
This is where the prior work paid off. Realm Defense had already deployed a hardened email-authentication stack for the domain:
- SPF, DKIM, and DMARC fully aligned and validated
- A DMARC policy of
p=reject, the strictest enforcement level available
Because the domain publicly instructs every receiving server to reject mail that fails authentication, the recipient's provider refused the spoofed message outright. The rejection notice said so in plain terms: delivery denied. The sending domain does not pass DMARC verification and has a policy of reject.
In other words: the bounce the client was worried about was actually proof that his protection worked. The forgery never reached its target, and his brand was never put in front of the intended victim.
The Outcome
- Confirmed and documented: no account compromise
- Client reassured the same morning, with a plain-English explanation
- Domain reputation protected. The spoofed campaign was dead on arrival
- Routine device cleanup handled as quiet back-end housekeeping
What This Means for Your Business
Email spoofing is cheap, constant, and aimed at your clients, vendors, and partners, using your name. Without enforced DMARC:
- Forged invoices and wire-fraud requests reach your clients under your brand
- Your domain's reputation erodes with every spam run that rides on it
- A simple spoof becomes indistinguishable from a real breach, burning hours of panic and investigation
With it, that same attack is silently rejected before anyone sees it.
The difference between a crisis and a non-event is a correctly enforced DMARC policy, configured before the attack, not after.
Is Your Domain Actually Protected?
Most domains either publish no DMARC policy at all, or stop at p=none, monitoring only, with no enforcement. That's an unlocked door.
Realm Defense provides a domain-security assessment that shows exactly how your email authentication would hold up against a real spoofing attempt, and what it takes to reach full p=reject enforcement safely.
Details in this case study have been anonymized to protect client confidentiality.
Need help implementing these practices?
Schedule a Security Review