iCloud Bulk Sender Requirements: The Checklist Apple Publishes for Mail to iCloud

Apple's rule for bulk mail to iCloud is all-or-nothing: meet every requirement on its list or the email is rejected. The list is published on Apple's support page for bulk mail to iCloud Mail, read on 9 November 2026. Some items are DNS and authentication work. The rest are about who is on your list, and that part is where list hygiene does the heavy lifting.

Check an iCloud address →

The requirements in plain English

Apple's page, in our words:

Requirement	What it asks of you
Opt-in only	Mail only people who asked for it. No purchased, rented or appended lists
Unsubscribe link	Include one that takes effect right away
ARC headers	Add them when you forward messages
RFC 5321 and 5322	Your SMTP and message format must follow the standards
Reverse DNS	Publish records that point to your domain
Consistency	Keep sending IPs and domains consistent for bulk mail; separate marketing from transactional streams
Steady From	Use a consistent From name and address
SPF and DKIM	Authenticate your mail
DMARC	Publish a policy
Track SMTP errors	Watch temporary and permanent errors and act on them
Bounce policy	Have a standard policy for bouncing addresses
Inactive subscribers	Remove them regularly
Suppression	Don't reactivate addresses on unsubscribe or suppression lists

Apple states the stakes in one line: "All requirements must be met in order to send a bulk email. If not, the email will be rejected."

The technical half

These are DNS and sending-setup items. You fix them once and monitor.

SPF and DKIM. Every service that sends as your domain needs to be in SPF and signing with DKIM. The email domain health checker shows what your domain publishes today.

DMARC. A published policy is on the list. Gmail and Yahoo's bulk sender rules ask for the same, so one setup covers all three. The DMARC alignment checker shows whether your From domain lines up with what SPF and DKIM authenticate.

Reverse DNS. Your sending IP needs a PTR record that points to your domain. The reverse DNS lookup shows what yours returns, and reverse DNS and PTR records for email explains what a good one looks like.

RFC compliance. Mostly your sending platform's job. If you run your own server, malformed headers are the usual culprit.

ARC on forwarded mail. Only relevant if you forward messages. Most marketing senders don't.

Consistency. Don't rotate sending domains and IPs to dodge limits. Apple lists consistency as a requirement, and keeping marketing and transactional mail on separate streams protects your receipts and password resets from a marketing problem.

The recipient half

This half is about your list, not your DNS.

Opt-in only, no bought lists

Apple's page says to mail "only recipients who opted in," and rules out purchased, rented and appended lists. For a cold-outreach sender that is a hard stop worth knowing about: if a list of iCloud addresses came from a scrape or a vendor, this rule is not met. For newsletters and customers, keep the signup record for every address.

Working unsubscribe

The link must take effect right away. Test it. Our one-click unsubscribe guide walks through the header setup that Gmail and Yahoo also ask for.

A bounce policy and tracking errors

Apple wants you to track temporary and permanent SMTP errors and have a standard policy for bouncing addresses. In practice that means:

1. Hard bounces (the mailbox doesn't exist) are suppressed after the first one.
2. Temporary failures retry for a limited time, then are treated as failed.
3. Someone looks at the error text. Apple says its servers "generate SMTP errors with information about why your connection or message was rejected," and "Most of the errors will also include a URL that provides more information." Paste a bounce into the bounce message analyzer if the wording is unclear.

If you are seeing the generic "message rejected due to local policy" text, iCloud 554 5.7.1 CS01 and HM08 covers how to read it.

Remove inactive subscribers

Apple lists regular removal of inactive subscribers as a requirement. Pick a window that fits your sending rhythm, then move people who haven't opened or clicked into a sunset segment before removing them. Verification is the first pass: a mailbox that no longer exists is inactive for good, and it is a bounce waiting to happen.

Never reactivate suppressed addresses

Importing an old list on top of a new one is how suppressed addresses come back. Always merge your suppression list into any file you import. Cold email suppression lists covers the mechanics.

Where verification fits

Verification can't fix DNS or prove opt-in. What it does for these requirements:

• Bounce policy: pre-send removal of non-existent iCloud mailboxes keeps hard bounces near zero, so there is less to track and act on.
• Inactive subscribers: closed accounts show up as invalid, which is a cleaner first cut than waiting for bounces.
• Error tracking: fewer hard bounces means the errors you do see stand out.

A simple routine for iCloud rows:

1. Split out icloud.com, me.com and mac.com addresses. Email list segmentation by mailbox provider shows how.
2. Upload the file at /verify.
3. Suppress invalid rows. Keep risky rows out of the first send.
4. Send iCloud rows in a smaller batch at first, then watch the bounce text.

For one-off checks, see verify an iCloud email address.

A pre-send checklist

• SPF and DKIM pass for every sending service.
• DMARC policy published.
• PTR record points to your domain.
• Unsubscribe link tested.
• Marketing and transactional mail on separate streams.
• Suppression list merged into the file.
• Inactive segment removed or sunset.
• iCloud rows verified in the last few days. How often to verify an email list suggests a schedule.

Mistakes that break the iCloud rules without anyone noticing

1. Adding old lists on top of new ones. That is how suppressed addresses come back, which Apple lists as a requirement not to do.
2. Mixing marketing and transactional mail on the same domain and IP. Apple asks for separate streams.
3. Changing the From name and address between campaigns. Apple lists a steady From as a requirement.
4. Treating "bulk" as someone else's problem. If you send marketing mail to a list, read the whole page.
5. Not reading the rejection text. Apple says most errors include a URL with more information. The answer is usually already in your logs.

Quick answers

• Does Apple publish thresholds, like a spam-rate number? Not on this page. It lists requirements, not numbers.
• Is this only for big senders? The page is titled for bulk mail. Apple doesn't define "bulk" in the text we read, so treat the list as the standard if you send marketing mail at any volume.
• Where do I see the exact rejection reason? In your mail logs. The text and URL come from iCloud's servers.

Try it on your own list

Run an iCloud slice at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.