Can I email users who have Apple's private relay email addresses?
Updated on 16 Oct 2026: We updated this guide for Apple's announced relay domain and clarified authentication and bounce handling.
Yes, you can email users who have Apple's private relay email addresses, but the exact rule depends on how Apple created the alias. A Sign in with Apple address must have been shared with your app or website, and your outbound email source must be registered with Apple and authenticated. An iCloud+ Hide My Email address is user-generated and follows a separate forwarding model, but you still need the user's permission to send.
A private relay address is an alias. For Sign in with Apple, it forwards to one of the user's verified Apple Account email addresses without sharing that destination with your app. The user can stop forwarding, and Apple can reject messages from unregistered or unauthenticated Sign in with Apple sources. Each Sign in with Apple relay address has a daily limit of 100 messages, including messages sent by the developer and replies from the user. Apple's relay documentation explains the forwarding model and sender controls.
- Yes: send if the user gave the alias to your app or site, the message matches that relationship, and any required Apple source registration is complete.
- No: do not send if you received the address outside that user relationship or cannot prove permission.
- Expect bounces: failed registration, failed authentication, disabled forwarding, or the 100-message daily limit can stop Sign in with Apple relay delivery.
- Keep identity separate: use your app user ID as the account key, not the relay address alone.
When you can send to a relay address
Use one simple test before sending to a relay address: did the user share this address with this app or site for this communication path? If the answer is yes, the address is usable once the relevant domain setup and consent controls are correct. If the answer is no, the address is not a workaround for reaching the user's hidden mailbox.
The collection method helps identify the workflow. Sign in with Apple creates a relay alias associated with a developer team. iCloud+ Hide My Email generates random addresses at icloud.com for web forms, Mail, Apple Pay, and supported apps. Both protect the user's real mailbox, but their sender setup is different.
Do not treat relay addresses as list assets
A relay address is valid because of a specific user relationship. If another company shares it with you, suppress it unless the user has directly granted permission for your use. Even if a message appears technically sendable, the consent and account context are wrong.
|
|
|
|---|---|---|
User chose Sign in with Apple for your app | Yes | Register the source and pass SPF or DKIM |
User generated Hide My Email for your site | Yes | Use it only for the purpose the user permitted |
Address came from another developer's app | No | No direct relationship |
Purchased or scraped audience | No | Permission is missing |
Support reply to an app user | Yes | Use the registered support source when required |
Permission and sender requirements for common relay address scenarios.
That distinction matters most for marketing teams. A relay address is not automatically bad data. It becomes bad data when it is detached from the app event, account record, or consent trail that created it.
Sign in with Apple and Hide My Email are different
Apple uses private email aliases in two related products. Sign in with Apple creates an address associated with a user and developer team, so apps from the same team can share it. iCloud+ Hide My Email lets the user create random addresses for web forms and other supported contexts. Mixing the two leads to incorrect registration advice and poor bounce handling. These email aliases are separate from iCloud Private Relay, which protects web browsing, and Mail Privacy Protection, which controls remote content loading in Apple Mail.
|
|
|
|
|---|---|---|---|
privaterelay.appleid.com; announced domain: private.icloud.com | Sign in with Apple | Register each source with Apple and pass SPF or DKIM | Source mismatch, authentication failure, disabled forwarding, or daily limit |
User-generated Hide My Email address at icloud.com | iCloud+ Hide My Email | No Sign in with Apple source registration; use normal authenticated sending and valid consent | User deactivation, permanent deletion, or normal mailbox filtering |
Use the collection method with the address domain to identify the forwarding rules.
An icloud.com suffix alone does not identify Hide My Email, because ordinary iCloud Mail addresses use it too. Do not infer consent from either suffix. Keep the event that collected the alias and the associated account ID, then store the alias type and communication preferences with that record. If a Hide My Email address is deactivated, messages return to the sender. If a Sign in with Apple relay message fails, inspect Apple source registration and authentication before classifying the recipient as invalid.
Accept Apple's new private.icloud.com relay domain
Apple's August 2026 announcement schedules new Sign in with Apple addresses on private.icloud.com later in 2026. Existing privaterelay.appleid.com addresses will keep working. iCloud+ Hide My Email remains on icloud.com.
- Accept both Sign in with Apple domains in account systems and email validation. Check any rules that classify or suppress relay addresses.
- Keep each stored alias unchanged. Do not replace its domain or create a second account solely because a new alias uses a different suffix.
How Apple decides whether to forward the message
For Sign in with Apple aliases, Apple checks whether the outbound email source is registered and whether SPF or DKIM authenticates that source. The domain you register must match the relevant domain in the message path exactly. This registration requirement does not apply to user-generated iCloud+ Hide My Email addresses in the same way.
For SPF, Apple checks the envelope sender domain, also called the MAIL FROM, Return-Path, or bounce domain. That domain must be registered as an email source and pass SPF. For DKIM, Apple checks that the signature passes, includes the From header, and uses a signing domain that exactly matches the registered From domain. Either method can meet the relay requirement, and Apple recommends using both when possible. If your email service provider uses its own Return-Path domain, configure DKIM with your registered From domain. See Apple's authentication requirements.
Sign in with Apple email relay flow with sender registration and SPF or DKIM checks.
Exact source matching matters
Register every sending domain, subdomain, or individual source address you use for Sign in with Apple mail. A message from help.example.com can fail even when example.com is registered, because Apple treats the source as separate.
Illustrative DNS authentication records, replace provider valuesDNS
example.com. TXT "v=spf1 include:_spf.mail.example ~all" s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=BASE64KEY" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
These records are placeholders; use your sender's SPF include and complete DKIM public key. Update your existing SPF record instead of publishing a second one. DMARC reporting helps identify authentication gaps across your sending sources, but it does not confirm Apple source registration or delivery to the user's forwarding inbox.
Setup checklist for Sign in with Apple
The setup is not difficult, but the details are unforgiving. Start by listing every production source that can send to relay users, including product notifications, account mail, support replies, and consented marketing. Map the visible From domain and envelope sender domain for each source, then record its DKIM signing domain separately.
- Inventory: list every app, sending account, support path, and service that can send to relay users.
- Register: in Apple Developer, open Certificates, Identifiers & Profiles > Services > Sign in with Apple for Email Communication > Configure, then add the source in Email Sources.
- Authenticate: pass SPF for the registered envelope sender or DKIM for the registered From domain, and configure both where possible.
- Verify: send through the production path, not a one-off test from a different source.
- Monitor: watch bounces, authentication failures, and source changes after every sending-system update.
Apple permits up to 32 registered email sources for an individual developer enrollment and up to 100 for an organization. Register a domain when you control the senders using that exact domain; register individual addresses when you cannot authorize all senders on it. Keep Apple's relay delivery notifications enabled for the Account Holder and team admins to catch source problems after launch.
Apple Developer Email Sources settings for Sign in with Apple private email relay.
Before live traffic starts, check the domain setup with a domain health check so SPF or DKIM failures and DMARC reporting gaps are visible before the first relay bounce reaches the logs.
Next, send a real message through the same sending path and inspect the result with an email tester. Confirm the headers, envelope sender, DKIM signature, Return-Path, and domain identity that production mail will use.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Keep the send test small. Send to one active relay address issued for your own app and representative direct mailboxes, then confirm receipt at the forwarding inbox. An email tester checks the message sent to its test address; it does not verify Apple relay acceptance.
Marketing and lifecycle email rules
You can send account and lifecycle email to a relay address when the user relationship supports it, including consented marketing. The relay address does not remove the need for unsubscribe handling, preference centers, consent records, or suppression logic. It also does not reveal the user's real mailbox, so do not build workflows that depend on reverse matching it.
Treat the relay address as a deliverable contact method for that account, while storing a stable internal user ID as the identity key. For more detail on suppression decisions, see Hide My Email handling.
Good use
- Source: the user signed into your app or site and Apple shared the relay address with you.
- Consent: the message matches the user relationship, subscription, or account workflow.
- Identity: the app user ID is primary, with the relay address stored as a contact method.
- Compliance: unsubscribe, consent history, and support replies work without needing the real address.
Bad use
- Source: the address came from another company's app or a purchased list.
- Consent: the user did not give your brand permission to use that relay address.
- Identity: the relay address is used as a cross-app identifier or matching key.
- Compliance: preference data is missing, stale, or attached to a different company.
Do not suppress every Apple relay address by default. Blanket suppression creates account and support problems for users who chose a valid privacy feature. Suppress an address when permission is missing or a recipient failure is confirmed, including disabled forwarding. A sender registration or authentication failure calls for pausing affected sends and fixing the source, rather than marking every recipient invalid.
The relay domain does not identify the user's mail app. Mail Privacy Protection can load tracking images in the background, so an open is not proof that the user read the message. Use account activity and conversions when assessing engagement.
Troubleshooting bounces and rejections
When Apple rejects a Sign in with Apple relay message, check the mechanics before reputation. Relay bounces usually come from registration gaps, authentication mismatches, disabled forwarding, or source changes made after setup. A blocklist (blacklist) issue can still affect delivery, but a relay-domain bounce alone does not establish a reputation problem.
|
|
|
|---|---|---|
550 5.1.1 with "unauthorized sender" | Unregistered or unauthorized source | Full SMTP diagnostic and Apple email sources |
SPF fail | SPF authorization failure or unregistered envelope domain | SPF record and exact MAIL FROM domain |
DKIM fail | Signature failure or signing-domain mismatch | Signature verification, signed From header, and d= value |
Reply fails | Changed support source or broken relay reply path | Registered support sender and original reply headers |
Ongoing address-level rejects | Forwarding disabled or address deleted | Alias status and collection source |
Failures after heavy daily traffic | 100-message relay limit, including replies | Combined developer messages and user replies |
Common relay failures and the fastest first check.
Capture the full SMTP response before suppressing the address. A 550 5.1.1 message such as "unauthorized sender" or "relay not allowed" can resemble an invalid-recipient bounce even when the real problem is source registration or authentication. Fix the sender path and retest through production before marking the alias invalid. A successful SMTP handoff to Apple confirms relay acceptance, not arrival in the destination inbox. If Apple accepts the message but the user cannot find it, ask them to check forwarding for your app and the destination inbox's spam folder.
Suped is our DMARC and email authentication platform. Use Suped to review sending sources and SPF or DKIM failures, then compare those findings with the SMTP responses in your sending logs. Check Apple source registration and user forwarding status separately.
- Detection: review sending sources and authentication failures in Suped, then match the affected source to your relay bounce logs.
- Alerts: use authentication notifications to investigate failures after sending-system or DNS changes.
- Hosted SPF: managed SPF and flattening help keep SPF within its DNS lookup limit when several senders share a domain.
- Verification: after fixing the source, retest an active relay alias to confirm forwarding; DMARC reports do not confirm inbox arrival.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
DMARC monitoring shows authentication results reported by participating receivers and helps identify forgotten senders. Compare those results with the specific sender path Apple rejected.
What to store in your app database
Do not use the relay address as the account's permanent identity. Apple can keep a Sign in with Apple relay address stable for a user and developer team, but the app still needs its own durable user record. Store the alias as a contact channel, not as the only account key.
|
|
|
|---|---|---|
User ID | Primary key | Stable app identity |
Apple sub | Apple account link | Login continuity |
Relay email | Contact method | Sendable alias |
Alias type | Routing rule | Correct registration and bounce handling |
Consent | Permission | Send governance |
Status | Forwarding and suppression | Separate recipient status from sender failures |
Source | Origin | Audit trail |
Useful fields for a relay-aware account model.
Process Apple's signed email-disabled and email-enabled notifications to keep forwarding status current. Validate each notification before changing the record, and keep forwarding status separate from marketing consent. Follow Apple's account-change guidance.
Support teams should show the alias plainly as the user's chosen contact address. Ask for the real address only when a product requirement cannot be completed through the alias, such as a separate recovery flow. Explain why the direct address is needed and keep the alias usable for users who prefer it.
Segment relay users by alias type and collection source. That makes Apple-only bounces, source-specific failures, and permission problems easier to diagnose. For adjacent Apple-domain troubleshooting, see Apple bounce causes.
Views from the trenches
Best practices
Register every sending subdomain before launch, then test the exact production headers.
Use app account IDs as identity keys, with relay addresses stored as contact fields only.
Separate relay bounces in reporting so Apple-specific setup failures are visible early.
Keep SPF and DKIM ownership clear when support and marketing use different tools.
Common pitfalls
Assuming a relay address can be shared across brands without clear user permission.
Registering the header From domain but missing the envelope sender domain Apple checks.
Testing with a manual inbox message instead of the real production mail path headers.
Suppressing all relay users and breaking valid account notifications for real users.
Expert tips
Audit source domains after every ESP migration, DNS change, and support tool change.
Track Apple relay failures separately from ordinary iCloud inbox placement issues.
Use both SPF and DKIM where possible so one path does not carry the whole setup.
Keep consent history close to the relay address so targeting decisions stay clear.
Marketer view
Marketer from Email Geeks says relay addresses work when they come from active app users and the sender owns the app relationship.
2023-02-14 - Email Geeks
Marketer view
Marketer from Email Geeks says private relay addresses need registered sending domains, or Apple will reject the messages.
2023-02-14 - Email Geeks
