The Attachment Inside the Attachment: How Nested RFC822 Messages Evade Parser-Based Detection

The email carried two attachments. One was a 76,583-byte message/rfc822 file with control characters injected into its filename. The other was a delivery-status notification that the gateway could not retrieve at all. Between them, they represent two distinct failure modes in how email security tools process what they cannot cleanly parse.

In April 2026, IRONSCALES flagged a phishing email targeting an enterprise organization. The sender had never contacted the recipient before. The sending domain published DMARC at p=none, offering monitoring with zero enforcement. And the primary payload was not a link or a credential form. It was an email hidden inside an email.

A Message Wrapped in a Message

The message/rfc822 MIME type is part of the original Internet Message Format specification (RFC 5322). It allows a complete email, headers and body included, to be embedded as an attachment within another email. Forwarded messages, bounce notifications, and delivery status reports all use this structure legitimately.

Attackers use it for a different reason. A nested RFC822 attachment creates a second layer of content that many Secure Email Gateways (SEGs) do not fully recurse into. The Verizon 2024 Data Breach Investigations Report found that 68% of breaches involved a human element, and attachment-based social engineering remains one of the most reliable delivery mechanisms because it shifts the parsing burden from the recipient to the security stack.

The nested message in this case was 76,583 bytes. That is large enough to contain a full HTML body, embedded images, or additional nested attachments. But the filename is where the evasion technique lived.

Where Parsers Disagree

The attachment filename contained CR/LF (Carriage Return / Line Feed) characters, the control characters that define line endings in email protocols. Injecting CR/LF into a filename is not accidental. It exploits a known class of inconsistencies in how different email parsers handle unexpected characters in MIME headers.

Some parsers truncate the filename at the first control character. Others strip the characters and process the remainder. Others reject the attachment entirely. And some pass it through unchanged, letting the email client interpret the result. This is not a theoretical concern. MITRE ATT&CK T1027 (Obfuscated Files or Information) documents techniques where attackers deliberately craft file metadata to confuse automated analysis tools, and MIME header manipulation is a well-established variant.

The practical result: a security tool that truncates the filename may classify the attachment differently than one that strips and reprocesses. In a layered security environment where multiple tools inspect the same message, this inconsistency can create gaps where no single tool fully inspects the content.

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

The Attachment That Vanished

The second attachment was a delivery-status notification, a standard MIME type used for bounce messages and read receipts. Except in this case, the content could not be retrieved for inspection. The attachment metadata was present in the headers, but the body was either malformed, empty, or structured in a way that the retrieval pipeline could not process.

This creates a genuine blind spot. Security tools that log "attachment present" but cannot extract and scan the content are effectively reporting a known unknown. The Microsoft Digital Defense Report 2024 notes that attackers increasingly test email delivery paths to identify which attachment types and structures bypass inspection at specific targets. An unretrievable attachment may not contain the payload. It may simply be probing the inspection boundary.

The DMARC Enforcement Gap

The sending domain published DMARC at p=none. That policy tells receiving servers to accept the message regardless of authentication results and simply report the outcome back to the domain owner. According to analysis from Agari (now Fortra), over 70% of domains that publish DMARC records still use p=none, meaning the vast majority of DMARC deployments provide no protection against spoofing.

For this email, p=none meant that even if SPF and DKIM had failed, the message would still have been delivered. Combined with the first-time sender context, the absence of DMARC enforcement removed one of the most basic authentication-based filtering mechanisms.

MITRE ATT&CK Mapping

• T1566.001 (Phishing: Spearphishing Attachment): Malicious content delivered as an email attachment targeting a specific recipient.
• T1036.005 (Masquerading: Match Legitimate Name or Location): The nested RFC822 structure mimics legitimate forwarded messages and delivery notifications.
• T1027 (Obfuscated Files or Information): CR/LF character injection in the attachment filename designed to confuse parser-based inspection.

Indicators of Compromise

Parsing Is Not Understanding

Themis, the IRONSCALES Adaptive AI, flagged this message based on a combination of signals that no individual parser-level check would have caught. The first-time sender context, the anomalous attachment structure, the DMARC enforcement gap, and the unretrievable second attachment formed a behavioral profile that deviated from normal communication patterns.

The FBI IC3 2024 Annual Report recorded over 298,000 phishing complaints in 2024, with attachment-based delivery remaining a top vector. Security teams that rely on content inspection alone are inherently limited by what their parsers can extract. When an attacker designs the payload specifically to exploit parser inconsistencies, behavioral detection that evaluates the message in context, not just the bytes on disk, becomes the last line of defense. If your security stack cannot inspect it, it needs to be able to reason about why it cannot inspect it.