DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

Apple iCloud Header Smuggling: Why Anyone Can Send Email as tim.cook@icloud.com and Pass DMARC

By DMARCGuardian Editorial Team ·

An email landed in a test inbox. The From line said Tim Cook . Apple Mail rendered it normally. The header line Authentication-Results said spf=pass, dkim=pass, dmarc=pass. The email was not from Tim Cook. It was from an attacker.

SEC Consult and researcher Timo Longin disclosed two Apple iCloud SMTP bugs on 2026-10-01 that make this possible. An attacker can send mail as any @icloud.com address, including tim.cook@icloud.com and no-reply@icloud.com, and every layer of the email authentication stack still reports pass. Apple paid a $15,000 bounty after the 2024-11-19 disclosure and patched both bugs before the public write-up.

The durable lesson is not that DMARC is broken. DMARC worked exactly as designed. The durable lesson is this: the message DKIM signs is not always the message the attacker originally wrote. That single gap is what makes header smuggling work, and it is the gap Apple had to fix twice in its own pipeline.

What did the spoofed email actually look like to the recipient?

The SEC Consult disclosure includes a screenshot of the test inbox. The From line reads Tim Cook . The mail client renders it normally. Authentication-Results shows spf=pass (the submission server was a real Apple SMTP endpoint), dkim=pass (signature from Apple), and dmarc=pass (alignment verified). A mail admin who only checks authentication headers has no signal that anything is wrong.

The only hint that the message was not authentic is a careful read of the raw headers and a comparison with what the attacker originally submitted. There is no automated flag the receiver can rely on.

Header smuggling is SMTP smuggling's smaller sibling

The same researcher, Timo Longin, is best known for the 2023 SMTP smuggling disclosure, which showed that differences in how outbound and inbound SMTP servers interpret the end-of-data sequence let an attacker smuggle a second, unauthenticated message inside a legitimate one. After the 2023 disclosure, Postfix, Sendmail, Exim, and other major SMTP implementations shipped patches. SMTP smuggling was not theoretical - it had been used to send as admin@outlook.com and pass SPF on vulnerable server pairs.

The 2026 iCloud disclosure applies the same parsing-discrepancy logic to a different layer. Instead of attacking the SMTP envelope (the part the MTA reads), it attacks the From header (the part the user sees). Longin calls the new technique header smuggling. The mechanism is the same: two components see two different versions of the same message, and the version the receiver checks is not the version the attacker wrote.

The technique is not isolated. The 2024 work by slonser_ showed that Gmail display-name parsing could be abused to send as admin@gmail.com against SMTP services like Outlook. CERT/CC VU#517845 (2025) formalized the broader category as ambiguous From header interpretation across major providers. Header smuggling on Apple iCloud is the next entry in that lineage, and it is the cleanest demonstration of how the class of attack works in a real disclosure.

How did Apple's two SMTP parsers disagree?

Apple's iCloud submission endpoint sits at smtp.mail.me.com on port 587. Based on observed behavior, the message goes through at least two parsers:

  • Parser 1 is a custom From-header check. It verifies the From header against the authenticated user and rejects mismatches with 5.7.0 From address is not one of your addresses.
  • Parser 2 is a downstream Postfix-style rewriter. It normalizes line endings, normalizes dot-stuffing, and adds the DKIM signature before the message is delivered to the receiver.

The two parsers disagree on what counts as a valid From header. Parser 1 reads the message one way; parser 2 rewrites it and reads it again. The rewritten message is the one that gets DKIM-signed and sent to the receiver.

When the two parsers disagree, an attacker can construct a message where parser 1 sees the legitimate From and accepts it, while parser 2 rewrites the line and sees a different From. That rewritten From is what the recipient's mail client displays.

Vulnerability one: bare in the From header

RFC 5321 section 2.3.8 and RFC 5322 section 2.3 say that bare and bare characters MUST NOT be transmitted independently of a matching line break. Some SMTP implementations enforce this strictly; others do not.

Apple's parser 1 treated bare as part of the From header line and ignored the malformed-looking result. Parser 2 stripped the bare and produced a clean, well-formed From header that matched any address the attacker wanted.

The attacker submitted a message with two From-style lines, one wrapped in bare characters around the colon and a clean one after. Parser 1 ignored the malformed line and validated the clean line against the authenticated user. Parser 2 stripped the from the first line, leaving a message with two valid-looking From headers.

To hide the redundant line from the recipient, the attacker wrapped the body in Content-Type: multipart/alternative and used the boundary strings to push the legitimate From header into the body, where the receiver's mail client ignored it as text. The visible From is the spoofed one.

Vulnerability two: dot-peeling

RFC 5321 section 4.5.2 defines dot-stuffing. Outbound SMTP adds an extra dot before any line that starts with a period. Inbound SMTP strips the extra dot before delivering the message. The two ends of the conversation must agree, or the message body gets garbled.

Longin found that parser 1 and parser 2 on iCloud disagreed about a From header that began with a leading dot. Parser 1 saw the dotted header and matched it against the authenticated address. Parser 2 stripped the dot and produced a different From header that the attacker controlled. DKIM signed parser 2's output. The receiver saw the dot-stripped From.

