ACS Email: custom-domain mail silently dropped by iCloud; Azure-managed domain delivers to the same recipient

Email sent via Azure Communication Services to Apple-hosted recipients (@icloud.com) is accepted and then

silently discarded — never delivered, never bounced — when the From domain is one of our verified custom

domains. The identical message to the same recipient IS delivered when sent from the Azure-managed domain.

All authentication is verified and aligned. This locked a real customer out of our product for a week.

Resource: acs-grizcam-website (email service ecs-grizcam-website), West US 2.

TIMELINE

2026-06-24 Azure-MANAGED domain (*.azurecomm.net) -> Delivered to @icloud.com

2026-07-14 Cut over to CUSTOM domain mail.grizcam.com -> Silent drop

2026-08-02 New clean CUSTOM domain auth.grizcam.com -> Silent drop

EVIDENCE (ACSEmailStatusUpdateOperational, same sender, same hour)

22:30:19 Outlook-hosted recipient Delivered (2s)

22:54:37 ProtonMail recipient Delivered (15s)

23:49:51 nonexistent test domain Bounced, IsHardBounce=true (~1s)

22:49:37 @icloud.com OutForDelivery - never resolves. No bounce, ever.

23:26:30 @icloud.com OutForDelivery - never resolves. No bounce, ever.

A nonexistent domain hard-bounces in ~1 second, proving the pipeline reports failures correctly. Apple

produces no status at all, and no RecipientMailServerHostName is ever recorded, so the handoff never

completes.

AUTHENTICATION (all verified, all aligned)

• From domain auth.grizcam.com; MAIL FROM / Return-Path auth.grizcam.com (aligned)
• SPF: v=spf1 include:spf.protection.outlook.com -all
• DKIM: both ACS selectors published as CNAMEs, Verified
• DMARC: v=DMARC1; p=none; rua=...
• ACS domain verification states: Domain / SPF / DKIM / DKIM2 = Verified

RULED OUT

• Our DNS/authentication (verified above)
• Domain reputation (a brand-new custom domain fails identically)
• Recipient-side rules (customer confirmed no matching block rules; sender added to Contacts)
• General outage (same sender delivers to Outlook/ProtonMail continuously)
• Complaint contamination (auth.grizcam.com has only ever sent transactional login codes)

SUSPECTED CAUSE

This looks like the PTR/HELO misalignment already reported in

https://learn.microsoft.com/en-us/answers/questions/2083603/ptr-record-mismatch-causing-email-delivery-issues

where sending IP 104.47.51.185 had PTR mail-...outbound.protection.outlook.com while the session announced a

different ...outbound.protection.outlook.com hostname. Both names are Microsoft-owned, so no tenant-side fix

is possible. That thread was never publicly resolved.

Apple's own Postmaster guidance (https://support.apple.com/en-us/102322) says senders should "publish reverse

DNS with your domain" and "use consistent sending IP addresses" - neither of which an ACS custom domain can

satisfy, since PTR points to Microsoft infrastructure and the pool is shared and rotating.

QUESTIONS

1. Which outbound IP(s) carry our custom-domain traffic to Apple, and what is their current reputation or block status with Apple?
2. Is the PTR vs HELO mismatch on ACS outbound hosts a known cause of Apple silent-discard, and is any remediation in progress?
3. What is the supported path for reliable Apple/iCloud delivery from an ACS custom domain, given that dedicated IPs and custom PTR are documented as unsupported?
4. If there is no tenant-side or Microsoft-side remediation available, please state that plainly so we can make an informed architecture decision.

Not asking for: a quota increase, or generic SPF/DKIM/DMARC guidance - authentication is already correct

and verified.