Free iCloud Account Could Let Attackers Spoof Any @icloud.com Address and Pass Email Security Checks

Security researcher Timo Longin, working with the SEC Consult Vulnerability Lab, disclosed two email spoofing flaws in Apple’s iCloud mail infrastructure that could have let someone with a free iCloud account send messages that appeared to come from any @icloud.com address.

The crafted messages could pass SPF, DKIM, and DMARC checks, the core controls used by mail services to verify sender identity. Apple has since remediated both issues following a lengthy responsible disclosure process.

The research shows that email authentication is only as reliable as the systems that prepare and process the email before it leaves a provider’s network.

In this case, the issue was not a stolen iCloud account or a weakness in the recipient’s inbox. It came from different parts of Apple’s outbound SMTP processing pipeline reading the same message data in different ways.

SMTP, or Simple Mail Transfer Protocol, remains the foundation of Internet email. It uses both an envelope sender, known as MAIL FROM or Return-Path, and a visible From: header that users see in their mail client.

Normally, iCloud checks that an authenticated account is only using one of its permitted sender addresses. If an account tried to directly set the visible sender to another iCloud identity, Apple’s service returned an error stating that the address was not associated with the user.

iCloud Email Address Spoofing

Longin found ways to make iCloud’s internal parsers interpret a message differently. One flaw involved unusual carriage-return characters in the From: header.

Apple’s first parser did not treat the manipulated field as a normal sender header during the user validation stage. A later parser cleaned up the message before delivery, turning it into a valid-looking sender header for the receiving mail server.

According to the technical report published by SEC Consult, the result was serious: a user authenticated as one iCloud address could make a delivered email appear to be from another address, including high-value identities such as tim.cook@icloud.com or no-reply@icloud.com.

SEC Consult demonstrated that the messages reached receiving systems with valid iCloud authentication results. The second issue used SMTP dot-stuffing rules, a long-standing part of the protocol that handles lines beginning with periods. The first iCloud parser and the next parser did not apply these rules in the same way.

This parsing gap again enabled a malicious From: header to survive iCloud’s checks and appear differently after the message was relayed.

The most concerning part was that the spoofed messages could pass SPF, DKIM, and DMARC. SPF confirmed that Apple’s legitimate mail infrastructure sent the email.

DKIM passed because iCloud applied its cryptographic signature after the affected message-processing stage. DMARC then passed because the visible sender domain was still icloud.com, aligned with Apple’s signed message.

This is important because users and mail gateways often treat these three “pass” results as strong proof that an email is safe.

As Cyber Security News has explained in its guide to detecting email spoofing with DMARC, DMARC alignment normally connects the visible sender domain with SPF or DKIM validation. This iCloud case showed how a trusted provider-side parsing flaw could undermine that protection.

SEC Consult first reported the carriage-return issue to Apple on May 21, 2024. Apple changed how it handled the original proof of concept, but the researchers later found a second bypass.

The final fixes were confirmed in December 2025, and the technical report was published on October 1, 2026. Apple awarded Longin a $15,000 Apple Security Bounty for the findings.

The case follows earlier SMTP smuggling research, where inconsistent protocol handling enabled spoofed mail across services. It also reflects a broader problem tracked by CERT/CC: ambiguous From: header parsing can let authenticated SMTP users impersonate other identities and bypass expected sender checks.

For defenders, the main lesson is clear. SPF, DKIM, and DMARC remain essential, but they are not a reason to trust every email without question.

Security teams should review full message headers, watch for differences between the visible From: address and Return-Path, and treat unexpected requests for credentials, payments, or urgent action with caution.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup into your SOC