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

Question

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

Jeff Reed 0

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

Which outbound IP(s) carry our custom-domain traffic to Apple, and what is their current reputation or block status with Apple?
Is the PTR vs HELO mismatch on ACS outbound hosts a known cause of Apple silent-discard, and is any remediation in progress?
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?
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.

Abhinaba Das 105 Reputation points Microsoft External Staff Moderator

2026-08-04T00:13:15.1233333+00:00

Thank you for contacting us about the Azure-managed domain delivers to the same recipient issue We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this
Abhinaba Das 105 Reputation points Microsoft External Staff Moderator

2026-08-05T23:40:36.4433333+00:00
Hi @Jeff Reed

Thank you for providing such a detailed investigation and timeline. The information you've shared shows that you've already ruled out many of the common tenant-side causes, including domain verification, SPF, DKIM, DMARC, and recipient-specific configuration.

The comparison between the Azure-managed domain and your verified custom domains is particularly useful. Since the same iCloud recipient successfully receives messages from the Azure-managed domain but not from the custom domains, while deliveries to Outlook and ProtonMail continue to succeed, this does not immediately point to a configuration issue within your Azure Communication Services Email resource.

Regarding the previously reported PTR/HELO discussion, Microsoft has not published documentation confirming that it is a known root cause for iCloud delivery issues. Therefore, it would be premature to conclude that it is the underlying cause without additional investigation.

To help narrow this down further, could you please share the following details in private message:

The Message ID (or Operation ID) for one or two affected email messages from the ACSEmailStatusUpdateOperational logs.

Whether the behavior is reproducible across multiple iCloud mailboxes or only a specific recipient.

Whether both custom domains (mail.grizcam.com and auth.grizcam.com) are configured under the same Azure Communication Services Email resource.

These details may help determine whether the behavior is specific to a recipient, domain configuration, or requires further investigation using service-side telemetry that is not exposed through Azure Monitor logs.

For reference:

Azure Communication Services Email overview: https://learn.microsoft.com/azure/communication-services/concepts/email/email-overview

Add and verify custom domains: https://learn.microsoft.com/azure/communication-services/quickstarts/email/add-custom-verified-domains

Email domain management: https://learn.microsoft.com/azure/communication-services/concepts/email/email-domain-configuration

Azure Communication Services Email logs: https://learn.microsoft.com/azure/communication-services/concepts/analytics/logs/email-logs

Azure Communication Services service limits: https://learn.microsoft.com/azure/communication-services/concepts/service-limits#email

Kindly let us know if the above helps or if you need further assistance on this issue.

Please upvote if the information was helpful—this helps others in the community as well.
Jeff Reed 0 Reputation points

2026-08-06T03:44:30.4433333+00:00
Hi Abhinaba — thank you for the fast, substantive response. Answers to your three

questions, plus one controlled experiment we ran that I believe isolates the layer.

MESSAGE / OPERATION IDs (from ACSEmailStatusUpdateOperational)

Affected messages — each was accepted, sat at OutForDelivery, and reached a terminal

DeliveryStatus of FAILED exactly ~12 hours after send (IsHardBounce=false), which I

understand to be the service retry window being exhausted against a host that kept

deferring without a hard rejection:

CorrelationId b99e40e2-5ce1-43c8-8671-f1aae7e35d26

SendMail 2026-08-02 22:49:34 UTC (sender auth.grizcam.com) -> Failed 2026-08-03 10:49:38

CorrelationId 73941da4-047a-46e1-a757-7ecbe42791bd

SendMail 2026-08-02 23:26:29 UTC (sender auth.grizcam.com) -> Failed 2026-08-03 11:26:31

CorrelationId 4dc57729 (prefix; from the earlier custom domain mail.grizcam.com)

-> Failed 2026-08-03 08:29:00

Delivered controls from the SAME sender in the SAME window (for contrast):

da742c7d-c070-4188-9143-01b05ff35e0e -> Delivered (ProtonMail, ~15 s)

05ef795c-df03-4938-a682-f9efef7f3928 -> Delivered (Outlook-hosted, ~3 s)

80a042f6-ca7a-4afb-957e-9351b08354c5 -> Delivered (ProtonMail, ~5 s)

REPRODUCIBILITY ACROSS MAILBOXES

Our user base contains only one real Apple-hosted mailbox, so we ran a controlled

experiment against NONEXISTENT @icloud.com addresses (mails nobody; Apple's response

is diagnostic, since an engaged MTA rejects an unknown user quickly):

From the AZURE-MANAGED domain -> nonexistent iCloud user:

HARD BOUNCE in ~3 seconds (Bounced, IsHardBounce=true) — Apple engaged fully, evaluated the recipient, and rejected it. CorrelationId prefix e18696c0 (2026-08-03 01:59:52 -> 01:59:55).