The class of attack is the same as the bare- variant: parser 1 says ok, parser 2 signs a different message, and DMARC verifies parser 2's version.

Why did SPF, DKIM, and DMARC all still pass?

Every layer of the authentication stack did exactly what it was designed to do. The gap was upstream.

SPF passes. The submission server was smtp.mail.me.com, which is a legitimate Apple sending host. SPF against the icloud.com domain authorizes that endpoint. From the receiver's perspective, the connection came from where icloud.com said it should come from.

DKIM passes. The DKIM signature was computed by parser 2 after it normalized the message. The receiver verified the signature against parser 2's output, byte for byte. The signature is valid. The signature just does not match what the attacker originally wrote.

DMARC passes. Alignment is checked against the DKIM signing domain and the SPF-authenticated identity. The DKIM signing domain matches the spoofed From in parser 2's view. The SPF identity matches the envelope sender. Both align. DMARC passes.

The version the attacker originally submitted was discarded before signing. The full authentication chain reported green because every check looked at parser 2's version of the message.

What Apple did about it

Apple acknowledged the report as qualifying for the Apple Security Bounty and paid $15,000 on 2024-11-19. The first patch closed the bare- vector by making parser 1 strict about malformed From headers. A second patch closed the dot-peeling vector.

The 2026-10-01 public disclosure confirms both vectors are closed. The technique no longer works against Apple iCloud. The class of attack, parser discrepancies between sender-side components, is not unique to Apple, but each provider's pipeline is different, and a similar bug in another provider would need its own disclosure.

What a defender can actually do

If you run a tenant or an inbox:

  • Authentication headers are necessary but not sufficient. Content heuristics (does the body match what tim.cook@icloud.com usually sends?), display-name vs From address mismatches, and BIMI / VMC as a confidence signal are all part of the picture. None of them alone would have stopped header smuggling.
  • Mail clients are starting to flag expected-from behavior. Apple's own updates are partly designed to spot senders that break their normal pattern. A user who suddenly receives a one-off email from an executive should still treat it as suspicious.

If you run a sender infrastructure:

  • Keep the submission check and the signing step on the same parser. Avoid putting a custom From-header check in front of a Postfix-style downstream rewriter, because that is exactly the split-parser topology the attack exploits.
  • Verify what your submission server actually submits versus what your downstream signer actually signs. A diff between the two views is the same class of signal Apple just investigated in its own pipeline.

If you operate a DMARC-focused program on your own domain:

  • DMARC does not defend against a provider with a parsing gap. It defends against senders you do not authorize. The lasting value of monitoring your own aggregate reports is that an unauthorized DKIM-signing domain appearing under your From is the same shape of signal Apple had to investigate internally.
  • A tool like DMARCFlow watches your aggregate reports and flags senders you do not recognize, which is the operational equivalent of the parser-discrepancy audit Apple ran on itself. Not a fix for header smuggling, but the kind of monitor that would catch a similar gap on your own infrastructure.

Order of practical actions:

1. Confirm you are running DMARC at p=quarantine or p=reject so an unauthorized DKIM-signing domain on your From is automatically rejected at receivers.
2. Subscribe to your aggregate reports and review them monthly for DKIM signing domains you do not recognize. DMARCFlow consolidates these reports and surfaces unknown senders automatically if you want a tool to handle the review.
3. For high-value senders (executive mail, transactional systems), set up a manual review of the DKIM signing domain in your inbound headers, so a spoofed executive address is caught even if DMARC passes.

FAQ

Is this still exploitable against Apple iCloud today?
No. Apple patched both the bare- and the dot-peeling vectors after the 2024-11-19 disclosure. The 2026-10-01 SEC Consult write-up confirms the patches are in place.

Could the same technique work against Outlook or Gmail?
The class of attack, parser discrepancy between sender-side components, is provider-agnostic. Whether any specific provider is exploitable today would require fresh research and a fresh disclosure. The 2024 slonser_ work demonstrated alias-name spoofing against Gmail display-name parsing, and CERT/CC VU#517845 catalogs the broader class across major providers.

Is DMARC broken?
No. DMARC verified the message parser 2 produced. The gap was that parser 2 produced a different message than the attacker originally wrote. DMARC works exactly as designed.

Could DMARCFlow or BIMI have detected this in my inbox?
No, not directly. BIMI requires DMARC at p=quarantine or p=reject and a verified VMC, but it is a confidence signal at the receiver, not a parser-discrepancy detector. DMARCFlow on your own domain would not have stopped an attacker spoofing an @icloud.com sender either. What it would have done is surface a similar gap on your own infrastructure - if your pipeline ever started signing a different From than the one your submission check validated, the DKIM signing domain in your aggregate reports would change and DMARCFlow would flag it.

What should I tell a non-technical colleague?
An Apple iCloud bug let attackers send mail that looked like it came from any @icloud.com address, including from Apple executives. The authentication headers all showed pass because of how Apple's mail pipeline processed the message before signing. Apple has since fixed it.

Could I have detected this without the disclosure?
Only by hand, by inspecting the original message source and comparing it to what parser 2 output before signing. There is no automated signal that an inbox alone can rely on. The durable answer is sender-side auditing and DMARC aggregate report monitoring on your own domain.

Where to read the original research