What do Apple X-Headers mean in email filtering?
Updated on 24 Oct 2026: We clarified Apple's private filtering headers, separated iCloud placement from privacy opens, and corrected the authentication checks used in troubleshooting.
Apple X-Headers are private mail-processing headers that describe how Apple's iCloud Mail filtering path handled a message. X-Apple-MoveToFolder records the folder named during processing, while X-Apple-Action records a paired processing label. In an original message retrieved from an iCloud mailbox, X-Apple-MoveToFolder: Junk paired with X-Apple-Action: CLXJUNK/Junk is evidence that Apple routed that copy to Junk during processing.
Read these headers as placement evidence, not as a public scoring API or a complete cause code. Apple has not published a sender-facing dictionary for these particular fields, and action prefixes vary between samples. Compare them with the full header set, authentication results, recipient behavior, and repeated test sends.
Observed Apple placement headers
X-Apple-MoveToFolder: Junk X-Apple-Action: CLXJUNK/Junk X-ICL-SCORE: 4.333034030041 x-spam-flag: yes x-suspected-spam: true X-Apple-MoveToFolder: INBOX X-Apple-Action: MOVE_TO_FOLDER/INBOX X-ICL-SCORE: 3.333033230041
Short answer
- X-Apple-MoveToFolder records the destination named during Apple processing, commonly Junk or INBOX.
- X-Apple-Action records a processing label paired with that destination, but its prefix can vary.
- X-ICL-SCORE gives comparison context, but it is not a published Apple threshold.
- A single header sample documents that message copy's handling, not every recipient's result.
How to read Apple X-Headers
X-Apple-MoveToFolder and X-Apple-Action are the main placement fields to inspect. Unlike standard fields such as From, Date, To, Subject, Message-ID, and Received, these fields are provider-added metadata. They answer the practical question, "Where did Apple put the message during filtering?" Senders often receive a forwarded copy or seed-mailbox sample and need to determine whether the message was accepted, routed to Inbox or Junk, or moved later by a rule or recipient action.
Use the headers together. X-Apple-MoveToFolder gives the folder name. X-Apple-Action adds a processing label, but observed values such as CLXJUNK/Junk, DMARCINFO/Junk, and BL/Junk have no published cause-code definitions. X-ICL-SCORE gives numeric context without a documented sender-facing scale. Other filters use X-Spam-Status to publish score= and required= values, but those values do not define an Apple score threshold. Fields such as x-spam-flag and x-suspected-spam strengthen the junk interpretation when they agree with the folder and action values.
|
|
|
|---|---|---|
X-Apple-MoveToFolder | Junk | Apple recorded Junk as the processing destination |
X-Apple-MoveToFolder | INBOX | Apple recorded Inbox as the processing destination |
X-Apple-Action | CLXJUNK/Junk | A Junk action label in that sample |
X-Apple-Action | DMARCINFO/Junk or BL/Junk | Other observed Junk labels, not published cause codes |
X-ICL-SCORE | Number | Comparison context without a public threshold |
Compact interpretation of observed Apple filtering fields.
To inspect a message in iCloud Mail, Apple's help page explains how to view all headers. On iCloud.com, select the message, choose More, then Show All Headers. Compare Received, Return-Path, Reply-To, Content-Type, and Authentication-Results with the Apple placement fields. This keeps routing evidence separate from authentication and filtering evidence.
Infographic showing Apple X-Headers for folder, action, score, and spam flags.
The prefix in an X-Apple-Action value is less useful than the destination after the slash. Treat CLXJUNK, DMARCINFO, BL, and similar prefixes as private processing labels unless the rest of the headers independently supports a cause. They are not DNS settings or remediation instructions. The actionable result is the recorded destination, followed by a review of authentication, reputation, content, engagement, recipient rules, and the complete routing path.
How iCloud filtering differs from Apple Mail
iCloud Mail filters messages on Apple's receiving servers. Apple Mail is an email app that can display accounts from other providers. Opening a message in Apple Mail does not establish that iCloud handled delivery. Check the trusted Received chain to identify the receiving service. The absence of undocumented Apple fields does not prove that filtering was skipped.
Mail Privacy Protection (MPP) is a separate privacy setting. Apple says it downloads remote content in the background and hides the recipient's IP address. A tracking-pixel request therefore does not prove a human open or Inbox placement. Keep open-rate data separate from the folder evidence in an original message.
On Mac, local junk filtering and the "Trust junk mail headers in messages" option can use server-provided spam flags. Disabling that local filter does not disable filtering on the receiving server. Check Apple's junk mail settings when the app and the original server placement disagree.
How to interpret Junk versus INBOX
When the folder header says Junk, treat it as Apple's recorded junk placement for that message copy during processing. When it says INBOX, treat it as the recorded inbox placement. The phrase "message copy" matters. Mailbox history, user training, client settings, and routing paths affect the result. One result documents that exact sample, while repeated samples show whether it is a pattern.
The following comparison is a practical triage method for the two common outcomes before changing DNS, sender infrastructure, or content.
Junk path
- X-Apple-MoveToFolder: Junk is the strongest placement clue.
- An action ending in /Junk supports the same recorded destination.
- x-spam-flag and x-suspected-spam support that reading when they come from the trusted receiving system.
- Compare authentication and source evidence with campaign and recipient history.
Inbox path
- X-Apple-MoveToFolder: INBOX records an Inbox placement.
- MOVE_TO_FOLDER/INBOX records a matching folder action.
- Compare a score only with repeated samples from a controlled test.
- Keep a baseline so future Junk samples have a clean comparison.
Do not use X-ICL-SCORE as a standalone pass or fail value. In the samples above, a Junk message had a score around 4.33 and an Inbox message had a score around 3.33. Two samples do not establish directionality or prove that 4.0, 4.3, or another number is a boundary. The folder and action headers carry more practical weight.
Evidence weight for Apple header review
This editorial triage aid applies to trusted original iCloud samples. It is not Apple's scoring scale.
Strong evidence
Act
Folder, action, and spam flags all match.
Useful context
Compare
Score changes with matching samples.
Weak evidence
Retest
One sample without full headers.
Good evidence
Baseline
Repeated Inbox samples with clean authentication.
Why the visible folder can disagree
An Apple placement header can remain in the raw message after the visible mailbox state changes. A recipient can move a message, mark it as junk or not junk, or run an iCloud rule. The Apple Mail app can also apply local junk filtering. These later actions do not need to rewrite the original X-Apple-MoveToFolder or X-Apple-Action values.
|
|
|
|---|---|---|
Header says Junk, message is in Inbox | The recipient moved it or marked it as not junk | Recipient action history and rule settings |
Header says INBOX, message is in Junk | A user action, rule, or local filter moved it later | Current rules and Apple Mail junk settings |
Apple fields appear in another provider's mailbox | The message was forwarded, copied, or uploaded | The new mailbox's Received chain and arrival time |
Folder and header agree | The recorded placement probably remains unchanged | Full headers and any recipient actions |
Common reasons the current folder and preserved headers differ.
Apple says messages from people in iCloud contacts or recent conversations do not go to Junk, and marking a legitimate message as not junk changes future handling for that sender. Record contact status and prior correspondence when testing. Capture raw headers before manual movement, and collect a Junk sample before iCloud removes it after 30 days. These behaviors are described in Apple's spam guidance.
What not to infer from these headers
Apple X-Headers look precise, but private metadata is not a public deliverability diagnosis. The fields document a processing result. They do not reveal every signal Apple considered or provide a complete fix list. Retrieve the original message directly from the iCloud mailbox and check the receiving server's own Received entries. An X-Apple field name alone does not prove that Apple added it.
- Junk placement indicates Apple accepted that original message copy. A rejection is a separate SMTP outcome.
- CLX, DMARCINFO, and BL are private labels, not confirmed root causes. BL/Junk does not confirm a public blocklist (blacklist) listing.
- One seed address does not establish placement for all icloud.com, me.com, or mac.com recipients.
- The current folder does not always show initial server placement. Rules and user actions can move mail later.
- X-Originating-IP describes an earlier submission source when supplied by a trusted system. Apple placement fields describe processing further along the delivery path.
For sender-side X-Headers such as X-Originating-IP, trust the actual SMTP connecting IP and the Received chain more than the custom field. An exposed origin IP matters if it reveals sensitive infrastructure or has a blocklist (blacklist) problem, but it remains secondary to authentication, sending reputation, and the server that delivered the message.
Apple Mail's local junk filter can use server-provided junk headers and learned criteria. The Apple Mail settings explain how those settings affect the visible folder.
Use full headers, not screenshots
A screenshot of a Junk folder is not enough for a technical investigation. Ask for the full raw headers, approximate received time, and any action the recipient took. The header chain shows authentication and routing, while Apple placement fields preserve the processing state recorded in that copy.
The same caution applies to forwarded samples. Forwarding can add a delivery hop, change the envelope, or place the original message inside a new message. Read Apple fields in an attached original as evidence about that original copy. Use the final receiver's trusted Authentication-Results for the final delivery.
How to test Apple placement
Use controlled samples to test Apple placement. Send the same message to several iCloud Mail test accounts, save the raw message source, and compare the folder and action values before anyone moves the mail. Then send a known-good baseline from the same domain and source. Compare campaign-specific results separately from source and domain reputation patterns.
Start with the exact message, then change one variable at a time. Changing subject, body, links, authentication, and sending IP together creates noise. If the next send lands in Inbox, you will not know which change mattered.
- Save the full original headers, Message-ID, received time with time zone, and current folder for the iCloud sample.
- Send to more than one iCloud Mail test account and compare folder and action values.
- Send a known-good message from the same authenticated source.
- Record contacts, prior conversations, rules, and manual mailbox actions.
- Adjust one variable per round so the result has a clear meaning.
- Review Apple placement beside SPF, DKIM, DMARC, the Received chain, and source reputation.
A real send gives better evidence than a copied header fragment. Suped's email tester inspects authentication and message structure for a message sent to Suped's test address. Run it alongside the iCloud test. That separate delivery does not reveal Apple's private placement headers or confirm iCloud Inbox placement.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After the test, compare Apple placement headers with the receiver's trusted Authentication-Results. DMARC passes when SPF or at least one DKIM signature passes and its authenticated domain matches the visible From domain under the domain's DMARC matching mode. A matching domain with a failed check is insufficient. A DMARC pass does not guarantee Inbox delivery, as RFC 9989 explains. If authentication passes and one campaign variant alone goes to Junk, investigate its content and linked domains next.
In Suped's product, use the delivered-message report to investigate DKIM signature or key lookup problems, SPF lookup failures, or missing DMARC coverage. Compare that finding with reported sending sources in domain-wide DMARC data before changing a campaign or policy.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Where DMARC and reputation fit
Apple X-Headers are not DMARC results, but authentication belongs near the start of an Apple Junk investigation. Apple's postmaster guidance requires SPF and DKIM, a published DMARC policy, and explicit subscriptions with an immediate unsubscribe option. It also calls for reverse DNS, consistent sending infrastructure, and ARC headers on forwarded mail. Track SMTP errors and remove bouncing or inactive addresses. Apple uses IP and domain reputation alongside content checks and user feedback. It offers neither an allow list for bulk senders nor a complaint feedback loop.
Use Suped's DMARC monitoring to review reported sending sources, check whether authenticated domains match the From domain, and identify sources needing fixes. A domain health checker helps review authentication DNS before deeper testing. DMARC aggregate reports summarize authentication and policy disposition. They do not report Apple placement headers or the final mailbox folder. Even disposition=none does not prove Inbox delivery; the standard report fields are defined in RFC 9990.
Reputation belongs in the same review. If Apple samples go to Junk and the source has listing or complaint problems elsewhere, use blocklist monitoring as part of the sender review. A public blocklist (blacklist) listing does not prove Apple uses that list, and a clean result does not establish a good private reputation.
Where Suped fits
Suped's product connects DMARC monitoring, SPF and DKIM checks, blocklist monitoring, and deliverability issue detection in one workflow. When an Apple sample records Junk, use that domain-wide evidence to find the affected source and verify whether authentication or reputation changed.
- Filter aggregate reports by sending source and time period to check for authentication changes around the affected Apple delivery.
- Resolve confirmed SPF or DKIM failures, then repeat delivery to the same iCloud test accounts to check placement.
Views from the trenches
Best practices
Sample sets: Compare Apple headers across several real sends before changing content or DNS.
Header pairs: Read folder and action headers together because one value alone is thin evidence.
Authentication: Check SPF, DKIM, and DMARC before treating Apple placement as content only.
Retention: Save full headers for every test because Apple values are not public specifications.
Common pitfalls
Single tests: One Junk sample does not prove a campaign-wide Apple filtering problem for all users.
Score fixation: A numeric score without folder action does not define a published threshold.
User rules: Local Mail rules and mailbox training can change placement for that mailbox.
Vendor guessing: CLX labels alone do not prove which internal filter made the decision.
Expert tips
Seed discipline: Use fresh addresses and consistent timing when testing Apple placement.
Header capture: Ask recipients for full headers, not screenshots of the message list or folder.
Trend review: Track repeated Junk actions by sending source, domain, and campaign type.
Fix order: Resolve authentication and reputation issues before rewriting every template.
Marketer view
Marketer from Email Geeks says the Apple folder header is best read as the filtering decision for that message, similar to other provider-added placement headers.
2023-06-12 - Email Geeks
Marketer view
Marketer from Email Geeks says INBOX values have appeared as MOVE_TO_FOLDER/INBOX, while Junk samples have appeared as CLXJUNK/Junk.
2023-06-12 - Email Geeks
