Email security is built on a mountain of text parsers, and every now and then, someone finds a crack that reminds us just how brittle the foundation is. Today, SEC Consult dropped a write-up showing exactly how they spoofed any iCloud address—including Apple’s CEO—while perfectly passing SPF, DKIM, and DMARC checks.[1]

If you were tracking email security in late 2023, you remember “SMTP Smuggling.” Timo Longin figured out that different mail servers had wildly different ideas about what constituted the end of a message data block. Most of the internet scrambled to patch that. But Longin didn’t stop there. He kept digging, this time looking at Apple iCloud’s internal infrastructure, and found a variation: “From header smuggling."[1]

When you send an email through iCloud, the message passes through multiple internal parsers. Apple uses a custom parser first to verify you are only sending mail from your own authenticated account, followed by a second parser (likely Postfix) that normalizes the message before it leaves their network.

Longin realized that if he injected bare carriage return (<CR>) characters into a fake “From” header, iCloud’s first parser would ignore it and authenticate the real sender address. But the second parser would strip the <CR> characters and pass the fake header along as legitimate. The result was a message that looked to the receiving server like it came directly from admin@icloud.com or tim.cook@icloud.com.

The most unsettling part of this isn’t just the spoofing itself—it’s how the authentication protocols reacted. Because the message was legitimately signed by iCloud’s infrastructure after the second parser, all cryptographic checks like DKIM passed with flying colors.[1] The receiving server verified the signature against Apple’s keys, checked SPF records for Apple’s IPs, and concluded the email was pristine.

When Apple patched the carriage return trick, Longin went back to the RFCs and found a second way in using SMTP “dot-stuffing.” The SMTP protocol has specific rules about how periods at the start of a line are added by the sender and removed by the receiver to prevent a single dot on a line from terminating the message prematurely.

Because iCloud’s first parser didn’t honor these dot-stuffing rules but the second one did, Longin could craft a dot-colon sequence that caused a separation of the message header and body sections inside the second parser. This effectively allowed him to “peel” dots and push a fake From header into the right spot, reviving the bypass. Once again, iCloud signed the spoofed message and sent it out to the world as fully authenticated.[1]

It took Apple a year and a half of back-and-forth communication to fully roll out fixes that addressed the root parsing flaws rather than just patching the specific payloads. They ultimately paid out a $15,000 bounty for the findings, which is a welcome shift for a class of vulnerabilities that providers often dismiss.[1]

The takeaway for defenders here is that cryptographic signatures are only as trustworthy as the parsers sitting in front of them. SPF, DKIM, and DMARC tell you that an email passed through the expected infrastructure. They do not guarantee that the infrastructure didn’t get confused along the way. As long as email relies on interpreting text strings across decades-old protocols, sender identity will remain far less solid than we want to admit.

Sources

[1] https://sec-consult.com/blog/detail/from-anyoneicloudcom-spoofing-arbitrary-apple-icloud-identities/