iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Yes—SEC Consult demonstrated that an authenticated iCloud Mail sender could make messages appear to come from arbitrary @icloud.com addresses and pass SPF, DKIM, and DMARC checks. The issue involved flaws in Apple’s outbound mail processing, not proof that attackers accessed the Apple Accounts named in the forged From fields. SEC Consult says Apple’s deployed fixes remediated the flaws, which the researcher confirmed on December 9, 2025; its technical report was published October 1, 2026.
What the iCloud email spoofing flaw did
SEC Consult’s technical disclosure describes two related parsing flaws in iCloud Mail’s outbound infrastructure. In demonstrations, an authenticated iCloud sender could craft a message that displayed an arbitrary @icloud.com address in the From field. The message was sent through Apple’s legitimate mail infrastructure and could pass SPF, DKIM, and DMARC checks.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
Cryptnox FIDO2 Security Key NFC Smart Card for 2FA MFA Passwordless Login | $30.99 | Buy on Amazon |
That is sender spoofing: the displayed identity was not necessarily the person who sent the message. It is not evidence that the sender logged in to, accessed, or controlled the Apple Account associated with the forged address.
How could a spoofed message pass SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC are domain-authentication mechanisms, not a guarantee that the person shown in an email’s From field personally sent it. Apple’s Postmaster information for iCloud Mail says iCloud Mail authenticates inbound email with SPF and DKIM, signs outbound email with DKIM, and publishes DMARC with a p=quarantine policy for its mail domains. Apple says that policy took effect July 2, 2018.
#1 Best Overall
- FIDO2 CERTIFIED: FIDO Alliance Certified FIDO2 v2.1 and CTAP Level 1 for 2FA and MFA on Google Microsoft Apple GitHub login.gov AGOV SwissID and any WebAuthn service
- PASSKEY READY: Works as a hardware passkey for passwordless sign-in where the service enables it and as a U2F and WebAuthn security key everywhere else
- CERTIFIED SECURITY: NXP JCOP 4.5 secure element rated Common Criteria EAL6+ (augmented)
- TAP OR INSERT: Dual NFC ISO 14443 and contact ISO 7816 interface in an ID-1 format smart card that is passive and battery-free
- BUILT TO LAST: Passive smart card made in Switzerland designed by Swiss company Cryptnox and backed by a 2 year manufacturer warranty
In the disclosed case, the weakness was in how Apple’s outbound mail pipeline interpreted message content. Different processing stages handled crafted input inconsistently, allowing the trusted service to accept and sign a sender identity the user did not control. Authentication checks could therefore pass because the message was processed and signed by Apple’s legitimate infrastructure. The protocols were not absent; their results did not correct the sender-identity error introduced inside that infrastructure.
What were the two parsing flaws?
CRLF and header injection
The first demonstration used a CRLF sequence—carriage return and line feed—to affect how a From header was interpreted. SEC Consult says Apple made changes after the initial report, and the original proof of concept later stopped working. According to the disclosure timeline, however, that first mitigation did not resolve the underlying parsing discrepancy.
Dot-stuffing and dot-peeling discrepancy
SEC Consult then reported a second approach involving dot-stuffing behavior and inconsistent interpretation of where message headers ended and the body began. The technical lesson is that when stages of a mail system parse the same input differently, validation at one stage may not protect later stages. The report describes the flaw at a technical level; reproducing it is unnecessary for understanding the risk.
Is the iCloud spoofing vulnerability fixed?
SEC Consult says Apple pushed updates and that the researcher confirmed deployed fixes remediated the original issue on December 9, 2025. This is the researcher’s reported verification. The public report appeared October 1, 2026; the evidence cited here does not include a separate Apple security advisory for these specific flaws.
The dates show why a public disclosure date should not be mistaken for the date the flaw was fixed: the researcher reported the first issue to Apple on May 21, 2024, and says remediation was verified in December 2025, before the technical account was made public.
Disclosure timeline
| Date | What SEC Consult reports |
|---|---|
| May 21, 2024 | SEC Consult submitted its first report to Apple, describing CRLF injection in the From header and spoofed messages with valid DKIM and DMARC. |
| October 17, 2024 | Apple said changes had been made; SEC Consult later confirmed that the original proof of concept no longer worked. |
| November 19, 2024 | SEC Consult’s timeline records a $15,000 Apple Security Bounty for the initial report. |
| December 6–12, 2024 | SEC Consult found and reported a second related parsing issue, saying the first deployed fix was insufficient. |
| May–June 2025 | After Apple asked for a reassessment, SEC Consult reported that a bypass remained. |
| November 11–12, 2025 | SEC Consult reported that its previous proof of concept no longer worked, and Apple said updates had been pushed. |
| December 9, 2025 | SEC Consult confirmed that deployed fixes remediated the original issue. |
| October 1, 2026 | SEC Consult published its technical report. |
The $15,000 figure is the bounty SEC Consult says Apple awarded for the initial report; it says nothing about how many people were targeted or affected. The disclosure does not establish a victim count or prevalence rate.
What this means if you receive an email from @icloud.com
An @icloud.com address in the From field does not, by itself, prove that the person associated with that address sent the message. This distinction remains useful beyond this particular, reportedly patched flaw: email authentication can provide evidence about a sending domain and the route or signing of a message, but it cannot always establish the human identity behind it.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute- Do not treat a familiar sender name or address as proof of identity when a message asks for money, passwords, verification codes, or an urgent account change.
- For sensitive requests, verify through a separate channel you already trust rather than replying to the message or using contact details it provides.
- Consider the message’s context and links as well as its authentication indicators; passing SPF, DKIM, and DMARC is not a guarantee that the visible sender is the person you expect.
Apple’s support page explains that @icloud.com, @me.com, and @mac.com addresses depend on account history: accounts created on or after September 19, 2012 receive an @icloud.com address, while some earlier MobileMe and iCloud users may retain other suffixes. Apple also says an email alias cannot be used to sign in to iCloud.com. Those address rules do not establish who sent a particular message. See Apple’s explanation of iCloud email addresses and aliases.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How this differs from Hide My Email
The issue described by SEC Consult concerns parsing in outbound iCloud Mail. It is not the same as Sign in with Apple’s Hide My Email feature. Apple’s Sign in with Apple white paper describes Hide My Email as a unique relay address that forwards mail to a verified inbox; it also says sending domains must be registered and that standard DKIM, DMARC, and SPF policies are used for the relay service.
What administrators can take from the disclosure
The incident is a reminder that domain-authentication policies depend on the sending system validating and handling message identities correctly before sending. For teams operating email infrastructure, the relevant safeguards act at different points:
- Before submission: authorize which users and systems may submit messages for particular sender identities.
- Across processing stages: validate and parse headers consistently at each stage, rather than relying on a single check before later transformations.
- At receipt: use SPF, DKIM, and DMARC results as authentication evidence, not as proof of a person’s identity.
- For users: provide clear handling for suspicious messages and a separate way to verify sensitive requests.
Apple’s iCloud mail-authentication policy and SEC Consult’s account of the parsing flaw support these general lessons; they do not establish that a particular buyer-side product would block this historical issue. Apple’s iCloud terms also prohibit impersonating another person or user and forging headers to mislead recipients about a message’s origin, describing that conduct as spoofing: Apple iCloud Terms.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