From the CUSTOM domain auth.grizcam.com -> nonexistent iCloud user:

NO engagement — OutForDelivery with no bounce (CorrelationId 15c6eeed-39f4-4247-9dd7-0f18c7e4e58e, SendMail 2026-08-06 03:28 UTC). Apple never even discovers the user doesn't exist. We expect it to reach the same +12 h Failed.

So the behavior is NOT specific to a recipient: for custom-domain traffic Apple

defers/refuses before mailbox evaluation, while identical traffic from the

Azure-managed domain on the SAME resource gets immediate engagement.

DOMAIN TOPOLOGY

Yes — both custom domains (mail.grizcam.com, auth.grizcam.com) AND the Azure-managed

domain are provisioned under the same Email Communication Service

(ecs-grizcam-website) linked to the same ACS resource (acs-grizcam-website),

subscription 8d07f785-ca9c-4709-963e-f550e176aa01, West US 2. Both custom domains show

Domain/SPF/DKIM/DKIM2 = Verified, and From / MAIL FROM are aligned per-domain.

THE ASK

Could you pull the service-side telemetry for the failed correlation IDs above —

specifically the actual SMTP responses (codes + text) Apple's MXes returned during the

12-hour retry windows? That's the piece not exposed through Azure Monitor, and it

would distinguish IP-reputation deferral from something else. Happy to run any further

controlled sends you'd find useful.

Thanks — Jeff (Grizzly Systems Inc)
Jeff Reed 0 Reputation points

2026-08-06T14:16:35.07+00:00
Hi Abhinaba — thank you for the fast, substantive response. Answers to your three

questions, plus one controlled experiment we ran that I believe isolates the layer.

MESSAGE / OPERATION IDs (from ACSEmailStatusUpdateOperational)

Affected messages — each was accepted, sat at OutForDelivery, and reached a terminal

DeliveryStatus of FAILED exactly ~12 hours after send (IsHardBounce=false), which I

understand to be the service retry window being exhausted against a host that kept

deferring without a hard rejection:

CorrelationId b99e40e2-5ce1-43c8-8671-f1aae7e35d26

SendMail 2026-08-02 22:49:34 UTC (sender auth.grizcam.com) -> Failed 2026-08-03 10:49:38

CorrelationId 73941da4-047a-46e1-a757-7ecbe42791bd

SendMail 2026-08-02 23:26:29 UTC (sender auth.grizcam.com) -> Failed 2026-08-03 11:26:31

CorrelationId 4dc57729 (prefix; from the earlier custom domain mail.grizcam.com)

-> Failed 2026-08-03 08:29:00

Delivered controls from the SAME sender in the SAME window (for contrast):

da742c7d-c070-4188-9143-01b05ff35e0e -> Delivered (ProtonMail, ~15 s)

05ef795c-df03-4938-a682-f9efef7f3928 -> Delivered (Outlook-hosted, ~3 s)

80a042f6-ca7a-4afb-957e-9351b08354c5 -> Delivered (ProtonMail, ~5 s)

REPRODUCIBILITY ACROSS MAILBOXES

Our user base contains only one real Apple-hosted mailbox, so we ran a controlled

experiment against NONEXISTENT @icloud.com addresses (mails nobody; Apple's response

is diagnostic, since an engaged MTA rejects an unknown user quickly):

From the AZURE-MANAGED domain -> nonexistent iCloud user:

HARD BOUNCE in ~3 seconds (Bounced, IsHardBounce=true) — Apple engaged fully, evaluated the recipient, and rejected it. CorrelationId prefix e18696c0 (2026-08-03 01:59:52 -> 01:59:55).

From the CUSTOM domain auth.grizcam.com -> nonexistent iCloud user:

NO engagement — OutForDelivery with no bounce (CorrelationId 15c6eeed-39f4-4247-9dd7-0f18c7e4e58e, SendMail 2026-08-06 03:28 UTC). Apple never even discovers the user doesn't exist. We expect it to reach the same +12 h Failed.

So the behavior is NOT specific to a recipient: for custom-domain traffic Apple

defers/refuses before mailbox evaluation, while identical traffic from the

Azure-managed domain on the SAME resource gets immediate engagement.

DOMAIN TOPOLOGY

Yes — both custom domains (mail.grizcam.com, auth.grizcam.com) AND the Azure-managed

domain are provisioned under the same Email Communication Service

(ecs-grizcam-website) linked to the same ACS resource (acs-grizcam-website),

subscription 8d07f785-ca9c-4709-963e-f550e176aa01, West US 2. Both custom domains show

Domain/SPF/DKIM/DKIM2 = Verified, and From / MAIL FROM are aligned per-domain.

THE ASK

Could you pull the service-side telemetry for the failed correlation IDs above —

