554 5.7.1 [CS02] — Message rejected due to local policy (iCloud)
Retrying will not help. The message will not be delivered.
The reply
554 5.7.1 [CS02] Message rejected due to local policy.The one label in this family where looking at the message is the right first move. CS02 is consistently reported on mail that resembles phishing — copy that asks for credentials, a From: name that does not match the sending domain, links whose visible text differs from where they go.
What it means
Still a permanent 5.7.1 policy rejection, but the reported pattern behind CS02 is narrower than CS01's: it clusters on messages whose shape imitates an account notice. That is an awkward category for legitimate senders, because a password reset and a phishing attempt are the same message written by different people. Apple has not confirmed this reading, but it is consistent enough to act on.
Why it happens
- Copy that asks for a password, payment details or identity documents, even legitimately.
- A display name naming one brand while the sending domain is a different one — a pattern authentication cannot rescue.
- Link text that shows one destination and an href that goes somewhere else.
- Links through a shortener or a redirector on a domain unrelated to the sender.
- A login or verification message from a domain with no history, which is indistinguishable from the real thing being imitated.
What to do
- Remove any request for credentials or payment data from the body. Send people to your site to act there instead.
- Make the display name and the sending domain tell the same story. If the mail is from Example, it should come from a domain with Example in it.
- Let links show their real destination and point at your own domain. Drop shorteners entirely from transactional mail.
- Add the things a real notice has and a forgery usually does not: a postal address, a support link, an explanation of why this message was sent.
- Verify SPF, DKIM and DMARC alignment — necessary, not sufficient, but a gap here makes the message look exactly like what it is being mistaken for.
Questions
It is a genuine password reset. What now?
That is the hard case, because the genuine article and the forgery have the same anatomy. What separates them to a filter is everything around the copy: an aligned domain, a consistent From: name, links to your own host, and a sending history that makes the address familiar.
Could a link be the whole problem?
It can be. A shortener, a tracking redirect on a domain unrelated to the sender, or a link to a host someone else has abused are each enough on their own. Test by sending the same message with the links pointing straight at your domain.