iCloud Email Spoofing Flaw Passed SPF, DKIM and DMARC

Picture a message in your Gmail inbox from security@icloud.com. Gmail says it was mailed by icloud.com and signed by icloud.com. The raw headers read spf=pass, dkim=pass and dmarc=pass. For about 19 months, Apple's own servers could make all of that true for a forged sender.

On October 1, 2026, SEC Consult published a technical writeup by Timo Longin, the researcher behind SMTP smuggling, describing two ways to make iCloud send mail under an @icloud.com address the sender did not own. The only prerequisite was an ordinary iCloud account. Both holes are closed, but they show what "authenticated" email really proves.

Key Takeaways

• SEC Consult disclosed on October 1, 2026 two iCloud email spoofing flaws that let an authenticated iCloud user send mail showing a different @icloud.com address as the sender.
• Gmail's own servers recorded spf=pass, dkim=pass and dmarc=pass on the test messages, because Apple signed each email after an internal parser had rewritten its headers.
• The first technique hid a forged From header behind bare carriage return characters, and the second abused iCloud's inconsistent handling of SMTP dot stuffing after Apple's first fix.
• Apple awarded a $15,000 bounty on November 19, 2024, yet SEC Consult only confirmed the deployed fixes on December 9, 2025, roughly 19 months after its May 21, 2024 report.
• DMARC checks the domain in the From address, not the mailbox, so a pass on a shared domain like icloud.com proves the server, not the person.

What Did SEC Consult Find in iCloud Mail?

SEC Consult found that two parsers inside iCloud's outbound mail system read the same message differently, letting a sender pass Apple's identity check with one From header and deliver another. It calls this "header smuggling," a cousin of SMTP smuggling that never escapes the message data.

Clients submit iCloud mail to smtp.mail.me.com on port 587 with an app specific password, per Apple's server settings page. Apple then checks that the From header belongs to the logged in user; a naive spoof gets 5.7.0 From address is not one of your addresses. That check is "not mandated by SMTP itself," SEC Consult notes. Each provider builds its own.

Longin inferred two stages. "Parser 1" runs the ownership check. "Parser 2," "likely" based on Postfix, normalizes the message before DKIM signing and delivery. When two parsers disagree about where a header ends, the security check loses.

How Did the Carriage Return Trick Work?

The first technique wrapped the colon of a forged From header in bare carriage returns, which Parser 1 skipped over and Parser 2 stripped out. RFC 5321 section 2.3.8 says lines end with CR LF and "Conforming implementations MUST NOT recognize or generate any other character or character sequence" as a terminator. iCloud's stages disagreed.

A simplified sketch based on SEC Consult's description:

From<CR>:<CR>admin@icloud.com   # Parser 1: not a From header, skipped
From: user@icloud.com              # Parser 1: matches the logged in user, accepted

# Parser 2 strips the <CR> characters from the first line,
# so the message now carries two valid From headers

Most receivers reject two From headers. So Longin added more bare CRs, which Parser 2 rewrites as CR LF elsewhere in the message, to push the legitimate From: user@icloud.com line into the body. A smuggled Content-Type: multipart/alternative header and a closing boundary hid the leftovers. The demos arrived from admin@icloud.com and tim.cook@icloud.com.

How Did Dot Peeling Bypass Apple's First Fix?

Dot peeling exploited SMTP dot stuffing rules that Parser 2 followed and Parser 1 ignored. After Apple made Parser 1 treat From\r:\r as a real From header, Longin turned to RFC 5321 section 4.5.2. Senders double any leading period, and receivers follow this rule: "If the first character is a period and there are other characters on the line, the first character is deleted."

Parser 2 removed that dot. Parser 1 never did. A dot and colon sequence (.:) made Parser 2 split headers from body at a point Parser 1 never saw. Same outcome: the authentic From line ended up in the body, and the forged one went out signed.

Why Did SPF, DKIM and DMARC All Pass?

All three passed because the forged message really did leave Apple's servers with Apple's signature and an icloud.com address. None of them checks which person sent it.

• SPF passed because the sending IP, 17.57.155.19 in SEC Consult's headers, is authorized for icloud.com.
• DKIM passed because, as SEC Consult puts it, "DKIM signatures are created after parser 2 processed the message." If Apple had signed at Parser 1, verification "would most likely fail."
• DMARC passed because RFC 7489 defines alignment as "When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM." The domain matched. The mailbox is never compared.

That point matters more than the parser bugs. RFC 7489 says alignment "cannot occur" with a "repeated RFC5322.From field." Longin's tricks delivered exactly one clean From header, putting the message back inside DMARC's scope, with a pass.

