You Sent This Email to Yourself. Except You Didn't.

The email appeared to be sent by the recipient to themselves. The From address matched the To address exactly: a single employee at a regional bank, sent to their own mailbox. The subject line read "Action Required - Proposal Settlement - Citynational //Message ID: fe1fd4..."

The body was empty.

The sending domain had DMARC p=reject. Under strict enforcement, an unauthenticated external message claiming to come from that domain should be rejected before it arrives. This one was caught and analyzed, raising a question about how a self-spoof reaches the evaluation point at all, and why attackers keep trying it.

The Self-Spoof Technique

A self-spoof attack constructs an email where the From address matches the recipient's own address. The intended effect is twofold. First, some email clients and spam filters give elevated trust to messages that appear to come from the recipient's own account. The reasoning is that a message from yourself is unlikely to be external spam. Second, the psychological impact on the recipient is significant: seeing your own address in the From field creates immediate curiosity and a sense of urgency around whatever subject line accompanies it.

"Action Required - Proposal Settlement" with a specific-looking Message ID creates the impression of a real business transaction in progress. A recipient who does not immediately recognize this as a spoofed message is likely to reply asking for context. That reply is the attacker's goal.

The inclusion of "Citynational" in the subject (with capital C and lowercase n, differing from the formal brand styling) mirrors email spoofing without being a direct copy. This subtle variation can bypass brand-name matching rules while retaining the association.

The DMARC Question

The sending domain had DMARC p=reject configured, with MX records pointing to a commercial email security platform. A well-enforced p=reject policy should cause receiving mail servers to reject the message outright when SPF and DKIM cannot authenticate the sending path.

The fact that this message reached the analysis queue rather than being silently dropped suggests one of several scenarios. The message may have been caught pre-delivery by the security platform and quarantined for review rather than being rejected at the MTA level. That is technically a rejection from the inbox's perspective, but it produces an incident record for investigation. Alternatively, the attacker may have used a construction that routes the message in a way that avoids the full DMARC evaluation path, such as submitting to a relay that is on a trust list before the final delivery hop.

For organizations with DMARC p=reject, it is worth verifying that the policy is applied consistently across all inbound delivery paths, including relayed messages, and that quarantine or rejection is enforced at the final MTA rather than only at the perimeter.

Empty Body as Deliberate Attack Design

A BEC attack with an empty body and no links or attachments has exactly zero traditional payload for a security tool to evaluate. No URL to check against threat intelligence. No attachment to detonate. No text for natural language classifiers to analyze. The entire technical attack surface is the From address, the subject line, and a Message ID.

This design is intentional. Social engineering at this level operates on curiosity and urgency, not on technical delivery mechanisms. A recipient who opens the email and sees nothing written will frequently reply to ask what the message was about. That first reply establishes the communication channel the attacker needs.

From there, the typical escalation path is: the attacker responds from a separate, attacker-controlled address (the original self-spoof is now acknowledged as "a mistake" or "test"), and the real fraud request follows. Wire transfer requests, bank account update demands, and invoice payment diversions have all been observed following this initial contact pattern.

Detection Through Behavioral Analysis

Themis, the IRONSCALES Adaptive AI engine, evaluates this message type through behavioral signals that go beyond authentication and payload inspection. The key indicators here are: a From address matching the recipient's own address, an external sending IP inconsistent with the recipient domain's legitimate mail infrastructure, an empty body with an urgency-framed financial subject, and a DMARC p=reject domain where the authentication does not verify.

None of these are individually novel signals. Together, they match the pattern profile of a self-spoof reply-bait BEC setup with high specificity. The detection does not depend on finding a malicious URL or a known threat signature. It depends on recognizing the combination of signals as a coherent attack pattern.

The contrast with a separate major bank brand's domain (which also uses DMARC p=reject with a different commercial email security platform) illustrates that the financial sector broadly has adopted strong DMARC enforcement. The attack was not able to exploit a weak or missing DMARC policy. It was caught at the behavioral layer.

See Your Risk: Calculate how many threats your SEG is missing

What Finance Sector Defenders Should Take From This

Self-spoof attempts against DMARC p=reject domains are a form of probe. They test whether the enforcement is consistent, whether an allow-list bypasses evaluation, and whether the recipient will reply to an apparently self-generated message. Organizations should verify that their DMARC rejection is applied uniformly, that no relay path creates a bypass, and that recipients are trained to treat a self-addressed email with an urgent subject and empty body as an automatic escalation flag.

The Message ID pattern in the subject line (referencing a specific alphanumeric identifier) is a social engineering signal worth including in security awareness training. A real message ID reference in a subject line does not indicate a real transaction.

Indicators of Compromise

MITRE ATT&CK Mapping