Should I suppress Apple private relay addresses and how to handle them?

Published 12 Aug 2025

Updated 10 Oct 2026

14 min read

Summarize with

Apple private relay email forwarding for Sign in with Apple and Hide My Email.

Updated on 10 Oct 2026: We updated our guidance for Apple's revised domain plan and suppression decisions based on delivery evidence.

No. Do not suppress every Apple private relay address just because it ends in @privaterelay.appleid.com or @private.icloud.com. If the address came through Sign in with Apple, Hide My Email, or another user-controlled flow, treat it like a real customer address. Send the mail the user asked for, watch delivery, and suppress it only when normal bounce, complaint, consent, or engagement rules say you should. Keep marketing permission separate from required account notifications.

The key distinction is source. A private relay address that came from your app login flow or was intentionally entered by the user has user intent behind it. A private relay address that appears in a purchased lead file, a scraped list, or an unexplained surge of form submissions is a data quality warning. Investigate where it came from before deciding whether to mail it.

Default rule: Keep legitimate Apple private relay users active. Apply delivery suppression to undeliverable aliases and marketing suppression to complaints, unsubscribes, or missing permission.
Investigate rule: If these addresses enter a public form unexpectedly, use source logging, CAPTCHA, and double opt-in where the risk warrants it.
Suppression rule: Suppress specific private relay recipients that prove undeliverable, not the whole domain.

What Apple private relay addresses mean

Apple private relay email addresses are generated when a user chooses to hide a personal email address through Sign in with Apple or iCloud+ Hide My Email. The address forwards mail to a verified address on the user's Apple Account while keeping that underlying address private from the app or website.

This is different from iCloud Private Relay for web browsing. That browser privacy service hides network information. A private relay email address is an email forwarding identity. Turning off browser Private Relay or blocking its network endpoints does not deactivate an email alias.

The practical answer

If the user created the account through your Apple app flow and Apple returned a relay address, that address is the user's chosen contact address for your service. Treat it as a first-party signup. Sign in with Apple does not require iCloud+, and an account signup does not itself give permission for marketing.

Sign in with Apple email relay flow with sender registration and forwarding to the user's inbox.

Apple's published plan is to issue new Sign in with Apple addresses on @private.icloud.com later in 2026. Existing addresses on @privaterelay.appleid.com continue to forward mail. iCloud+ Hide My Email addresses remain on @icloud.com. Accept the new Sign in with Apple domain without rewriting or retiring existing aliases. Apple's current domain guidance.

Account validation: Accept private.icloud.com without rejecting it as disposable or malformed.
Routing rules: Include private.icloud.com in domain-based filtering, routing, and suppression rules without blocking it by default.
Legacy records: Do not rewrite, merge, or retire existing relay aliases.

Do not classify every @icloud.com recipient as a relay user because iCloud.com is also a normal mailbox domain. For Sign in with Apple, record Apple's is_private_email signal. For manually entered Hide My Email aliases, retain the signup source and the exact address supplied by the user.

When suppression makes sense

Suppress Apple private relay addresses for the same recipient-level reasons that apply to other addresses. The domain alone is not the reason. The recipient's behavior, the mail system response, and your permission model determine the action.

Situation	Action	Reason
Apple app signup	Keep active	The user chose this address; marketing needs separate permission.
Purchased lead	Do not mail	A purchased record does not establish permission for your mail.
Hard bounce	Diagnose, then suppress	Confirm it is recipient-specific, not a sender setup failure.
Relay deactivated	Suppress	Apple no longer forwards mail for the alias.
Repeated soft bounce	Pause; suppress persistent failures	Use completed retry history and the actual delivery error.
Complaint	Suppress marketing	Honor the complaint under your suppression policy.
Marketing unsubscribe	Stop the relevant marketing subscription	Keep required account notifications separate from marketing permission.

Use the address source and delivery outcome to decide the action.

A blanket rule that labels every @privaterelay.appleid.com or @private.icloud.com recipient as low value removes legitimate users. The user made a privacy choice. That does not make the address disposable.

Suppress the individual address