One trace survived: the envelope sender, shown here in Gmail's verdict on a test message.

Return-Path: <attacker@icloud.com>
Authentication-Results: mx.google.com; dkim=pass header.i=@icloud.com ...
  spf=pass ... smtp.mailfrom=attacker@icloud.com;
  dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=icloud.com

Legitimate iCloud mail rarely shows a Return-Path that differs from the From address, so SEC Consult says heuristics could flag it. "However, as it is, this is a legitimate and authenticated email."

The 19 Month Disclosure Timeline

The published timeline runs 567 days from report to confirmed fix. The bounty landed 385 days before the job was done.

• May 21, 2024: SEC Consult reports the From header injection to Apple with proof of concept files.
• November 1 and 4, 2024: SEC Consult confirms the original proof of concept no longer works; Apple marks the report remediated.
• November 19, 2024: Apple awards a $15,000 Apple Security Bounty.
• December 6 to 12, 2024: SEC Consult finds a second parsing issue, reports that the fix merely blocklisted the substring "admin" in the From header, and spoofs security@icloud.com.
• May 24 to June 13, 2025: Apple ships an update; SEC Consult confirms a bypass still works.
• December 9, 2025: SEC Consult confirms the deployed fixes remediate the issue.

A blocklist on "admin" stopped the demo and little else, and risked breaking mail for real users with "admin" in their address. The writeup lists no CVE ID and mentions no abuse in the wild.

What This Means for Your Gmail Inbox

For Gmail users, the authentication badge was the problem, not the solution. Google's help page on authenticated messages says Gmail shows a "Mailed by" domain and a "Signed by" sending domain. On a spoofed iCloud email both would read icloud.com, the one thing that was genuine.

The gap applies wherever millions of strangers share one domain. A DMARC pass on gmail.com, outlook.com or icloud.com says a provider's server sent it. Whether the right customer did depends on each provider's private sender check, the layer that broke here. CERT/CC's VU#517845, published October 28, 2025, describes the same failure through a different trick: ambiguous From syntax lets "Authenticated SMTP users" spoof other identities.

It is not the first trusted sender to pass all three checks this year. In May, attackers made Google itself send crypto phishing through its account recovery notification system. There the sender was real and the content hostile; here the sender was fake. A 2021 USENIX Security paper, Weak Links in Authentication Chains, tested "30 popular email services and 23 email clients" and found "all of them are vulnerable to certain types of new attacks."

How Does This Compare to SMTP Smuggling?

SMTP smuggling broke out of a message to inject a second email; the iCloud bugs swapped the From header inside one message. Longin's December 18, 2023 SMTP smuggling research exploited disagreements over the end of data sequence between an outbound server and an inbound one. It led to fixes across the ecosystem, including CVE-2023-51764 for Postfix.

This time, Longin says weeks of classic smuggling attempts produced "NOTHING" that worked. The new bugs sat between two of Apple's own components, which is harder for outsiders to test and for the provider to notice, because both halves trust each other.

Is the iCloud Spoofing Flaw Fixed, and What Should You Do?

Yes, SEC Consult confirmed on December 9, 2025 that Apple's fixes work, and iCloud users have nothing to install. The next parser gap will look identical in your inbox, so these habits still matter.

For everyone who reads email

1. Treat a DMARC pass as proof of the domain only. On freemail domains it says nothing about which account sent it.
2. Open the full headers when a request is unexpected. In Gmail, click More, then Show original. A smtp.mailfrom or Return-Path mailbox that differs from the From address is a red flag.
3. Verify money, credential and access requests out of band. Use a channel you already trust, never a reply.
4. Be extra suspicious of role and celebrity addresses on freemail domains. security@icloud.com and tim.cook@icloud.com were SEC Consult's demo senders.

For mail administrators and developers

1. Run the sender check on the final message. SEC Consult told Apple a Milter based filter such as milterfrom, checking the From header against the final message before sending, was the likely root cause fix. Validate what you sign.
2. Reject bare CR and LF on submission. Postfix offers smtpd_forbid_bare_newline=yes from versions 3.5.23, 3.6.13, 3.7.9 and 3.8.4, per the Postfix SMTP smuggling notes and NVD.
3. Refuse messages with more than one From header, and flag envelope versus header mismatches on shared domains. Then fix your own DMARC policy, since weak settings caused the internal domain spoofing Microsoft warned about.
4. Test every hop. Longin's SMTP Smuggling Tools cover end of data tricks between servers. Internal header smuggling needs custom fuzzing of CR, LF and leading dots.

SEC Consult's own conclusion is blunt: "parsing issues in old and complex protocols like SMTP will always remain." Build your trust in an email on who you can reach, not on which checks turned green.