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 allowed someone with a free iCloud account to send messages that appeared to originate from arbitrary @icloud.com addresses.

The crafted messages could pass SPF, DKIM, and DMARC checks, the core mechanisms used by mail services to verify sender identity.

Apple has since remediated both vulnerabilities following a lengthy responsible disclosure process.

The research demonstrates that email authentication is only as reliable as the systems that prepare and process messages before they leave a provider's infrastructure.

In this case, the issue was not a compromised iCloud account or a vulnerability in the recipient's mailbox. Instead, different components of Apple's outbound SMTP processing pipeline interpreted the same message data differently.

How iCloud Email Spoofing Worked

SMTP (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 displayed to users in their email clients.

Alt text

Normally, iCloud verifies that an authenticated account is only using permitted sender addresses.

If a user attempted to directly set the visible sender to another iCloud identity, Apple's service would reject the message with an error indicating that the address was not associated with the authenticated account.

Longin discovered ways to make different iCloud components parse the message differently.

Carriage-Return Parsing Issue

One vulnerability involved unusual carriage-return characters in the From: header.

Apple's initial parser did not interpret the manipulated field as a conventional sender header during the sender-validation stage.

A later parser subsequently normalized the message before delivery, transforming the manipulated data into a valid-looking sender header for the receiving mail server.

According to the technical report published by SEC Consult, this allowed a user authenticated as one iCloud address to make a delivered message appear to originate from another iCloud identity.

The researchers demonstrated spoofing addresses including high-value identities such as:

The spoofed messages were delivered with valid iCloud authentication results.

SMTP Dot-Stuffing Issue

The second vulnerability involved SMTP dot-stuffing, a longstanding protocol mechanism used to handle lines beginning with periods.

The first iCloud parser and a subsequent parser did not apply dot-stuffing rules consistently.

This parsing discrepancy once again allowed a manipulated From: header to pass Apple's sender validation and appear differently after the message was relayed.

SPF, DKIM and DMARC Still Passed

The most concerning aspect of the vulnerabilities was that spoofed messages could successfully pass SPF, DKIM, and DMARC.

SPF (Sender Policy Framework) passed because Apple's legitimate mail infrastructure was responsible for sending the message.

DKIM (DomainKeys Identified Mail) passed because iCloud applied its cryptographic signature after the affected message-processing stage.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) then passed because the visible sender domain remained icloud.com, matching the domain validated through Apple's email authentication mechanisms.

This is significant because many users and mail security gateways treat successful SPF, DKIM, and DMARC results as strong evidence that a message originated from a legitimate sender.

However, the iCloud case demonstrates that these mechanisms cannot protect against every provider-side message-processing flaw.

Responsible Disclosure and Apple Security Bounty

SEC Consult first reported the carriage-return parsing vulnerability to Apple on May 21, 2024.

Apple changed how it handled the original proof of concept, but researchers subsequently discovered another bypass using SMTP parsing behavior.

The final fixes were confirmed in December 2025.

SEC Consult published the technical report on October 1, 2026, and Apple awarded Longin a $15,000 Apple Security Bounty for the findings.

The research follows earlier work involving SMTP smuggling, where inconsistent interpretation of SMTP data between different mail-processing components has enabled attackers to manipulate how messages are processed.

It also reflects a broader security concern around ambiguous From: header parsing.

Security Implications

The vulnerabilities highlight an important limitation of email authentication.

SPF, DKIM, and DMARC can provide strong protection against many forms of domain impersonation, but they ultimately depend on the email provider correctly parsing and processing messages before authentication is applied.

An attacker who can manipulate the message-processing pipeline may potentially cause different components to interpret the same email differently.

This means that a message displaying a legitimate domain and showing successful authentication results should not automatically be considered trustworthy.

Recommendations for Defenders

Security teams should continue using SPF, DKIM, and DMARC, while also implementing additional email-security controls.

Defenders should:

  • Review complete email headers when investigating suspicious messages.
  • Compare the visible From: address with the Return-Path and other header fields.
  • Monitor for unusual sender behavior and impersonation attempts.
  • Use additional phishing and business-email-compromise detection controls.
  • Treat unexpected requests for credentials, payments, or urgent actions with caution.
  • Educate users that SPF, DKIM, and DMARC pass results do not guarantee that the message itself is safe.
  • Investigate suspicious messages even when standard email authentication checks pass.

Key Takeaway

The iCloud vulnerabilities demonstrate how parser inconsistencies inside trusted email infrastructure can undermine otherwise effective email authentication mechanisms.

Even when SPF, DKIM, and DMARC all report successful validation, defenders should consider the broader context of the message, including its headers, content, sender behavior, and requested action.

For organizations relying heavily on email for authentication, payments, password resets, or sensitive business communications, layered email security remains essential.