What causes email deliverability issues for Gmail users with iCloud Private Relay?
Updated on 12 Oct 2026: We clarified Apple's email relay rules, corrected the Gmail requirements, and added checks for relay bounces and address verification.
The usual causes are an unregistered Sign in with Apple sending source, a deactivated alias, broken authentication, Gmail filtering after forwarding, sender DNS gaps, and recipient-side routing. When a Gmail user signs up with an Apple private relay address, your mail does not go straight to Gmail. It goes to Apple's relay first, then Apple forwards it to the user's real Gmail inbox. That extra hop creates two separate delivery decisions.
iCloud Private Relay protects browsing traffic; it does not forward email to Gmail. Apple's private email relay is used by Hide My Email and Sign in with Apple. Sign in with Apple aliases ending in @privaterelay.appleid.com accept mail only from the app's registered sending sources. iCloud+ Hide My Email addresses created separately use @icloud.com without requiring developer registration by senders. Confirm how the alias was created before applying the registration checklist.
Normal bounce rates are not proof that these messages reached the inbox. A message can be accepted by Apple, forwarded toward Gmail, then filtered by Gmail into spam, held by Google Workspace quarantine, routed by a user filter, or delayed in a place the sender cannot see. A rejection during the original SMTP delivery appears in the sender's logs. To detect later forwarding failures, check Apple-generated delivery status notifications at the return-path address as well as provider queues and bounce handling.
Why Apple relay messages miss Gmail inboxes
Gmail delivery issues for users behind Apple relay come from Apple's source checks and spam filtering before forwarding or Gmail's final filtering decision. For Sign in with Apple, mail from an unregistered source bounces at Apple before Gmail receives it. A message Apple accepts can still reach Gmail with different authentication, forwarding, and recipient-engagement signals than a direct copy.
- Relay registration: Sign in with Apple relay addresses accept mail only from sources registered by the app's developer team that pass Apple's SPF or DKIM checks.
- Alias status: A user can deactivate the private address, stop forwarding, or change the destination, which causes a rejection or delivery somewhere other than the Gmail inbox being checked.
- Forwarding effects: Forwarding can break SPF for the original return-path domain. A surviving DKIM signature that matches the visible From domain preserves the original sender's authenticated identity.
- Gmail filtering: Gmail can place relay-forwarded mail differently than the same mail sent directly to the same Gmail account.
- Sender foundation: Authentication, TLS, forward and reverse DNS, complaint rates, and message format still affect acceptance and placement.
- User routing: Personal filters, Google Workspace rules, blocked senders, and spam folder behavior can look like silent loss from the sender side.
The sender is not always the only problem
A sender with strong direct Gmail delivery can still have poor delivery to Gmail users who signed up through Apple's relay. That does not clear the sender from review, but it changes the diagnostic path. First prove whether direct Gmail and Apple-relayed Gmail behave differently under the same content, sending IP, DKIM selector, and message stream.
The relay path shows a sender, Apple relay, Gmail filtering, and the user mailbox.
Why Gmail treats relayed mail differently
A direct Gmail delivery test and a relay delivery test are not the same test. Direct mail reaches Gmail from your mail provider. Relayed mail reaches Gmail after Apple has accepted and forwarded it. Gmail checks the forwarded copy using the connecting relay, any valid DKIM signature, headers added during forwarding, the final recipient's previous engagement, and its own abuse signals. Gmail does not automatically trust an earlier authentication result just because another system forwarded the message.
This is why the symptom can look inconsistent. The sender can have clean direct delivery to Gmail, normal complaint rates, and no visible bounce spike, yet a subset of Apple-relayed Gmail users reports missing mail. In that case, look for a path-specific problem before concluding that the sender has a broad reputation failure.
Direct Gmail path
- Connection: Gmail sees the sender's sending IP and mail stream directly.
- Authentication: Gmail evaluates SPF, DKIM, and DMARC on the original delivery.
- Diagnosis: Logs, Gmail placement tests, and authentication headers are easier to compare.
Apple relay path
- Connection: Gmail receives a forwarded message from Apple's relay infrastructure.
- Authentication: Gmail checks SPF against the relay connection and return-path domain; DKIM can retain the original sender's identity.
- Diagnosis: The sender cannot directly see Gmail's final folder-placement decision.
If the same message reaches the inbox when sent directly to Gmail but lands in spam after Apple forwards it, the relay path is the differentiator. For a deeper relay-specific spam discussion, see Apple relay spam.
Authentication and DNS causes
Authentication is the first place to check because forwarding exposes weak setups. For Sign in with Apple, Apple checks the registered source and SPF or DKIM at intake. Gmail then checks SPF using Apple's connecting IP and the forwarded envelope sender. If Apple preserves the original envelope sender, SPF can fail; if the relay rewrites it, SPF can pass for the relay domain without authenticating your visible From domain. A valid DKIM signature can survive unchanged signed content and allow DMARC to pass through DKIM domain matching. Google's forwarding guidance recommends preserving DKIM signatures.
Gmail requires the connecting sending IP to have valid forward and reverse DNS, with the PTR hostname resolving back to that IP. Your provider controls the original sending IP; Apple controls the relay IP Gmail sees. Broken sender A, AAAA, or PTR records affect the original hop. Tracking CNAME records matter for link availability and reputation rather than SMTP routing. MX records support replies and bounces, while Gmail requires TLS. Replace the placeholders below and arrange PTR records with the sending IP owner.
Illustrative DNS baseline, replace placeholdersDNS
example.com. 3600 IN MX 10 mail.example.com. mail.example.com. 3600 IN A 203.0.113.10 example.com. 3600 IN TXT "v=spf1 include:spf.sender.example -all" selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY" ) _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
For a fast DNS and authentication pass, run a domain health check before changing content or suppressing users. Confirm that the sender's base identity and sending infrastructure are healthy before isolating the relay path.
|
|
|
|---|---|---|
No bounce | No rejection reported to the sender | Queues, bounce handling, seed tests, and headers |
Apple rejects original SMTP delivery | Relay intake | Registered source, SPF/DKIM, and alias status |
Gmail rejection reported by Apple | Forwarding handoff | Downstream SMTP code and delivery status notification |
Gmail spam | Final filtering | Compare direct and relayed headers and placement |
DNS warning | Sender infrastructure | Fix the affected record on the correct hop |
DMARC fail | Authentication failure or domain mismatch | Inspect SPF, DKIM, and any ARC results at Gmail |
Use the symptom to choose the next check.
Check Sign in with Apple sender registration
For addresses ending in @privaterelay.appleid.com that were created with Sign in with Apple, Apple restricts which sources can send through the alias. Register every outbound email domain, subdomain, or individual source address in the developer team account for the app or website that created the alias under Services and Sign in with Apple for Email Communication. An unregistered source produces a bounce before Gmail can filter the message.
Apple permits an SPF or DKIM authentication path and recommends both. For SPF, the registered domain must exactly match the envelope sender domain and pass SPF. For DKIM, the signature must pass, cover the From header, and use a d= domain that exactly matches the registered header From domain. If a mail provider uses its own return-path domain, the DKIM path is normally the practical way to meet Apple's check. Apple's exact matching requirements are separate from DMARC's strict or relaxed domain matching. Keep undelivered-email notifications enabled for the Account Holder and team admins. Follow Apple's relay configuration requirements.
Sign in with Apple acceptance checklist
- Read the bounce: Capture Apple's SMTP status, diagnostic text, timestamp, and message ID.
- Check the source: Confirm registration in the correct developer team and test SPF or DKIM on a real message; the portal's SPF status does not prove DKIM passes.
- Check the alias: Ask the user to confirm that the private address remains active and forwards to the Gmail address being searched.
- Check volume: A Sign in with Apple private relay address has a daily limit of 100 messages, including replies.
- Retest once: After correcting the cause, send one transactional message and record Apple's response before testing Gmail placement.
Interpret relay bounces and verification results
An email verification result is not a delivery test. Syntax and MX checks confirm address structure and a mail route, not an active alias or Gmail inbox placement. A probe using an unregistered source cannot establish that a Sign in with Apple alias is invalid.
- An SMTP 4xx response is temporary. Let your provider retry on its normal schedule and inspect queue status before suppressing the address.
- An SMTP 5xx response is a permanent rejection of that attempt. Read the diagnostic to distinguish source or authentication errors from an inactive alias before deciding what to fix.
- 'Risky' or 'catch-all' labels describe the verification system's result. Keep those addresses for review until real delivery evidence confirms a problem.
- A final 250 response after message submission confirms acceptance by that server. If Apple issued it, Gmail placement still needs a mailbox test.
The SMTP response definitions distinguish temporary failures from permanent rejections. Correct sender-side failures before resending a rejected message or treating an alias as unusable.
How to test the relay path
The cleanest test uses two recipients controlled by the same person: a normal Gmail address and an Apple relay address that forwards to that same Gmail account. Send two separate messages with the same content from the same stream. Do not change the subject, links, template, DKIM selector, sending IP, or envelope setup between tests. Generate a separate Message-ID before DKIM signing for each copy so both deliveries can be tracked independently. Then use Gmail's search operators with in:anywhere from:sender@example.com to include Spam and Trash; check categories and any Google Workspace admin quarantine.
Collect full headers from any delivered relay copy using Gmail's Show original. Inspect the Authentication-Results added by Gmail, including SPF, DKIM, and DMARC. ARC (Authenticated Received Chain) headers, if present, carry earlier authentication results but do not prove Gmail trusted them or guarantee inbox placement. If no copy arrives, use the Apple bounce, sender logs, and repeated seed tests across more than one Gmail account.
A Gmail screenshot showing direct delivery in Inbox and relay delivery in Spam.
A practical test sequence
- Baseline: Send to a normal Gmail address and record placement.
- Relay copy: Send the same message to an Apple relay address that forwards to Gmail.
- Mailbox search: Use in:anywhere to include Spam and Trash, then check categories, filters, and any Workspace quarantine.
- Header review: Compare authentication results between direct and relayed copies.
- Repeat: Run the same test across different Gmail accounts before changing policy.
Reduce Apple relay delivery failures
Do not suppress every Apple relay address by default. Some users rely on those addresses for account access and password resets. Prove the failure stage, register every Sign in with Apple sending source, harden authentication, reduce unexpected sending patterns, and give users a backup route for critical messages.
Start with Suped's real-message email test to inspect actual authentication, DNS, TLS, and blocklist (blacklist) results. Test Gmail placement separately with the seed accounts above. Then check DMARC reports over the same window. If the issue only occurs for Apple-relayed Gmail users, keep the remediation focused on that path.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Meet Gmail's sender requirements for personal Gmail accounts. All senders need SPF or DKIM, TLS, valid forward and reverse DNS, and correctly formatted mail. Google recommends a user-reported spam rate below 0.1%, never reaching 0.3%. Google classifies senders close to 5,000 messages or more in 24 hours as bulk senders, counting the primary domain and its subdomains together. Bulk senders need SPF, DKIM, and DMARC, with p=none accepted. Their marketing and subscribed messages need one-click unsubscribe and a visible unsubscribe link; password resets and other transactional messages are exempt from that unsubscribe requirement. Check Google's sender guidelines FAQ.
Use stable DKIM signing, a clean From domain, consistent return-path handling, and a verified tracking domain. The message should match what the user expected when creating the relay address. Check blocklist (blacklist) signals for the sending domain and IPs because reputation trouble can combine with a relay-specific problem. Suped's blocklist monitoring tracks listing changes alongside authentication results for those sources.
- Keep DKIM stable: Use a signing domain that matches the visible From domain and avoid message changes after signing.
- Separate mail streams: Do not mix password resets, lifecycle mail, and bulk marketing through the same stream when relay complaints appear.
- Warn relay users: During signup, tell Apple relay users the From address to expect and offer a way to resend critical mail.
- Watch reports: Use Suped's DMARC monitoring to catch authentication failures and new sources before they become Gmail placement issues.
Use Suped to investigate sender authentication
Suped's DMARC reporting and email authentication platform provides receiver-reported evidence for sender-side checks before relay seed testing. Use its DMARC reports to identify reported sources with failing SPF or DKIM and check domain matching. Pair those reports with Suped's DNS checks and blocklist (blacklist) monitoring before comparing direct Gmail with Apple-relayed Gmail.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's DMARC reports do not expose the full Apple-to-Gmail SMTP transaction or Gmail folder placement. DMARC aggregate reports cover messages reported by participating receivers rather than every original send, and show authentication at the reporting receiver. Compare new sources and blocklist changes with bounce logs, message IDs, full headers, and seed-test timestamps.
Best practical workflow
Use Suped to monitor authentication, diagnose DNS issues, track unverified sources, and keep policy changes controlled. Use Gmail and Apple relay seed accounts to confirm placement. The combined evidence separates sender-side defects from relay acceptance and final Gmail filtering.
Views from the trenches
Best practices
Segment Apple relay users separately so Gmail issues do not hide inside total bounce rates.
Warn new Apple relay signups to watch for the sender address before critical mail starts.
Compare direct Gmail delivery with relay delivery using the same content and sender setup.
Common pitfalls
Treating normal bounce rates as proof of inbox placement misses spam folder placement.
Changing DNS during testing adds noise when the relay path already has extra filtering.
Assuming Gmail drops mail silently can hide filters, spam placement, or forwarding faults.
Expert tips
Keep test accounts on Gmail and Apple relay so changes can be checked within minutes.
Capture headers from delivered relay mail; they show what Gmail evaluated after forwarding.
Use DMARC reports to inspect reported failures, then use Gmail seed accounts to test placement.
Marketer view
Marketer from Email Geeks says rejected mail at Gmail should normally create a bounce path through Apple, so missing mail without bounce growth points first to spam placement, user filtering, or relay handling.
2025-03-03 - Email Geeks
Marketer view
Marketer from Email Geeks says the only parties that can fully see the Apple-to-Gmail SMTP transaction are Apple and Google, so sender-side testing should focus on warnings, seed accounts, and clear evidence.
2025-03-03 - Email Geeks
Escalate persistent relay delivery failures
First identify the failure stage. A rejection at Apple's intake points to source registration, authentication, alias status, or the per-alias limit. A Gmail rejection reported by Apple points to downstream SMTP delivery. Apple acceptance followed by confirmed Gmail spam placement points to forwarding effects, sender quality, Gmail filtering, or recipient mailbox rules.
For Sign in with Apple, verify source registration, DNS, and authentication, then run direct Gmail and Apple-relayed Gmail seed tests and inspect delivered headers. If the sender passes the required checks and only Apple-relayed Gmail users miss mail, escalate to the party responsible for the failing hop with test timestamps and timezone, relay addresses, message IDs, SMTP responses, and header evidence.
Frequently asked questions
iCloud Private Relay does not forward email. Hide My Email and Sign in with Apple use Apple's private email relay, which forwards to the address set in the user's Apple Account. Sign in with Apple aliases require the app's registered sending sources; determine how the alias was created before troubleshooting.
Normal bounce rates mean no rejection reached the sender. They do not prove Gmail inbox placement. The message can be in spam, Trash, a Workspace quarantine, or a user-filtered location.
For a Sign in with Apple alias, check source registration, SPF or DKIM, exact-domain matching, and whether forwarding is active. Apple documents a daily limit of 100 messages per alias, including replies; read the diagnostic rather than assuming every limit-related failure is permanent. If Apple accepted the original message and reports a Gmail rejection later, investigate the downstream SMTP response.
Not always. Gmail checks SPF against Apple's connecting IP and the forwarded envelope sender. Preserving the original return-path domain can cause SPF failure; rewriting it can produce an SPF pass for the relay domain. A surviving DKIM signature matching the visible From domain can preserve DMARC authentication for the original sender.
Do not suppress them by default. Keep active aliases for account and transactional mail, add resend flows, and tell users the expected From address. Suppress confirmed inactive or invalid aliases and honor opt-outs for the relevant mail stream. Fix sender-registration failures before marking an alias invalid.
Collect timestamps with timezone, message IDs, relay addresses, original recipient addresses where allowed, bounce text, sender logs, seed test results, and full headers from any delivered copy. Evidence from both direct Gmail and relayed Gmail tests gives the clearest comparison.
