Skip to this post for the solution. It’s an issue with Apple not validating SPF records properly.
I am curious if anyone else is having issues validating domains with DNS in Cloudflare for the iCloud+ Custom Domain feature?
Apple has a new onboarding flow (making this doc obsolete). They use Domain Connect to automatically configure the necessary DNS records in Cloudflare DNS.
However, the domain validation never completes. I am aware of a couple other people reporting the same problem on Reddit. The worst part is, they update your MX records to iCloiud’s mail servers, but the email mailbox/alias for that domain never gets created. So your inbound mail gets broken with a hard bounceback (“user does not exist”).
Apple has no user-facing support that works on the backend, and the Tier II Engineering seems to dish out generic advice like “contact your DNS provider/registrar”.
I even bought a new domain for testing, and can consistently reproduce the failure of the onboarding process. I don’t see anything that Cloudflare DNS could be doing to break this process, as the service is returning all the DNS records as configured by Apple’s Domain Connect template. But I was wondering if anyone else has had successfully configured this integration in recent days.
@domjh for awareness, since you have a pinned tutorial on iCloud+ setup, which is now obsolete due to Apple (poorly) implementing Domain Connect.
As far as I can tell, the issue from the linked post has been resolved. The records do get created. It’s just that the domain never gets validated on Apple’s side. But Apple’s Tier 2 support is still advising people to contact Cloudflare.
They no longer display or email the required records if the Domain Connect integration is used. But you can open Developer Tools on your browser, and see the request that they’re making to Cloudflare. So records could be extracted that way.
To be clear, I believe this issue is 100% on Apple’s side. But thus far I was unable to reach anyone who’s involved in the backend side of this validation system in order to confirm exactly what’s wrong. Meanwhile the advice they (escalation engineers) give out is to basically blame the user / Cloudflare.
Here’s the new setup flow at iCloud for Cloudflare, using Domain Connect:
I had the same issue yesterday and saw this thread. Today I canceled it on the iCloud side and manually deleted all of the DNS entries it had created. Started the process again from iCloud and this time it worked.
But, upon further investigation, the issue is with the SPF record specifically. Apple’s validation logic appears buggy, and not handling multiple include: statements right.
So I believe that the least impactful workaround is to delete your SPF record, THEN go through Apple’s validation process.
Unfortunately, Apple Support was not interested in investigating it further, and they seemed quite happy to advise people to nuke their DNS zone going forward, even though this will cause an outage (however brief, still unacceptable!) on customer’s side.
Hi @hannes Unfortunately, it looks like this was short lived. After my successful verification I updated my MX and SPF records to use Cloudflare email routing. Today I received an email from Apple stating,
“You’re currently unable to send or receive iCloud Mail, or create new email addresses, with your domain, “[my-domain]”. Check with your domain registrar, as your domain may have expired, or your configuration may have changed. To reverify your domain, or to stop using the domain with iCloud Mail, go to iCloud Settings.”
When I go to iCloud Settings, it confirms that that I need to reverify my domain. The reverify process appears to be the same as the initial verification where it wants to overwrite my email related DNS setting in Cloudflare using the API. It would seem that Apple is checking all mail related DNS entries, not just the verification TXT and so Cloudflare email routing is not currently possible.
Just to clarify, what I meant is: The Domain Connect integration between iCloud Mail and Cloudflare DNS is working now.
What you are describing seems that you are also using Cloudflare Email Routing.
As of today, you cannot use a cloud email provider simultaneously with Cloudflare Email Routing. The reason is because in order to use Cloudflare Email Routing, we expect you to configure 3 MX records all pointing to Cloudflare email servers. But if you want to receive email in iCloud Mail you have to configure the required Apple email servers on your MX records. You can’t do both at the same time.
I contacted Apple about this last week, before seeing this post, and had the issue escalated all the way to one of their engineers. It has since been fixed, at least for me.
Assuming their fix applies to everyone else, you should be able to see a “Reverify” button now. Clicking it will cause you to go through the domain connect setup again. After that, everything will work as normal.
It didn’t affect my initial setup, and only started happening when I removed a custom email address later: this leads me to believe the issue was caused by a recent change on Apple’s end. ↩︎
Cloudflare’s UI for that process shows you which records replace existing ones, so pay attention: I had to change my SPF policy back and delete the previous apple-domainTXT record, since the setup simply adds another one. ↩︎
That’s quite welcome, as iCloud+ inexplicably limits each custom domain to three email addresses, none of which act as a catch-all. Removing a dedicated DMARC report address after realizing that is actually what caused me to run into this bug.
On a related note, are there plans to allow customized WHOIS records? I’d much prefer having dedicated (actual) email addresses for each field, rather than having Cloudflare interpose a web form with no way of verifying the identity of the sender.
You can already specify a different contact per use case (see screenshot below), but all those will be redacted and not publicly visible. If you want us to show your actual contact addresses, please reach out to support, they can manually change this for you. We may allow users to disable redaction at some point in the future.