specifically the actual SMTP responses (codes + text) Apple's MXes returned during the

12-hour retry windows? That's the piece not exposed through Azure Monitor, and it

would distinguish IP-reputation deferral from something else. Happy to run any further

controlled sends you'd find useful.

Thanks — Jeff (Grizzly Systems Inc)Hi Abhinaba — thank you for the fast, substantive response. Answers to your three

questions, plus one controlled experiment we ran that I believe isolates the layer.

MESSAGE / OPERATION IDs (from ACSEmailStatusUpdateOperational)

Affected messages — each was accepted, sat at OutForDelivery, and reached a terminal

DeliveryStatus of FAILED exactly ~12 hours after send (IsHardBounce=false), which I

understand to be the service retry window being exhausted against a host that kept

deferring without a hard rejection:

CorrelationId b99e40e2-5ce1-43c8-8671-f1aae7e35d26

SendMail 2026-08-02 22:49:34 UTC (sender auth.grizcam.com) -> Failed 2026-08-03 10:49:38

CorrelationId 73941da4-047a-46e1-a757-7ecbe42791bd

SendMail 2026-08-02 23:26:29 UTC (sender auth.grizcam.com) -> Failed 2026-08-03 11:26:31

CorrelationId 4dc57729 (prefix; from the earlier custom domain mail.grizcam.com)

-> Failed 2026-08-03 08:29:00

Delivered controls from the SAME sender in the SAME window (for contrast):

da742c7d-c070-4188-9143-01b05ff35e0e -> Delivered (ProtonMail, ~15 s)

05ef795c-df03-4938-a682-f9efef7f3928 -> Delivered (Outlook-hosted, ~3 s)

80a042f6-ca7a-4afb-957e-9351b08354c5 -> Delivered (ProtonMail, ~5 s)

REPRODUCIBILITY ACROSS MAILBOXES

Our user base contains only one real Apple-hosted mailbox, so we ran a controlled

experiment against NONEXISTENT @icloud.com addresses (mails nobody; Apple's response

is diagnostic, since an engaged MTA rejects an unknown user quickly):

From the AZURE-MANAGED domain -> nonexistent iCloud user:

HARD BOUNCE in ~3 seconds (Bounced, IsHardBounce=true) — Apple engaged fully, evaluated the recipient, and rejected it. CorrelationId prefix e18696c0 (2026-08-03 01:59:52 -> 01:59:55).

From the CUSTOM domain auth.grizcam.com -> nonexistent iCloud user:

NO engagement — OutForDelivery with no bounce (CorrelationId 15c6eeed-39f4-4247-9dd7-0f18c7e4e58e, SendMail 2026-08-06 03:28 UTC). Apple never even discovers the user doesn't exist. We expect it to reach the same +12 h Failed.

So the behavior is NOT specific to a recipient: for custom-domain traffic Apple

defers/refuses before mailbox evaluation, while identical traffic from the

Azure-managed domain on the SAME resource gets immediate engagement.

DOMAIN TOPOLOGY

Yes — both custom domains (mail.grizcam.com, auth.grizcam.com) AND the Azure-managed

domain are provisioned under the same Email Communication Service

(ecs-grizcam-website) linked to the same ACS resource (acs-grizcam-website),

subscription 8d07f785-ca9c-4709-963e-f550e176aa01, West US 2. Both custom domains show

Domain/SPF/DKIM/DKIM2 = Verified, and From / MAIL FROM are aligned per-domain.

THE ASK

Could you pull the service-side telemetry for the failed correlation IDs above —

specifically the actual SMTP responses (codes + text) Apple's MXes returned during the

12-hour retry windows? That's the piece not exposed through Azure Monitor, and it

would distinguish IP-reputation deferral from something else. Happy to run any further

controlled sends you'd find useful.

Thanks — Jeff (Grizzly Systems Inc)
TP 162.1K Reputation points Volunteer Moderator

2026-08-18T20:08:53.47+00:00

Hi Jeff,

I started investigating your issue and first thing I notice is you don't have MX record for mail.grizcam.com or auth.grizcam.com. I don't know specifically how iCloud treats lack of MX record, but I do know in general it is considered potential spam signal.

ACS documentation recommends having MX record. I would go a step further and say it is best to not only have MX record, but that it points to valid email server that will receive messages for that domain and the MailFrom addresses (******@mail.grizcam.com, etc.) you have configured. Have automation that processes any messages that come in for Non Delivery Reports, manual unsubscribes, opt-outs, etc.

I plan to do some tests against iCloud but first I would appreciate it if you would add MX records and test again to see if it changes your results at all.

Please add comment below with your results, whether positive or negative.

Thanks.

-TP
Abhinaba Das 105 Reputation points Microsoft External Staff Moderator

2026-08-19T22:07:28.5866667+00:00
Hi Jeff,

