iCloud 554 5.7.1 [CS01] / [HM08]: Message Rejected Due to Local Policy

A 554 5.7.1 bounce with [CS01] or [HM08] is iCloud refusing your message under Apple's own filtering policy. It isn't a public blocklist listing and there's nothing to look up. Apple doesn't publish what triggers each code, so you fix it by working through the things Apple says it filters on: authentication, sender reputation, list quality and content. If that doesn't clear it, you email Apple's postmaster team.

The rejection is permanent for that message. It won't be retried.

What the bounce says

The bounces look like this, as posted publicly by senders who received them:

554 5.7.1 [CS01] Message rejected due to local policy.
Please visit https://support.apple.com/en-us/HT204137

554 5.7.1 [HM08] Message rejected due to local policy.
Please visit https://support.apple.com/en-us/HT204137

The link goes to Apple's postmaster information for iCloud Mail, which doesn't mention either code. Some senders report the same text with a 550 code instead of 554. Treat it the same way.

What it means

The 5.7.1 part is the standard enhanced status code for "delivery not authorized, message refused." The phrase "local policy" means Apple's own rules made the decision, not a third-party list.

The bracketed code is Apple's internal label for which rule fired. Apple doesn't document them, and anyone who tells you exactly what CS01 or HM08 means is inferring it. What Apple does say is that it judges senders on "IP and domain reputations, content checks, and user feedback," and that bulk mail that doesn't meet all of its requirements will be rejected. That gives you the checklist.

For the bigger picture on iCloud filtering, see why iCloud is blocking your emails.

Common causes, most likely first

1. Authentication that fails or doesn't align. Apple requires SPF and DKIM, plus a published DMARC policy, for bulk senders. One publicly documented CS01 case was resolved by fixing a mismatch between the DKIM signing domain and the From domain.
2. Poor list quality. Mailing old, bought or scraped addresses generates hard bounces and low engagement. Apple explicitly requires recipients to have subscribed and asks you to remove inactive ones.
3. Content or link reputation. A link to a domain with a bad reputation, a URL shortener, or a shared click-tracking domain can be enough when everything else is clean.
4. IP or domain reputation. A new IP or domain with no history, a sudden volume jump, or a shared IP pool that other senders have damaged.
5. A problem on Apple's side. Public reports exist of CS01 and HM08 blocks that Apple fixed after the sender contacted them, with no sender-side change. Rule out the first four before you count on this.

How to fix it

1. Scope it. Pull every iCloud bounce (icloud.com, me.com, mac.com) and note which code, which IPs, which campaigns or message types, and when it started. A block that hits only one campaign points at content. One that hits everything points at authentication or reputation.
2. Check authentication on a real message. Run its headers through the header analyzer. SPF and DKIM should pass, and at least one should align with your From domain. The SPF, DKIM and DMARC checker shows what your DNS currently publishes.
3. Fix what's broken. Set up custom DKIM so the signature carries your domain, keep SPF under the 10-lookup limit, and make sure a valid DMARC record exists. If DKIM is failing outright, DKIM fail: body hash did not verify covers the usual reasons.
4. Check reverse DNS. Apple asks for reverse DNS that includes your domain. On a dedicated IP, the PTR record should point to a hostname you control that resolves back to the IP.
5. Clean the list. Suppress hard bounces. Pause anyone who hasn't clicked in several months. Drop any segment from a source you can't explain.
6. Strip the content down. Send a plain version without shorteners and with links only to your own domain. If that goes through and the full version doesn't, the problem is in the content or a linked domain. Check those domains against the blocklists that matter.
7. Email Apple. If the blocks continue after all that, write to icloudadmin@apple.com with your company name, your email domain, the IP addresses of the affected servers, the exact SMTP errors, and a detailed description including when it started. Apple asks for all five.

How to confirm it's fixed

Send to a small segment of recent, engaged iCloud subscribers and watch the bounce log for those domains. If CS01 or HM08 stops appearing, increase volume gradually over a few days. Look at clicks rather than opens to judge whether mail is reaching people, since Apple Mail Privacy Protection inflates opens.

How to keep it from coming back

• Keep every sending service on custom DKIM and re-check authentication whenever a tool is added.
• Suppress hard bounces at once and sunset inactive subscribers on a schedule.
• Keep sending consistent: same domains, same IPs, steady volume.
• Track iCloud bounces as their own segment. Apple has no feedback loop, so bounces are the only signal you get.

When to get help

If you've cleared authentication and list quality and the blocks persist, or you can't tell which stream is triggering them, bring in someone who reads these bounces every day before you write to Apple.

FAQ

What's the difference between CS01 and HM08?

Apple doesn't say. Both carry the same "rejected due to local policy" wording and point to the same postmaster page. Work through the same checklist for either one.

Is CS01 a blocklist listing?

Not a public one. It's Apple's internal filtering. A public blocklist rejection would usually name the list, like the Proofpoint block covered in why Proofpoint is blocking your emails.

How long does a CS01 block last?

Apple doesn't publish a timeframe. Blocks tied to a fixed cause often ease as reputation recovers, but if nothing changes after you've fixed the obvious problems, contact icloudadmin@apple.com.

Should I remove iCloud addresses that bounced with CS01?

No. CS01 and HM08 are about you, not the recipient. Removing those addresses loses real subscribers. Suppress only addresses that return a user-unknown error like 550 5.1.1, and check that your ESP hasn't automatically marked policy bounces as hard bounces.