iCloud "554 5.7.1 Message Rejected Due to Local Policy" (CS01, HM08): What It Means and What to Fix

554 5.7.1 [CS01] Message rejected due to local policy means Apple's iCloud Mail refused your message because one of its filtering rules matched. It is not a statement that the address doesn't exist (that is 550 5.1.1), so don't suppress the recipient on this alone. Apple doesn't publish what CS01, HM07 or HM08 mean, but it does publish the requirements senders must meet: SPF, DKIM, a DMARC policy, reverse DNS, a working unsubscribe, and sending only to people who explicitly subscribed. Work through those, and if everything checks out, email Apple's postmaster address with your sending IPs and the bounces.

What the bounce looks like

The full reply usually reads like this, with a link to Apple's support site:

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

That exact text is recorded by the SMTP Field Manual. Other bounces carry a different bracketed code with the same wording, such as [HM08] Message rejected due to local policy, reported in Apple Community and Microsoft Q&A threads. The link points to Apple's postmaster information for iCloud Mail, which covers Apple's mail domains icloud.com, me.com and mac.com.

The parts mean:

Part	Meaning
554	Permanent failure. Your server won't retry
5.7.1	Delivery not authorized: a policy or security refusal, not a mailbox problem
[CS01], [HM08]	Apple's internal reason code. Not defined publicly
"local policy"	Apple's own filtering, as opposed to a public blocklist

Paste the full bounce into Bounce Doctor to confirm it's a sender-side block and see what else the reply says.

Apple's requirements, as a checklist

Apple's postmaster page (published 25 February 2025, read 2 November 2026) says that if bulk senders don't meet its requirements, "the email will be rejected". Use the list as a checklist:

Requirement	How to check
Authenticate with SPF and DKIM	SPF checker, DKIM checker; confirm the DKIM domain matches your From domain
Publish a DMARC policy on the sending domain	DMARC checker
Publish reverse DNS for sending IPs, with your domain	Reverse DNS lookup; only relevant if you run your own server or dedicated IPs
An unsubscribe link that works immediately	Click it on a real send
Consistent sending IPs and domains; marketing and transactional mail separated	Check which streams share a domain
A consistent From name and address	Look at the last month of sends
Comply with RFC 5321 and RFC 5322	Message headers: one From, one Date, a Message-ID. The email header analyzer shows them
Add ARC headers to forwarded mail	Only if you forward mail (mailing lists, aliases)
Track temporary and permanent errors and act on them; remove inactive subscribers; don't reactivate suppressed addresses	Your bounce and suppression handling
Send only to recipients who explicitly subscribed, not purchased, rented or appended lists	Where the list came from

On authentication, the same page says iCloud checks incoming mail with SPF and DKIM and honors senders' DMARC policies. So a failing or misaligned DKIM signature is worth ruling out first, because it is quick to check. If authentication passes, the problem is more likely reputation, the list or the mail itself.

What usually causes it

Because Apple doesn't publish the codes, any single-cause explanation is a guess. The patterns that fit Apple's list:

• New or changed sending infrastructure. A new domain, a new ESP, a new dedicated IP with no history. Apple asks for consistent IPs and domains.
• Bounces and inactive recipients. Lists with many dead or long-inactive iCloud addresses look like old or bought lists. Apple explicitly asks you to remove inactive subscribers and act on errors.
• The list source. Appended or purchased consumer addresses are named in Apple's rules. If the iCloud addresses came from a data vendor rather than your own sign-up form, that is the likely problem, and no DNS change fixes it.
• Complaints. People marking your mail as junk raises the odds of a block.
• A shared IP. On an ESP's shared pool, another sender's mail can affect yours; tell the ESP, with the bounce text.

What to do, in order

1. Confirm it's iCloud-wide. If every icloud.com, me.com and mac.com recipient bounces with a local policy code, it's your sending. If it's one recipient among many delivering fine, it may be that person's filters or a message-level issue.
2. Pause sends to iCloud domains while you fix things. Pushing more mail into a block rarely helps.
3. Work the checklist above. Authentication and DMARC first, then list source and hygiene.
4. Clean the iCloud segment. Remove addresses that hard-bounced with 550 5.1.1, long-inactive subscribers and anything that didn't come from an explicit sign-up. Verifying the segment removes the dead ones: our checker probes icloud.com, me.com and mac.com, and Apple rejects unknown users with 550 5.1.1, so most come back valid or invalid. A temporary reply comes back risky.
5. Resume slowly, to your most engaged iCloud subscribers first.
6. Contact Apple if you've done all of that. The postmaster page asks administrators to email icloudadmin@apple.com with your company name, email domain, the IPs of the affected mail servers, the SMTP errors received and a detailed description including when it started. If you send through an ESP or a Google or Microsoft mailbox, the platform owns the IPs, so ask them to raise it.

Cold email and iCloud addresses

If you're doing B2B cold outreach and hitting this, look at why iCloud addresses are on the list at all. They are personal mailboxes, and Apple's requirements ask for explicit subscription. Our post on personal emails in a B2B lead list covers swapping them for work addresses or dropping them. The free iCloud email checker checks single addresses; for a whole list, upload it on the verify page.

Where SimpleVerifier fits

Verification removes iCloud addresses that no longer exist, which is one item on Apple's list. It can't fix authentication, reputation or consent. The first 100 checks are free with a Google sign-in. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.