Thank you for the detailed testing and correlation IDs.

Based on the results, the issue is isolated to delivery of messages sent from the ACS custom domains to Apple/iCloud. Your authentication and domain configuration are already verified, and the same resource successfully delivers to other providers. The controlled test also shows that the Azure-managed domain reaches the iCloud MX while the custom-domain traffic remains in OutForDelivery.

At this point, there is no additional tenant-side DNS, SPF, DKIM, or DMARC change that we can recommend to resolve this behavior. The PTR/HELO behavior mentioned earlier should also not be treated as a confirmed root cause without service-side evidence.

For a reliable production workaround, use the Azure-managed *.azurecomm.net sender for messages that must reach iCloud while the custom-domain delivery path is being investigated. Your testing has already confirmed that the Azure-managed domain successfully reaches the same Apple-hosted destination.

If using the custom domain is a hard requirement, the remaining action is service-side investigation of the SMTP responses and outbound delivery path for the affected correlation IDs; those details are not exposed through the tenant-side Azure Monitor logs.

Reference:

https://learn.microsoft.com/en-au/azure/communication-services/concepts/email/email-overview?utm_source=chatgpt.com

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-domain-and-sender-authentication?utm_source=chatgpt.com

https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/add-custom-verified-domains?utm_source=chatgpt.com

https://learn.microsoft.com/en-us/azure/communication-services/concepts/analytics/logs/email-logs?utm_source=chatgpt.com

Kindly let us know if the above helps or if you need further assistance on this issue.

Please upvote if the information was helpful—this helps others in the community as well.
Abhinaba Das 105 Reputation points Microsoft External Staff Moderator

2026-08-22T19:08:33.2066667+00:00
Hi @Jeff Reed

Thank you for the detailed follow-up and the controlled testing. Based on the correlation IDs, timestamps, and comparison results you provided, the issue does not appear to be caused by the configuration of your custom domains.

The key observation is that messages sent from the same Azure Communication Services Email resource using the Azure-managed domain receive immediate engagement from Apple's mail infrastructure, while messages sent using the verified custom domains remain in OutForDelivery and eventually reach Failed. Since the same custom-domain sender successfully delivers to other providers, and the custom-domain test against a nonexistent @icloud.com address does not receive an immediate recipient-level rejection, this indicates that the delivery problem is occurring during the interaction between the ACS outbound email infrastructure and Apple's mail infrastructure, before normal mailbox evaluation.

At this point, there is no additional tenant-side SPF, DKIM, DMARC, or domain verification configuration that we can recommend changing based on the information available. The actual SMTP response details for the delivery attempts are not exposed through Azure Monitor logs, so those would require investigation through service-side telemetry.

As a practical workaround for time-sensitive delivery to Apple-hosted recipients, you may consider continuing to use the Azure-managed domain where it meets your requirements, since your controlled testing shows successful delivery from that domain to the same recipient environment.

For the custom-domain delivery issue itself, the correlation IDs and timestamps you provided would need to be reviewed against service-side telemetry to determine the exact response or deferral received from Apple's MX infrastructure. The information currently available does not support a tenant-side configuration change as a confirmed resolution.

Thank you again for providing such detailed evidence and controlled test results.

For additional reference, please see the following official Microsoft documentation:

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-overview?utm_source=chatgpt.com

https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/add-custom-verified-domains?utm_source=chatgpt.com

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-domain-and-sender-authentication?utm_source=chatgpt.com

https://learn.microsoft.com/en-us/azure/communication-services/concepts/analytics/logs/email-logs?utm_source=chatgpt.com

Kindly let us know if the above helps or if you need further assistance on this issue.

Please upvote if the information was helpful—this helps others in the community as well.

Your answer

Abhinaba Das 105 Reputation points Microsoft External Staff Moderator

2026-08-04T00:13:15.1233333+00:00

Thank you for contacting us about the Azure-managed domain delivers to the same recipient issue We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this
TP 162.1K Reputation points Volunteer Moderator

2026-08-18T20:08:53.47+00:00

Hi Jeff,

I started investigating your issue and first thing I notice is you don't have MX record for mail.grizcam.com or auth.grizcam.com. I don't know specifically how iCloud treats lack of MX record, but I do know in general it is considered potential spam signal.

ACS documentation recommends having MX record. I would go a step further and say it is best to not only have MX record, but that it points to valid email server that will receive messages for that domain and the MailFrom addresses (******@mail.grizcam.com, etc.) you have configured. Have automation that processes any messages that come in for Non Delivery Reports, manual unsubscribes, opt-outs, etc.

I plan to do some tests against iCloud but first I would appreciate it if you would add MX records and test again to see if it changes your results at all.

Please add comment below with your results, whether positive or negative.

Thanks.

-TP