Can I email users who have Apple's private relay email addresses?
Michael Ko
Co-founder & CEO, Suped
Published 1 Jun 2025
Updated 28 May 2026
9 min read
Summarize with
Yes, you can email users who have Apple's private relay email addresses, but only when the address was shared with your app or website and your sending source is registered and authenticated with Apple. If the address came from a purchased audience, a partner export, or an app you do not own, treat it as unreachable. Apple designed the relay address as a permissioned communication channel, not a normal transferable email address.
A private relay address is an alias. It forwards to one of the user's verified Apple Account email addresses, but you never see that real mailbox. The user can disable forwarding, Apple can reject messages from unregistered senders, and each relay address has a daily message limit. Apple's relay documentation explains the basic forwarding model and the sender controls.
- Yes: send if the user gave the relay address to your app, your source is registered with Apple, and SPF or DKIM passes.
- No: do not send if you received the relay address outside that user relationship or cannot prove permission.
- Expect bounces: failed registration, failed authentication, user opt-out, or relay limits can stop 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
I use one simple test before sending to a relay address: did the user share this address with this app, under this developer team, for this communication path? If the answer is yes, the address is usable once the domain setup is correct. If the answer is no, the address is not a workaround for reaching the user's hidden mailbox.
The common address domain for Sign in with Apple is privaterelay.appleid.com. Apple also talks about private relay addresses that end in icloud.com, depending on how the user created the alias. In both cases, the important point is the same: the alias belongs to the user and the Apple account controls forwarding.
Do not treat relay addresses as list assets
A relay address is valid because of a specific app-user relationship. If another company shares it with you, the safest operational answer is to suppress it. Even if a message appears technically sendable, the consent and Apple registration model are wrong.
|
|
|
|---|---|---|
User chose Sign in with Apple for your app | Yes | Register sender and pass auth |
User generated Hide My Email for your site | Usually | Respect consent and replies |
Address came from another app | No | No direct relationship |
Purchased or scraped audience | No | Permission is missing |
Support reply to an app user | Yes | Use registered support source |
Use this table to decide whether the address belongs in a sendable audience.
That distinction matters most for marketing teams. A relay address is not automatically bad data. It is bad data when it is detached from the app event, account record, or consent trail that created it.
How Apple decides whether to forward the message
Apple does not forward every message sent to a private relay address. It checks whether the source is allowed and whether the message authentication proves that source. The practical requirement is exact domain control: the domain you register, the domain you use in the message path, and the domain in SPF or DKIM must match Apple's expectations.
For SPF, Apple checks the envelope sender domain, also called the Return-Path or bounce domain. That domain must be registered as an email source and pass SPF. For DKIM, Apple checks that the DKIM signature passes, includes the From address, and has a signing domain that matches the registered From domain. Apple recommends using both SPF and DKIM when possible.
Flowchart showing Apple Private Relay checks before forwarding email.
Exact source matching matters
Register every sending domain, subdomain, or individual source address you use. A message from help.example.com can fail even when example.com is registered, because Apple treats the source as separate.
Example DNS authentication recordsDNS
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"
DMARC is not the Apple relay registration step, but it is how I keep the broader sending system honest. If the same campaign domain has SPF or DKIM drift, that failure can affect Apple relay delivery, Gmail inboxing, corporate filters, and security controls at the same time.
The setup checklist I use
The setup is not difficult, but the details are unforgiving. I start by listing every source that can send to these users: product notifications, authentication mail, billing mail, marketing automation, support replies, password resets, and transactional alerts. Then I map each source to its visible From domain, envelope sender domain, and DKIM signing domain.
- Inventory: list every app, ESP account, support tool, and service that can send to relay users.
- Register: add the sending domains, subdomains, or individual email addresses in Apple Developer.
- Authenticate: publish SPF for the envelope sender and DKIM for the header From domain.
- Verify: send through the production path, not a one-off test from a different tool.
- Monitor: watch bounces, authentication failures, and source changes after every vendor update.
Apple Developer account screen for configuring Sign in with Apple email sources.
Before I send live traffic, I check the domain setup with a domain health check so SPF, DKIM, and DMARC failures are visible before the first relay bounce hits the logs.
After that, I send a real message through the same sending path and inspect the result with an email tester. The point is not only to check the content. It is to confirm the headers, envelope sender, DKIM signature, Return-Path, and domain identity you will use in production.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
I also keep the send test small. One relay test address, one normal iCloud address, and one non-Apple mailbox are enough to catch the most common routing mistakes without creating unnecessary volume.
Marketing and lifecycle email rules
You can send lifecycle, transactional, and marketing email to a relay address when the user relationship supports it. The relay address does not remove the need for consent, unsubscribe handling, preference centers, or suppression logic. It also does not give you the user's real mailbox, so do not build workflows that depend on revealing or reverse matching it.
The best operational pattern is to treat the relay address as a deliverable contact method for that account, while storing a stable internal user ID as the real 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 a third-party export, audience sync, or list purchase.
- 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.
I do not recommend suppressing every Apple relay address by default. That creates account and support problems for users who chose a valid privacy feature. Suppress addresses when permission is missing, forwarding has been disabled, hard bounces repeat, or the relay address is detached from the app account that created it.
Troubleshooting bounces and rejections
When Apple rejects a relay message, I start with the mechanics before blaming reputation. Relay bounces usually come from registration gaps, authentication mismatches, disabled forwarding, or source changes that happened after the original setup. A blocklist or blacklist issue can still hurt Apple-domain delivery, but relay-specific failures often have a cleaner cause.
|
|
|
|---|---|---|
Immediate bounce | Unregistered source | Apple email sources |
SPF fail | Return-Path mismatch | Envelope domain |
DKIM fail | Wrong signing domain | d= value |
Reply fails | Changed sender | Original From |
Ongoing rejects | Forwarding disabled | Account status |
Common relay failures and the fastest first check.
Suped, our DMARC and email authentication platform, is usually the best overall fit for teams that need to keep Apple relay sending stable because it connects the relay requirement to the systems that break it: SPF, DKIM, DMARC, sending-source drift, and blocklist (blacklist) signals.
- Detection: Suped flags new sources, authentication failures, and domain mismatches before they become recurring bounces.
- Alerts: real-time notifications help catch sudden relay-impacting failures after vendor or DNS changes.
- Hosted SPF: managed SPF and flattening reduce DNS lookup risk when several senders share a domain.
- Visibility: DMARC, SPF, DKIM, blocklist monitoring, and deliverability checks sit in one workflow.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
This is also where DMARC monitoring becomes useful beyond compliance. It shows whether the sources you think are authorized are actually sending authenticated mail, and it exposes lookalike or forgotten systems using the same domain.
Relay bounce rate bands
These are practical operating bands I use when diagnosing Apple relay delivery after setup.
Healthy
0-1%
Small normal noise, usually individual user settings or stale accounts.
Investigate
1-5%
Check source registration, SPF, DKIM, and recent sender changes.
Stop and fix
>5%
Pause relay sends until authentication and source registration are corrected.
Segmented
Source only
A spike in one source points to a tool-specific setup issue.
What to store in your app database
The biggest product mistake I see is using the relay address as the account's permanent identity. Apple can keep the relay address stable for a user and developer team, but your app still needs its own durable user record. Store the relay address as a contact channel, not as the only account key.
|
|
|
|---|---|---|
User ID | Primary key | Stable app identity |
Apple sub | Apple link | Login continuity |
Relay email | Contact method | Sendable alias |
Consent | Permission | Send governance |
Status | Suppression | Bounce handling |
Source | Origin | Audit trail |
Useful fields for a relay-aware account model.
For support teams, I prefer showing the relay address plainly as the user's chosen contact address. Do not ask for the real address unless there is a product reason, such as account recovery that cannot be completed through the relay. If you do ask, explain why and keep the relay address usable for users who prefer it.
For deliverability teams, segment relay users as their own group. That makes it easier to spot Apple-only bounces, source-specific failures, and content issues that affect privacy aliases differently than direct addresses. 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 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 from Email Geeks says private relay addresses need registered sending domains, or Apple will reject the messages.
2023-02-14 - Email Geeks
The practical answer
You can email Apple Private Relay users when the address came through your app or website, the user relationship is legitimate, and your sending source is registered and authenticated. You cannot use a relay address as a general-purpose way to reach someone whose real email address is hidden from you.
The operational fix is straightforward: register every source, pass SPF or DKIM with exact domain matching, test the real production path, and monitor the authentication system after launch. If relay bounces start, check source registration and authentication first, then look at reputation, blocklist or blacklist signals, and user-level forwarding status.