Hard failure: The recipient returns a permanent bounce after sender setup is verified.
Repeated failure: The same address remains undeliverable after retries and sender checks.
User signal: Honor marketing opt-outs; stop all email to a disabled relay alias.

Do not suppress the domain

Valid users: Many private relay users are legitimate customers.
Lost lifecycle mail: Password resets and account notifications stop.
Bad diagnosis: A blanket rule hides the real source or configuration problem.

For Sign in with Apple accounts, validate Apple's signed server-to-server notification before applying an email-disabled event. Record email-enabled events separately and review other suppression reasons before restoring sending. Reactivating forwarding does not remove an unsubscribe or complaint. A user can also deactivate a Hide My Email alias, which stops forwarding and returns future messages to the sender. Apple's forwarding change notifications.

If a customer is missing account emails, ask them to check forwarding for the app in Sign in with Apple settings, or the alias in Hide My Email, and verify the Forward To destination. Offer a verified contact-address change through account support if forwarding stays disabled.

Handle soft bounces carefully

Soft bounces need more nuance than hard bounces. A single temporary failure does not mean the private relay address is dead. It can mean mailbox capacity, temporary policy filtering, rate limiting, a forwarding issue, or a sender authentication problem.

Use your sending platform's retry schedule for temporary failures. Pause new campaigns to repeatedly failing addresses, then suppress persistent recipient failures after retries finish and sender setup is verified. Keep inactivity-based marketing suppression separate from bounce suppression; account activity does not make a failing address deliverable.

Preserve the full SMTP response and delivery status notification (DSN) in your logs. A hard-bounce label alone does not distinguish a disabled alias from an unregistered sender or failed authentication. Fix a sender-wide configuration error before reconsidering affected recipients; do not repeatedly resend unchanged messages after a permanent rejection.

Soft bounce handling stages

An operational framework, not an Apple rule. Set retry and pause thresholds using your platform's policy, send cadence, and bounce evidence.

No reported failure

0 failures

The relay accepted mail and no later delivery failure was reported.

Watch

1 failure

One temporary failure after prior activity.

Pause

Policy threshold

Recipient failures repeat after the normal retry process.

Suppress

Persistent

Recipient failures persist after retries, a pause, and successful sender checks.

Be careful with platform terminology. Some marketing tools use labels such as received, sent, delivered, bounced, and skipped in ways that are not interchangeable. If a filter says the user received a message, confirm whether that means the platform sent it or whether the receiving system accepted it. Apple's relay accepting a message does not prove that the final inbox received it; forwarding or spam filtering can still affect delivery.

Do not treat sent as delivered

A message can be sent by your platform and still bounce later. Build suppression and audience paths using receiver acceptance and later bounce events, plus permission and confirmed activity. A generic send event does not prove delivery.

Measure engagement without relying on opens

Hide My Email forwards messages and hides the recipient's personal address. Mail Privacy Protection is a separate Apple Mail setting that downloads remote content in the background even when the user has not read the message. An open-tracking pixel therefore does not prove engagement. A relay address also does not tell you which mail app or privacy settings the recipient uses. Apple's Mail Privacy Protection explanation.

Use authenticated app activity or purchases to distinguish active customers from dormant marketing subscribers.
Use confirmed clicks and completed opt-in confirmations as additional engagement signals.
Keep required account notifications separate from marketing sunset rules.
Do not suppress an address solely because tracked opens are missing or appear unusually high.

Fix the source before suppressing the symptom

Private relay addresses from an iOS app or Sign in with Apple are expected. A user can also create an iCloud+ Hide My Email alias and intentionally enter it in a normal web signup form. Trace the source when relay addresses appear in a paid lead import, sweepstakes list, partner feed, offline upload, or an unexplained cluster of form submissions. A Sign in with Apple alias is associated with its developer team, so use the alias returned for your own app or website.

App login: Keep the user unless delivery or consent signals say otherwise.
Standalone form: Respect a valid alias, log the source, and use double opt-in plus bot controls where risk is high.
Lead import: Quarantine the import and require provable consent before sending.
Unknown origin: Hold the audience out of marketing until the acquisition path is clear.

