Do not suppress every Apple address by one domain
Answer Do not suppress Apple mail by one domain. On August 24, 2026 Apple said new Sign in with Apple addresses will move from privaterelay.appleid.com to private.icloud.com, existing privaterelay addresses will keep forwarding, and iCloud+ Hide My Email will stay on icloud.com. Developers must allow both private.icloud.com and privaterelay.appleid.com. A one-domain kill rule does not match that note.
The note that started this: Updates to Sign in with Apple private email addresses, Apple Developer, August 24, 2026.
Friday's note refused to freeze the June wording. Today's note is the newer page. The plan narrowed. New Sign in with Apple addresses are the ones moving. Hide My Email, which the June text had also pointed at private.icloud.com, stays where it was after people pushed back. A suppression file built on the June sentence is now wrong in a specific way. It will not match the suffixes Apple just described.
The page is Apple's developer news for August 24, 2026. Starting later this year, new Sign in with Apple private addresses are issued on private.icloud.com instead of privaterelay.appleid.com. Addresses that already exist on privaterelay.appleid.com continue to work, and mail to them continues to forward. Hide My Email stays on icloud.com. Apple tells anyone who validates or allowlists these addresses to accept private.icloud.com in addition to the older privaterelay host. That is an allow instruction. It is the opposite of a block.
What did Apple say on August 24, 2026 about new relay addresses?
Starting later this year, new Sign in with Apple addresses move from privaterelay.appleid.com to private.icloud.com. Existing privaterelay addresses keep working and keep forwarding.
Later this year means the new suffix is coming, not that every old address died this morning. A seller who purges privaterelay.appleid.com today is deleting people whose forwarding Apple just confirmed. A seller who only allowlists the old suffix will start rejecting new signups when the new host turns on. The adult move is to accept both, and to keep accepting them only when the person opted in.
On a solo ad, you do not run Apple's signup form. You do inherit the seller's habits. If their hygiene script contains a homemade Apple block, the file you are renting is already missing a slice of real subscribers, or it is about to bounce a slice of new ones. Ask what the script does. The pages on safe solo ads sellers are the right place to ask it, next to the question of where the names were collected.
- privaterelay.appleid.com stays if the person opted in.
- private.icloud.com is added, not swapped in as a purge.
- The change is later this year, not a retroactive deletion.
- The quote says the seller accepts both.
What happened to Hide My Email in that update?
After community feedback, iCloud+ Hide My Email stays on icloud.com. Apple told developers to accept private.icloud.com in validation and allowlists in addition to privaterelay.appleid.com.
This is the line that breaks the clever filter. Hide My Email lives on icloud.com. Ordinary iCloud mail lives on icloud.com. A rule that calls every icloud.com address a relay, or every icloud.com address a bot, cannot tell a person with a normal mailbox from a person hiding one. Both can be subscribers. Neither should be deleted because the domain is famous. The June note had blurred these products. The August note splits them again. Use the split.
If you sell the mail, update the allowlist and leave the blocklist alone. Accept the new host when it starts appearing. Keep the old host. Do not build a segment called Apple bots out of a suffix. The complaint you will earn is from a person who did opt in and then watched the mail vanish, or from a buyer who paid for a count that your script had already shrunk.
Why is a single-domain suppression a bad solo ad rule?
A rule that drops one Apple suffix will miss the new one or kill the old one. A rule that treats every icloud.com address as a bot also throws out ordinary iCloud customers and Hide My Email users. Ask who opted in. Do not ban a suffix.
The opt-in question does not change because the host changed. A private address that joined the seller's form is a subscriber. A private address that arrived in a purchased file is still a bad address, for the same reason a gmail.com address in that file is bad. The domain is not the sin. The collection is the sin.
Before you buy solo ads, ask the seller to say the three hosts out loud and to say they do not purge them as a class. Apple's August 24 note is an allowlist update. Copy the allow. Leave the invention of a block to someone who wants a smaller list than they are selling.