Why are emails sent through Apple Private Relay going to spam?
Updated on 23 Oct 2026: We corrected Apple's relay domain rollout and clarified authentication checks, missing mail diagnosis, and bounce handling.
Emails sent through Apple's private email relay can go to spam because forwarding changes the delivery route and can change authentication and message headers. With Sign in with Apple or iCloud+ Hide My Email, Apple filters and forwards messages to the user's real mailbox. If that mailbox is Gmail, Gmail can filter the forwarded version differently even when the same campaign lands in the inbox when sent straight to the real address. Relay use alone does not prove that shared reputation caused the problem.
Relaxing your DMARC policy is not a general fix. If the delivered relay copy shows dkim=pass, spf=pass, and dmarc=pass for Apple-controlled domains, those results describe the delivered identities. They do not prove your original authentication survived forwarding or explain the spam decision. Compare the complete headers before changing DNS or attributing the result to relay reputation.
- Sign in with Apple: The user shares a relay address tied to an app account. Existing aliases use @privaterelay.appleid.com; Apple has announced @private.icloud.com for newly generated aliases later in 2026. The sending source must be registered with Apple.
- Hide My Email: The user creates a masked address for a site or service through iCloud+. These aliases will remain on @icloud.com. Apple Developer source registration applies to Sign in with Apple, not every iCloud+ Hide My Email alias.
- iCloud Private Relay: This is web browsing privacy, not the email forwarding path that changes message handling.
- Related handling: The practical differences are covered in Private Relay and Hide My Email.
Prepare for Apple's revised relay domain rollout
Apple's revised domain announcement schedules @private.icloud.com for new Sign in with Apple aliases later in 2026. iCloud+ Hide My Email will keep @icloud.com, and existing @privaterelay.appleid.com aliases will continue to work. Prepare account validation and routing for the announced change without treating the rollout as complete.
- Email validation: Accept private.icloud.com alongside privaterelay.appleid.com for Sign in with Apple. Continue accepting icloud.com addresses, including iCloud+ Hide My Email aliases.
- Routing rules: Include the announced domain in logic that routes Apple relay mail or separates known relay users for testing.
- Suppression rules: Do not suppress the new domain because it is unfamiliar, and do not remove working legacy aliases.
- Reporting: Group known Apple relay aliases into one cohort, but retain a domain-level breakout while placement and bounce patterns settle. Do not classify every @icloud.com mailbox as a relay alias.
Test signup, sign-in, password reset, verification, and account recovery flows with existing aliases, then with new-domain aliases when available. A relay address can be a durable account identifier, so rewriting stored addresses or forcing users to replace them can break access even though Apple still forwards the original alias.
Why the same email can land differently
A direct send and an Apple relay send can contain the same visible creative, subject line, links, and offer, but they are not identical at the transport and authentication layers. The direct message carries your return path, DKIM signature, and sending IP history. The relay copy arrives through Apple's infrastructure and can have a rewritten return path, an additional DKIM signature, or a changed visible From address. Check which original identities remain rather than assuming Apple replaces every authentication signal.
That matters because mailbox filters do not only score visible content. They use authentication identity, sending path, historical engagement, complaint behavior, missing or changed headers, link reputation, and receiver-specific learning. Shared relay infrastructure is one possible influence, but an Apple DKIM pass does not reveal the receiver's reputation weighting or establish that other relay senders caused the spam result.
Forwarding can break SPF for the original envelope domain because the final receiver sees the forwarding server's IP. Your original DKIM signature can survive if the signed content and headers remain intact. DMARC needs a passing SPF or DKIM identity that meets its domain-matching rules for the delivered From address, as defined in the DMARC standard.
Illustrative rewritten relay identity, not captured Apple headerstext
Authentication-Results: mx.destination.example; dkim=pass header.d=relay.example; spf=pass smtp.mailfrom=bounces.relay.example; dmarc=pass header.from=relay.example From: Example sender <sender@relay.example> Return-Path: <bounce@bounces.relay.example>
The .example domains above are placeholders. Read the final receiver's trusted Authentication-Results first. ARC-Authentication-Results records an earlier hop's assessment; it is not a substitute for the final receiver's checks. The ARC standard explains how forwarding assessments are carried between mail systems.
Authentication pass is not inbox placement
A relay message can pass SPF, DKIM, and DMARC and still land in spam. Passing authentication records successful checks for the specified identities. It does not prove the receiver trusts the message enough for inbox placement.
- Passed auth: The relay copy can authenticate through Apple, a preserved original signature, or both. Inspect each result.
- Spam placement: The receiver can still filter on reputation, content, or recipient-level behavior.
- ARC context: ARC can help the receiver understand forwarding when it trusts the sealing systems, but it does not guarantee inbox placement.
- Wrong fix: Changing DMARC from reject to none does not solve shared relay reputation.
Apple private email relay delivery with changed authentication and final mailbox spam filtering.
What to check first
Start with the headers from both versions using an account you control or a recipient who agrees to test: one sent directly to the real mailbox and one sent through its Apple relay address. The message body should be the same, the send time should be close, and the recipient should interact with both test paths as evenly as possible. Without that control, engagement and timing can distort the result.
The useful evidence goes beyond whether SPF, DKIM, and DMARC pass. Identify the domain attached to each result, check all DKIM signatures, and compare the delivered From address with the original. An Apple return path confirms a relay identity, but it does not prove that the mailbox ignored your original domain or that shared reputation caused filtering.
- Final mailbox: With a consenting test account, confirm whether the destination is Gmail, iCloud, Outlook, or another mailbox. The alias domain alone does not reveal it.
- Failure type: Separate spam placement from a source bounce, disabled forwarding, a deleted alias, the Sign in with Apple 100-message daily limit, or temporary non-delivery.
- Header owner: Look at the final Authentication-Results, every DKIM domain, return path, ARC results, and Received chain.
- Relay copy: Compare whether Apple has rewritten the visible From, envelope sender, or forwarding path.
- Unsubscribe signal: Check whether List-Unsubscribe and List-Unsubscribe-Post survived forwarding and whether the unsubscribe action still works for the alias.
- Apple setup: For Sign in with Apple, verify registered source domains, subdomains, and any individually registered sender addresses in the developer account.
- Placement pattern: Measure whether the problem happens only for relay users or across the broader list.
|
|
|
|---|---|---|
Return path | Your configured bounce address | Check for a rewritten bounce address |
DKIM | Your sending domain or provider | Check original and Apple signatures |
SPF | Checks your sending IP and envelope domain | Checks Apple's IP and the delivered envelope domain |
DMARC | Result for the original From domain | Result for the delivered From domain |
Unsubscribe | Confirm headers and action work | Check preservation and alias handling |
Placement | Record direct mailbox result | Record forwarded mailbox result |
Comparison points to inspect in actual direct and relayed message headers.
Use Suped's email tester for a direct authentication baseline, then compare it with the raw headers captured at the test user's final mailbox. Sending directly to the tester does not reproduce Apple forwarding or predict that mailbox's inbox placement.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the direct version passes under your domain and the relay version passes under Apple's domain, that alone does not identify a missing SPF include on your main sending domain. Apple still checks Sign in with Apple sources before accepting relay mail, so source authentication matters at the first hop. Do not add Apple's relay infrastructure to your SPF record just because Apple forwards your messages.
The important distinction is where the failure occurs. If Apple rejects or bounces the message, inspect the full diagnostic before changing registration, authentication, or alias handling. If a forwarded copy is present in Gmail spam, investigate filtering at the final mailbox. A sending platform's delivery event at Apple does not establish that the final mailbox received the message.
Apple setup checks
For Sign in with Apple private email relay, register your outbound source domains or individual sender addresses in the Apple Developer account. Apple relay setup requires SPF records for registered domains and SPF and/or DKIM authentication for outbound messages; Apple recommends both. These registration requirements do not apply to every user-created iCloud+ Hide My Email alias.
Exact matching matters. For SPF, the registered domain must exactly match the envelope sender domain, also called MAIL FROM, Return-Path, or bounce domain, and SPF must pass. For DKIM, the d= domain must exactly match the registered header From domain, the signature must pass, and it must cover the From header. If your provider uses its own envelope domain, configure DKIM with your registered From domain.
Apple also limits registered email sources: individual developer accounts can register up to 32 sources, and organization accounts can register up to 100. Teams with many brands, regions, or product subdomains should plan source registration before launch instead of discovering the limit after relay users start bouncing.
Each Sign in with Apple private relay address has a daily limit of 100 messages, counting developer sends to the alias and user replies. Reaching that limit is a per-address non-delivery issue, not proof of poor inbox placement or a domain-wide reputation problem. Apple's relay documentation describes this limit.
This is why a spam folder report is not proof that the Apple Developer setup is wrong. A source rejection stops that delivery attempt before forwarding. A relay copy found in the final mailbox proves that Apple forwarded that particular message; check its headers to assess authentication and placement.
Apple Developer private email relay setup with source domains and SPF status.
Illustrative source-domain records, replace with provider-supplied valuesdns
example.com. 3600 IN TXT "v=spf1 include:send.example.net -all" bounce.example.com. 3600 IN TXT "v=spf1 include:send.example.net -all" selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=KEY"
Do not skip subdomains
If you send from a subdomain, register that source too. Registering only the organizational domain does not satisfy an exact-match check for a different envelope sender or From subdomain. Register a custom Return-Path domain when relying on its SPF result.
- Marketing mail: Register the sending source and make sure SPF or DKIM passes for it. Domain registration does not require listing every address within that registered domain.
- Transactional mail: Register the transactional source separately when it uses a different domain.
- Individual senders: Register exact communication email addresses when domain ownership is not available.
- Failure notices: Keep Apple relay notifications enabled for Account Holders and Admins so source bounces do not sit unseen.
Diagnose missing mail before suppressing an alias
A successful SMTP handoff to Apple confirms acceptance by that server, not inbox placement at the hidden destination. If no copy is available, investigate missing delivery separately from a confirmed spam-folder result.
- Read the full bounce: Keep the SMTP reply text, rejecting server, Message-ID, and timestamp. A 550 5.1.1 response containing "unauthorized sender" points to source authorization, so do not automatically classify it as a deleted recipient.
- Check recipient settings: Ask the user to confirm that forwarding is active and the Forward To destination is current, then check that mailbox's junk folder. Use the app's Sign in with Apple settings or the separate iCloud+ Hide My Email settings as appropriate.
- Retry the right failures: Use queued retries with backoff for temporary 4xx responses. For a 5xx rejection, resolve its stated cause before resending. A confirmed daily-limit failure calls for lower volume and a later retry, not immediate permanent suppression.
- Escalate with evidence: For unresolved Sign in with Apple delivery failures, collect the primary App ID and Services ID, affected alias, raw headers when available, timestamps, and SMTP diagnostics. Submit sensitive account details through Apple's private Feedback Assistant workflow.
Follow Apple's relay troubleshooting instructions for escalation and Apple's forwarding settings instructions for recipient checks. The distinction between temporary and permanent SMTP replies is defined in the SMTP standard.
How to test whether forwarding changes placement
Use a paired test. Send the same campaign to a consenting recipient's direct mailbox and their relay address. Capture the raw source from both delivered messages. Keep the creative, send time, audience behavior, and sending system as close as possible. Repeat with multiple test accounts and comparable sends, since duplicate-message handling or one recipient's history can distort a single pair.
If direct copies consistently reach the inbox while relay copies reach spam, the evidence points to a delivery-path difference. That remains an inference, not proof of a shared Apple reputation problem. If both versions degrade, investigate your source authentication, list quality, content, and sending infrastructure alongside destination-specific filtering.
Direct versus Apple private email relay testing with header checks and inbox placement comparison.
Evidence points to a relay-path difference
- Direct copies: The same content lands in the inbox when sent straight to the real address.
- Relay copies: The forwarded copy lands in spam across repeated controlled tests.
- Auth owner: Inspect Apple-controlled identities alongside any preserved original signature; the headers identify the path, not the filtering cause.
- Header change: The return path, Received chain, or unsubscribe headers differ materially.
Evidence calls for source or broader checks
- Both paths: Direct and relay copies both show poor inbox placement.
- Apple bounce: Apple rejects the message before it reaches the final mailbox; read the diagnostic to identify the cause.
- Source gaps: Your required Sign in with Apple source domain, subdomain, or individual sender is not registered.
- Broader issue: Non-relay recipients at the same mailbox provider also move to spam.
Before attributing the problem to forwarding, check source health with Suped's domain health checker and use DMARC monitoring for reported authentication evidence. Suped's blocklist monitoring can identify blocklist (blacklist) events affecting direct sending, but it does not reveal a mailbox provider's internal filtering decisions.
What you can fix
You cannot directly control Apple's relay IP reputation, Apple's DKIM identity, or Gmail's filtering decisions for a forwarded copy. You can control your source authentication and the messages recipients receive. Keep the sending relationship clear, correct demonstrated source issues, and offer optional recovery choices for critical account mail.
- Register sources: For Sign in with Apple, register every sending domain and subdomain, or individual source address where appropriate.
- Preserve headers: Include valid List-Unsubscribe and one-click unsubscribe headers on subscription mail, then check the forwarded copy. Keep the unsubscribe action usable without knowing the real address.
- Respect consent: A Sign in with Apple account or purchase is not proof of a newsletter subscription. Send marketing only when it matches the permission the user gave, and honor opt-outs for the alias.
- Segment relay users: Measure known Apple relay users separately instead of blending them into global engagement metrics.
- Separate bounces: Treat deleted aliases, disabled forwarding, Sign in with Apple daily-limit failures, and source rejection differently from spam placement.
- Keep recognition: Use a stable visible From name and explain at signup which account messages users should expect.
- Set expectations: During signup, ask Apple relay users to check junk and move wanted mail to the inbox.
- Avoid policy panic: Do not weaken DMARC just because Apple-authenticated forwarded mail lands in spam.
- Offer choice: For critical notifications, offer an optional, verified alternative contact address. Respect the user's choice to keep their real address private.
Response priority for relay delivery problems
Use the observed failure to decide whether to fix source setup, investigate placement, or escalate.
Fix now
Source failure
Apple reports an unauthorized source or failed source authentication.
Investigate
Path split
Relay copies go to spam while direct copies land in the inbox.
Monitor
Mixed data
Placement varies by mailbox provider or by recipient engagement.
Escalate
Unresolved relay failure
Repeated relay-only failures persist after source and forwarding checks.
Do not suppress every Apple relay address because a test reached spam. Suppress confirmed permanent recipient failures or opt-outs, and correct source authorization errors before reassessing affected aliases. A useful starting point is handling relay addresses with separate monitoring, targeted prompts, and an optional alternative address.
Also separate spam placement from non-delivery. If a user disables forwarding, confirm their intent before requesting another address. If an alias reaches its daily limit, reduce traffic and retry later. A content change or DMARC change does not fix those conditions.
Limits of sender-side fixes
When Apple adds authentication or rewrites the sender identity, the final mailbox receives different signals. Your original domain can still contribute through a preserved signature, links, content, or recipient history. Headers show what changed; they do not expose Apple's or the destination provider's internal reputation scores.
Where Suped fits
Suped's product provides DMARC reporting and source-level SPF and DKIM results to help investigate authentication failures before relay testing. Use source breakdowns and alerts to identify a newly introduced sender or a change in authentication results.
Compare that source evidence with raw headers from the direct and forwarded test messages. DMARC reports do not show inbox versus spam placement. If Apple rewrites the From domain, the final receiver's DMARC report for that copy can go to the rewritten domain's reporting address instead of yours, so Suped's data for your domain does not provide complete visibility into every forwarded copy.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Useful Suped workflow
- Check source health: Confirm your sending domains pass SPF, DKIM, and DMARC before relay testing.
- Compare sources: Review authentication results reported for your domain, then inspect the final relay headers separately.
- Watch changes: Use alerts to investigate authentication failures or newly reported sources.
- Document proof: Keep raw headers and placement observations alongside source reports before asking Apple or a mailbox provider to investigate.
Views from the trenches
Best practices
Compare direct and relay headers before changing DMARC, DNS, or sender configuration.
Segment relay users so direct-domain placement metrics do not hide relay-only problems.
Register each Sign in with Apple source domain used for account communications and replies.
Ask relay users to check junk folders for critical mail and move wanted mail to inbox.
Common pitfalls
Treating Apple-authenticated DMARC pass as proof that inbox placement must be good.
Changing a reject policy to none without evidence that DMARC caused the placement issue.
Testing different send times or content, then blaming Apple for an uncontrolled result.
Missing List-Unsubscribe changes after forwarding and ignoring header-level differences.
Expert tips
An Apple DKIM pass identifies a signer; it does not prove why the final mailbox chose spam.
A copy in the final mailbox proves forwarding; Apple acceptance alone does not prove arrival.
Look for repeated relay-only spam placement before suppressing relay addresses broadly.
Keep examples with raw headers so support teams can inspect the exact forwarded copy.
Expert view
Expert from Email Geeks describes cases where Apple relay replaced the authenticated identity, changing the signals available to the receiver. Check the actual headers before applying that explanation to another message.
2022-04-25 - Email Geeks
Marketer view
Marketer from Email Geeks says repeated tests showed direct messages reaching the inbox while Sign in with Apple relay copies went to spam.
2022-05-06 - Email Geeks