Simple segmentation logictext

# Pseudocode: apply delivery checks before sending.
if verified_apple_event == "email-disabled":
  suppress_address(reason="relay_disabled")
if verified_apple_event == "email-enabled":
  clear_only_relay_disabled_suppression()

if hard_bounce == true:
  if recipient_specific_failure == true and sender_setup_verified == true:
    suppress_address(reason="recipient_undeliverable")
  else:
    pause_stream_and_fix_sender()
if soft_bounce_policy_threshold_reached == true:
  pause_address_and_review()

if source == "unknown" and address_domain in ["privaterelay.appleid.com", "private.icloud.com"]:
  hold_for_review()

if delivery_suppressed == true or address_paused == true or held_for_review == true:
  stop()

if account_notification_required == true:
  send_required_account_mail()
if marketing_opt_in == true and unsubscribed == false and complaint == false:
  send_marketing()

Double opt-in has a cost because some real users will not confirm. It keeps unconfirmed submissions and unreachable addresses out of the subscribed audience. Fix sender registration and authentication before treating a failed confirmation as an invalid recipient. For high-risk acquisition paths, that tradeoff is usually worth it.

How to handle Apple private relay addresses based on signup source and suppression rules.

Register sending sources and authenticate mail

Apple's Sign in with Apple private email relay checks whether mail comes from a registered source and authenticates it with SPF and/or DKIM. Register every outbound domain, subdomain, or exact sending address used for the flow, including customer support and account-notification senders. An unregistered source can bounce even when the recipient is valid. Apple's relay configuration requirements.

For SPF, the registered domain must match the envelope sender (MAIL FROM or Return-Path) domain exactly and pass SPF. For DKIM, a valid signature must cover the From header, and its signing domain (d=) must exactly match the registered From domain. If your provider uses its own envelope sender domain, configure DKIM with your registered From domain. Authenticate with both SPF and DKIM where possible. These exact domain requirements mean that a DMARC pass with relaxed domain matching does not by itself confirm Apple's relay checks. DMARC domain matching requirements.

A fast operational check is to send a real message through the same stream and inspect the headers, authentication, and content result with Suped's email tester. Then validate the sending domain with Suped's domain health check to identify authentication gaps before diagnosing individual relay recipients.

Email tester

Send a real email to this address. Suped shows a results button when the test is ready.

?/43tests passed

Check configuration before suppressing

If many relay recipients start bouncing after a From domain, Return-Path, or sending service change, verify Apple source registration and authentication first. Suppressing those recipients would hide a sender-side failure.

Apple documents a daily limit of 100 messages per Sign in with Apple private relay address, including developer messages and user replies. Keep account mail and campaign frequency below that ceiling, and investigate loops or duplicate sends if one recipient approaches it. Apple's relay messaging documentation.

Suped's product supports the sender-side investigation. DMARC reports from participating receivers identify reported sending sources and SPF or DKIM results, while DNS checks help detect authentication changes. Compare that evidence with your sending platform's bounce logs and Apple's source registration.

Suped DMARC dashboard showing email volume, authentication health, and source breakdown

If Apple private relay problems coincide with domain reputation problems, review DMARC pass results, authenticated sources, complaint rates, bounce trends, and blocklist monitoring together. Correlate any blocklist (blacklist) listing with the SMTP response before assigning the cause.

Build a safer audience path

If your platform does not expose soft bounce suppression cleanly, use an audience path that checks delivery events and confirmed activity early. Keep marketing permission as a separate gate, and use double opt-in when the signup risk warrants it.

Better new-user path

First message: Send a useful account welcome or an opt-in confirmation email, based on what the user requested.
Delivery check: Suppress recipient-specific hard failures after sender checks pass.
Engagement gate: Use clicks, app activity, purchases, or another confirmed action alongside marketing permission.
Suppression review: Pause repeated soft bouncers before broad campaigns.

Risky new-user path

Bulk import: Mix app users, leads, and old records.
No confirmation: Send before validating consent or reachability.
Weak filter: Treat sent events as delivery proof.
Late cleanup: Suppress only after reputation damage appears.

