How do you get email delivered to iCloud Mail and Apple private relay addresses?

iCloud Mail covers icloud.com, me.com and mac.com addresses, and Apple also forwards mail sent to private relay addresses that hide a person's real inbox. Both have their own rules for senders. This guide covers what Apple's postmaster page requires, how to send to Hide My Email and Sign in with Apple relay addresses without bouncing, and what Mail Privacy Protection changes, as documented at the time of writing (November 2026).

What does iCloud Mail require from senders?

iCloud Mail requires bulk senders to authenticate with SPF and DKIM, publish DMARC, use reverse DNS and send only to people who opted in. Apple's Postmaster information for iCloud Mail page is blunt about it: "All requirements must be met in order to send a bulk email. If not, the email will be rejected."

Apple's list for bulk senders, summarized:

• Send only to recipients who explicitly subscribed, "not list purchases, list rentals, or email appends."
• Include an unsubscribe link that takes effect immediately.
• Add ARC headers to forwarded mail. ARC (Authenticated Received Chain) records authentication results before a forwarder changes a message; see how forwarding breaks SPF and DMARC.
• Comply with RFC 5321 and RFC 5322.
• "Publish reverse DNS with your domain to help identify your IP addresses."
• Use consistent sending IPs and domains, and separate marketing from transactional mail.
• Use a consistent From name and address.
• Use SPF and DKIM, and publish a DMARC policy.
• Track temporary and permanent SMTP errors and act on them, with a standard policy for bounced addresses.
• Periodically remove inactive subscribers, and never reactivate addresses on unsubscribe or suppression lists.

Apple doesn't give a volume threshold for "bulk." Treat these as the baseline for any automated mail: newsletters, receipts, password resets and alerts. Many of them overlap with what Gmail and Yahoo require; our bulk sender requirements guide covers those.

Does iCloud Mail check DMARC?

Yes. Apple's postmaster page says iCloud Mail checks inbound mail with SPF and DKIM and honors the sending domain's DMARC policy. DMARC (Domain-based Message Authentication, Reporting and Conformance) is the DNS record that tells receivers what to do when mail claiming to be from your domain fails authentication. Read what DMARC is if you haven't set it up.

Apple also protects its own domains. iCloud domains have published a DMARC policy of p=quarantine since July 2, 2018, so mail claiming to come from an iCloud address that fails SPF and DKIM should go to "the recipient's Junk folder."

That has a practical consequence. If a website form or app sends mail with a customer's @icloud.com address in the From line, receivers that honor DMARC will treat it as failing. Send from your own domain and put the customer's address in Reply-To. Our guide to website form emails going to spam shows how.

A quick check for your domain:

1. Look up your SPF record with the SPF Checker.
2. Confirm DKIM signing with the DKIM Checker.
3. Confirm DMARC exists with the DMARC Checker.
4. Check your sending IP's reverse DNS with the PTR Lookup, if you run your own server.

Does iCloud Mail have an allow list or feedback loop?

No to both. Apple says iCloud Mail doesn't offer an allow list for bulk senders, and judges reputation using IP and domain reputation, content checks and user feedback. It also doesn't offer a feedback loop (FBL), the reports Yahoo and Microsoft send when a user marks your mail as spam.

Apple's alternative advice is to suppress inactive or disengaged subscribers periodically, remove addresses that bounce repeatedly, and honor unsubscribe requests promptly. Without complaint reports, your bounce logs and unsubscribe rate are the only direct signals you get from iCloud. Our guide to email feedback loops covers the providers that do send them.

What are Hide My Email and Apple private relay addresses?

Apple gives users several privacy features with similar names. Only two of them create email addresses you'll send to.

Apple's Hide My Email page says the service is "included with an iCloud+ subscription." It also explains the two endings: signing in with Sign in with Apple creates an address ending in @privaterelay.appleid.com, and other sites get one ending in @icloud.com. Apple's developer documentation lists @private.icloud.com, @privaterelay.appleid.com and @icloud.com as relay endings.

Two consequences follow. First, you can't tell a relay address from an ordinary iCloud mailbox by the @icloud.com ending alone. Second, you should never "clean" relay addresses out of a list just because they look random. They belong to real people who chose privacy.

How do I send email to privaterelay.appleid.com addresses?

If your app or website offers Sign in with Apple, register your sending domains with Apple before you email users. Apple's developer documentation says senders "must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails."

Register your email sources

Apple's account help gives these steps:

1. In Certificates, Identifiers & Profiles, click Services in the sidebar, then click Configure under Sign in with Apple for Email Communication.
2. In the Email Sources section, click the add button (+).
3. Enter a comma-delimited list of domains and subdomains you send from, then click Next.
4. Confirm the sources and click Register.
5. Check the table, which shows whether each registered source passed an SPF check.

You can register individual addresses instead of domains. Individual developer accounts can register up to 32 email sources, and organizations up to 100. Register every subdomain you send from. Apple's example: to send from john@sales.example.com, register both example.com and sales.example.com, or register the individual addresses.

Match SPF or DKIM exactly

Apple says all mail through the relay must pass SPF and/or DKIM, and recommends both. The matching is stricter than DMARC's usual relaxed alignment:

• SPF: the domain in the envelope sender (also called MAIL FROM, bounce or Return-Path address) must be registered, and "the registered domain and envelope sender domain must match exactly."
• DKIM: the signature must pass, must cover the From address, and "the DKIM domain and the domain in the From: address must match exactly."

That second rule catches many email platforms. If your provider uses its own domain in the Return-Path, SPF checks the provider's domain, not yours, so you need DKIM signed with your exact From domain. Apple says so directly: if your provider "uses their domain in the envelope sender," you "must sign your emails with DKIM." Our guide to Return-Path vs From explains the two addresses, and authenticating third-party senders covers custom DKIM on common platforms.

An SPF record that authorizes an email platform looks like this example from Apple's help page (replace the include with your own provider's):

example.com. IN TXT "v=spf1 include:amazonses.com ~all"

How replies work

When a user replies, Apple's relay routes the reply back to the address you sent from, and rewrites your address so it stays readable. Apple's example: sales@example.com may become sales_at_example_com_<something>@icloud.com. Make sure the address you send from can receive mail, or replies are lost.

Why do emails to Apple private relay addresses bounce?

When mail to a relay address bounces, check these causes in order.

The user's choice to stop receiving email has a wider effect. A relay address is the same across all apps from one development team, so if a user turns off forwarding for one of your apps, it affects your others too. Apple can email the account holder and team admins when relay delivery fails; check that someone reads those messages.

Does Mail Privacy Protection affect deliverability?

It doesn't change whether your mail is delivered, but it changes what you can measure. Apple's Mail Privacy Protection page says the feature "downloads remote content in the background by default" and routes it through two separate relays operated by different entities. Remote content includes the tracking pixel many platforms use to count opens.

Because content can load whether or not someone reads the message, open rates for Apple Mail users become unreliable. That matters for reputation work. Apple asks you to remove inactive subscribers, but "inactive" can't safely mean "no opens" for these users. Use clicks, replies, purchases or log-ins as your engagement signal instead.

What do iCloud Mail bounce messages look like?

Apple says its servers "generate SMTP errors with information about why your connection or message was rejected," and that "most of the errors will also include a URL that provides more information." Apple doesn't publish a code-by-code list or sample error text. The line below is an illustrative example of a rejection senders have reported, not wording Apple documents, and the exact text can change:

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

The old HT204137 link now redirects to the postmaster page above. Treat a 5xx code as permanent: fix the cause before resending, and don't keep retrying to the same address. If the cause isn't clear, check authentication on a real message with the Deliverability Test, your IP on blocklists, and whether a compromised account has been sending spam. Our hard bounce vs soft bounce guide explains how to handle each class.

How do I contact Apple about iCloud Mail delivery?

Apple's postmaster page says administrators who can't resolve a problem should email icloudadmin@apple.com with:

1. Your company name.
2. Your email domain.
3. The IP addresses of the affected mail servers.
4. The SMTP errors you're receiving.
5. A detailed description of the issue, including when it started.

Fix what you can first. If you're not a system administrator, Apple says to contact Apple Support instead.

Next steps

• Send a test message through the Deliverability Test and confirm SPF, DKIM and DMARC pass with your own From domain.
• If you use Sign in with Apple, register every sending domain and subdomain in your developer account today, and confirm each one passes Apple's SPF check.
• Make sure your email platform signs DKIM with your exact From domain, not a shared domain.
• Base inactivity rules on clicks and actions, not opens.
• Compare your setup with Yahoo's rules and Gmail's, and use the email deliverability checklist for a full review.
• To catch DNS changes that quietly break SPF or DMARC, iBlockSpam's domain monitoring alerts you when they change.

Browse more guides on running email day to day.