A short welcome series can help separate valid recipients from unreachable addresses. Keep it useful and light with a welcome email followed by account or product guidance. Send a reminder only after the user shows activity. If delivery failures persist after sender checks, suppress the address. If messages are accepted but the user is inactive, apply your marketing sunset policy using confirmed activity rather than opens.

Keep separate fields for source, marketing permission, delivery state, confirmed activity, and suppression reason. Apply any audience restrictions independently of whether the address is an Apple relay alias.

A clean suppression reason helps later

Store whether the user was suppressed because of a hard bounce, repeated soft bounce, complaint, unsubscribe, consent rule, deactivated relay, or unknown source. That prevents private relay users from being blamed for unrelated list quality problems.

How Suped fits into the workflow

Suped's product provides DMARC reporting and sender authentication checks for this investigation. Compare reported services and authentication results with your bounce logs, then verify each source in Apple's developer account. Keep consent, recipient suppression, and forwarding status in your account and sending systems.

Sender visibility: Use DMARC monitoring to see which sources send as your domain and whether they pass.
Authentication alerts: Review notifications about DNS or authentication changes and investigate the affected sending stream.
Hosted SPF: Manage senders without repeated DNS edits and avoid lookup-limit issues.
Blocklist monitoring: Correlate blacklist or blocklist listings with SMTP errors before attributing Apple-domain failures.

Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action

The decision still belongs in your lifecycle platform: keep valid app users, suppress undeliverable addresses, and quarantine unknown sources. Suped makes the sender-side diagnosis clearer while you make those audience changes.

Views from the trenches

Best practices

Treat Apple relay app signups as valid users unless delivery or consent says otherwise.

Use double opt-in and CAPTCHA for risky signup forms, including forms that accept relay aliases.

Separate source, marketing permission, delivery status, and activity before suppressing recipients.

Common pitfalls

Blanket suppressing the relay domain removes real users who made a privacy choice.

Treating sent events as delivered events hides repeated temporary delivery failures.

Blaming Apple relay addresses can mask purchased-list or bot-form acquisition issues.

Expert tips

Pause repeated soft bouncers; suppress persistent recipient failures after sender checks pass.

Use a short welcome series to check reachability, with separate permission for marketing.

Audit authentication and reputation before assuming Apple relay is the root cause.

Marketer view

Marketer from Email Geeks says private relay addresses from an Apple registration flow are valid recipients when the sender has completed the required Apple setup.

2024-10-21 - Email Geeks

Marketer view

Marketer from Email Geeks says a user who chooses a private relay address can still be real and interested, especially when the address came through an app flow.

2024-10-21 - Email Geeks

Apply suppression rules by message type

Keep delivery suppression separate from marketing opt-outs. An unsubscribe stops the relevant marketing subscription; an unreachable or disabled alias stops email to that address, including account messages. Offer forwarding reactivation or a verified contact-address change through account support without deleting the customer's account.

Frequently asked questions

No. Suppress individual undeliverable aliases after checking sender setup, and stop marketing for complaints, unsubscribes, or missing permission. Hold untrusted sources for review.

Yes. Apple plans to issue new Sign in with Apple aliases on private.icloud.com later in 2026, while existing privaterelay.appleid.com aliases keep working. iCloud+ Hide My Email stays on icloud.com. Accept the new domain without removing existing addresses.

They can be. If the address came through Sign in with Apple or the user intentionally supplied a Hide My Email alias, it has a clear user-controlled source.

Use your sending platform's retry schedule, pause repeated recipient failures, and suppress persistent failures after sender setup is verified. Missing tracked opens are not evidence that an alias is undeliverable.

Use double opt-in for high-risk forms, lead sources, or flows with weak consent. A Sign in with Apple account signup is not marketing consent. Keep required account notifications separate from optional campaigns.

Yes. The Sign in with Apple relay requires registered sending sources and SPF and/or DKIM authentication. A DMARC pass does not replace Apple's registration checks. Compare authentication results and any blocklist (blacklist) listing with the actual bounce response.