SPF, DKIM et DMARC pour Apple iCloud+ Custom Email Domain.
Le domaine de messagerie personnalisé d'iCloud+ d'Apple vous permet d'envoyer et de recevoir des messages sur votre propre domaine (vous@votredomaine.com) via iCloud Mail, et il authentifie ce courrier grâce à un ensemble d'enregistrements DNS qu'Apple génère pour vous lors de la configuration : deux enregistrements MX qui confient l'intégralité de votre boîte aux lettres à iCloud, un enregistrement TXT apple-domain qui prouve que vous êtes propriétaire du domaine, un enregistrement SPF qui ajoute l'include partagé d'Apple include:icloud.com, et un unique CNAME DKIM (sig1._domainkey) qui délègue la signature à Apple. Il n'y a aucune clé publique DKIM à coller ni rien à faire tourner (rotation) — Apple détient la clé privée derrière ce CNAME. Le seul enregistrement qu'Apple ne génère PAS, c'est DMARC ; c'est l'élément que vous ajoutez vous-même pour transformer SPF et DKIM en une véritable protection contre l'usurpation.
Pourquoi authentifier Apple iCloud+ Custom Email Domain ?
Configurer correctement ces enregistrements sur iCloud comporte des enjeux plus élevés que sur un simple service d'envoi, car le domaine de messagerie personnalisé fait d'iCloud l'hôte de votre boîte aux lettres, et pas seulement un relais sortant — la même modification MX qui vous permet d'envoyer redirige aussi chaque message entrant du domaine vers Apple. Une mauvaise configuration ne vous envoie pas simplement dans les spams : vous cessez de recevoir votre courrier. Côté délivrabilité, les règles modernes s'appliquent toujours : depuis février 2024, Gmail et Yahoo exigent que chaque expéditeur passe SPF ou DKIM (et que les expéditeurs en masse publient aussi DMARC avec alignement), et Microsoft a commencé à appliquer des vérifications similaires pour les expéditeurs à fort volume en 2025. iCloud est l'un des bons cas ici — parce qu'il est réellement l'hôte de votre boîte aux lettres, le courrier sortant est signé en DKIM au nom de votre domaine et SPF se résout via les adresses IP autorisées d'Apple, de sorte que les deux mécanismes peuvent s'aligner sur votredomaine.com et alimenter une réussite DMARC. Mais Apple ne publie jamais que SPF et DKIM ; tant que vous n'ajoutez pas vous-même l'enregistrement DMARC, les destinataires n'ont aucune politique à appliquer et votre domaine reste usurpable. Notez aussi que le domaine de messagerie personnalisé d'iCloud+ est une boîte aux lettres personnelle / pour petite équipe (toute formule payante de stockage iCloud+ l'inclut), et non une plateforme marketing ou transactionnelle — authentifiez-le en tant que votre boîte aux lettres humaine, et gardez l'envoi en masse sur un ESP dédié.
La réalité SPF pour Apple iCloud+ Custom Email Domain
iCloud est un véritable fournisseur « include » : vous ajoutez un seul mécanisme partagé, include:icloud.com, à l'unique enregistrement TXT SPF sur votre domaine racine, et l'assistant de configuration d'Apple l'écrit sous la forme v=spf1 include:icloud.com ~all. Cette partie-là est standard. Ce que presque tous les guides se trompent, c'est sur le coût. include:icloud.com n'est PAS un include bon marché à une seule recherche — c'est l'un des includes partagés les plus coûteux d'usage courant. Résolvez-le et l'enregistrement SPF d'icloud.com est v=spf1 redirect=_spf.icloud.com ; cette redirection pointe vers _spf.icloud.com, dont l'enregistrement est v=spf1 include:_nets0.icloud.com include:_nets1.icloud.com include:_nets2.icloud.com ~all (chaque enregistrement _nets ne contient que des plages ip4/ip6, la chaîne s'arrête donc là). En comptant selon la RFC 7208, cela fait l'include lui-même (1) + la redirection (1) + trois includes _nets imbriqués (3) = CINQ de vos 10 recherches DNS SPF autorisées, dépensées pour iCloud à lui seul. Si vous envoyez aussi via Google Workspace, Microsoft 365 ou SendGrid, vous pouvez atteindre rapidement le PermError des 10 recherches, alors traitez l'include d'iCloud comme un poste de dépense lourd et gardez le reste de votre SPF léger. Deux autres règles : conservez exactement un seul enregistrement SPF sur le domaine (fusionnez include:icloud.com dans votre ligne v=spf1 existante plutôt que de publier un second TXT — deux enregistrements SPF constituent un PermError automatique), et ne confondez pas la forme include avec la forme redirect=icloud.com que montrent certains tutoriels plus anciens. redirect=icloud.com remplace toute votre politique SPF par celle d'Apple et abandonne silencieusement tous les autres expéditeurs (et coûte les mêmes 5 recherches, donc ne vous apporte rien), il n'est donc correct que si iCloud est la SEULE chose qui envoie au nom de votre domaine. Apple termine par ~all (softfail), ce qui est la bonne valeur par défaut le temps de confirmer que chaque expéditeur est couvert.
Deux façons de le configurer
include:icloud.com (valeur par défaut d'Apple — conservez les autres expéditeurs)
- Ce que l'assistant de configuration d'Apple génère réellement : v=spf1 include:icloud.com ~all
- Coexiste avec d'autres expéditeurs — vous pouvez fusionner Google Workspace, M365, SendGrid, etc. dans la même ligne
- Coûte 5 de vos 10 recherches DNS SPF (redirection + trois includes _nets imbriqués), prévoyez votre budget en conséquence
- Se termine par un softfail ~all, la valeur par défaut sûre le temps de confirmer que chaque expéditeur est autorisé
redirect=icloud.com (uniquement si iCloud est votre SEUL expéditeur)
- Remplace TOUTE votre politique SPF par celle d'Apple — tout ce qui n'est pas dans l'enregistrement d'icloud.com échoue en hardfail
- Casse silencieusement tout autre service qui envoie au nom de votre domaine (newsletters, formulaires, CRM)
- Aucune économie de recherche — il résout la même chaîne icloud.com à 5 recherches, mais sans aucune flexibilité
- À n'utiliser que sur un domaine où iCloud Mail est l'unique source d'envoi exclusive
Étape par étape
- 1
Confirmez que vous disposez d'iCloud+
Le domaine de messagerie personnalisé est une fonctionnalité d'iCloud+, vous avez donc besoin de n'importe quelle formule payante d'iCloud+ (toute formule de stockage convient). L'organisateur du compte peut partager un domaine avec les membres du Partage familial, ou vous pouvez le configurer pour vous seul.
- 2
Ouvrez le domaine de messagerie personnalisé
Sur le web, connectez-vous sur icloud.com, ouvrez les réglages Compte/Mail, et choisissez Domaine de messagerie personnalisé (icloud.com/settings le liste directement). Sur un iPhone/iPad : Réglages → touchez votre nom → iCloud → faites défiler jusqu'à Domaine de messagerie personnalisé sous les Fonctionnalités iCloud+.
- 3
Ajoutez votre domaine
Choisissez si le domaine est pour « Vous uniquement » ou « Vous et d'autres personnes » (Partage familial), puis saisissez votre domaine, p. ex. votredomaine.com. iCloud+ autorise jusqu'à 5 domaines, avec jusqu'à 3 adresses par personne et par domaine.
- 4
Créez les adresses e-mail que vous utiliserez
Ajoutez les boîtes aux lettres que vous voulez sur le domaine (vous@votredomaine.com, hello@votredomaine.com, …). Apple ne publiera pas les instructions DNS tant que vous n'aurez pas défini au moins une adresse — il s'agit d'une migration de boîte aux lettres, pas d'une simple signature sortante, alors décidez de vos adresses dès le départ.
- 5
Récupérez vos enregistrements DNS
Apple affiche les enregistrements à ajouter — deux MX, une valeur de vérification TXT apple-domain, la ligne SPF, et le CNAME DKIM sig1._domainkey. Utilisez « Envoyer les instructions par e-mail » pour vous les envoyer, ou copiez chaque valeur. Les instructions d'Apple indiquent un TTL de 3600 (1 heure) ; tout TTL standard convient.
- 6
Redirigez les MX vers iCloud
Chez votre hébergeur DNS, SUPPRIMEZ tout enregistrement MX existant et ajoutez mx01.mail.icloud.com et mx02.mail.icloud.com, tous deux avec la priorité 10. C'est l'étape déterminante : elle déplace TOUT le courrier entrant du domaine vers iCloud, ne le faites donc que lorsque vous êtes prêt à faire d'iCloud la boîte aux lettres de ces adresses.
- 7
Ajoutez le TXT de vérification et l'enregistrement SPF
Sur la racine (hôte @) : ajoutez un enregistrement TXT avec la valeur de vérification apple-domain=… d'Apple, et ajoutez ou FUSIONNEZ l'enregistrement SPF v=spf1 include:icloud.com ~all. Si un enregistrement v=spf1 existe déjà, intégrez include:icloud.com dans cette unique ligne — ne publiez jamais un second TXT SPF.
- 8
Ajoutez le CNAME DKIM
Créez un CNAME avec l'hôte sig1._domainkey et la cible sig1.dkim.votredomaine.com.at.icloudmailadmin.com (Apple insère votre vrai domaine dans la cible). Si votre DNS est sur Cloudflare, réglez-le sur DNS only (nuage gris) — un enregistrement proxifié/nuage orange ou l'aplatissement de CNAME casse la résolution DKIM.
- 9
Publiez votre propre enregistrement DMARC
Apple ne crée pas DMARC. Ajoutez un enregistrement TXT à l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com. p=none est en mode surveillance uniquement, donc rien n'est bloqué le temps de confirmer que le courrier iCloud passe SPF et DKIM de façon alignée.
- 10
Terminez la configuration et testez un vrai message
De retour dans iCloud, cliquez sur Terminer la configuration afin qu'Apple vérifie les enregistrements (la propagation peut prendre de quelques minutes à quelques heures). Ensuite, envoyez un message depuis votre nouvelle adresse vers un compte Gmail, ouvrez ⋮ → Afficher l'original, et confirmez SPF: PASS, DKIM: PASS (signed-by votredomaine.com, sélecteur sig1), et DMARC: PASS. Envoyez aussi un message VERS l'adresse pour confirmer qu'iCloud reçoit désormais.
Enregistrements à ajouter
Apple iCloud+ Custom Email Domain génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| MX | @ | mx01.mail.icloud.comPriorité 10 — redirige tout le courrier entrant vers iCloud (supprimez d'abord les MX existants) |
| MX | @ | mx02.mail.icloud.comPriorité 10 — deuxième serveur de messagerie iCloud |
| TXT | @ | apple-domain=Ab12Cd34Ef56Gh78À titre indicatif — Apple génère une valeur de vérification unique par domaine ; gardez-la publiée, Apple la revérifie |
| TXT | @ | v=spf1 include:icloud.com ~allFusionnez dans votre unique ligne SPF si elle existe. include:icloud.com coûte 5 recherches DNS (redirection + 3 includes _nets imbriqués) |
| CNAME | sig1._domainkey | sig1.dkim.yourdomain.com.at.icloudmailadmin.comÀ titre indicatif — Apple insère votre vrai domaine. La clé DKIM est détenue/renouvelée par Apple ; gardez DNS-only (pas de proxy Cloudflare) |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez — Apple ne le fait pas. Un seul enregistrement DMARC par domaine ; commencez à p=none, puis durcissez |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Apple iCloud+ Custom Email Domain sur ce budget.
Apple iCloud+ Custom Email Domain utilise 5 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
Le DKIM pour iCloud est délégué, pas collé. Apple vous fait publier un unique CNAME — hôte sig1._domainkey.votredomaine.com pointant vers sig1.dkim.votredomaine.com.at.icloudmailadmin.com (Apple insère votre vrai domaine dans cette cible lors de la configuration). Il n'y a pas de clé publique v=DKIM1; p=… à copier ni de sélecteur à inventer : Apple détient la clé privée derrière ce CNAME, signe votre courrier iCloud sortant avec d=votredomaine.com en utilisant le sélecteur sig1, et peut faire tourner (rotation) la clé publiée de son côté sans que vous ayez à modifier le DNS de nouveau. Deux points pratiques. Premièrement, iCloud provisionne exactement UN seul sélecteur, sig1 — si un tutoriel vous dit d'ajouter aussi sig2, cela ne fait pas partie du flux actuel d'Apple ; un unique CNAME sig1 est correct et complet. Deuxièmement, parce qu'il s'agit d'un CNAME vers le nom d'hôte d'Apple, il doit se résoudre comme un enregistrement délégué normal : si votre DNS est sur Cloudflare, réglez-le sur DNS only (nuage gris), et évitez l'aplatissement de CNAME (CNAME flattening) ou tout proxy qui réécrirait la cible, car cela casse la délégation et le DKIM échoue silencieusement à signer. Le DKIM est le mécanisme qui s'aligne le plus fiablement sur votre domaine ici (le d= est votredomaine.com), c'est donc lui qui porte une réussite DMARC même lorsqu'un message est transféré et que SPF casse — configurez ce CNAME correctement.
DMARC
DMARC est l'enregistrement qu'Apple ne crée jamais pour vous, et sans lui, le SPF et le DKIM que vous venez de publier n'aboutissent à aucune politique applicable. Ajoutez un enregistrement TXT à _dmarc.votredomaine.com avec v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com. p=none est en mode surveillance uniquement — il ne change rien à la délivrance mais demande aux destinataires de vous envoyer par e-mail des rapports agrégés (rua) afin que vous puissiez observer l'authentification du courrier iCloud. Comme iCloud signe en DKIM au nom de votre propre domaine et envoie via les adresses IP autorisées SPF d'Apple, vous devriez rapidement voir des réussites propres et alignées. Laissez les rapports tourner une semaine ou deux, confirmez qu'iCloud ainsi que tout autre expéditeur légitime (un outil de newsletter, un formulaire de contact, un autre fournisseur de boîte aux lettres) passent tous de façon alignée, puis durcissez en p=quarantine et enfin p=reject pour réellement stopper l'usurpation. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine, quel que soit le nombre de services que vous utilisez — n'ajoutez jamais un second enregistrement DMARC spécifiquement pour iCloud. Si vous hébergez votre DNS quelque part qui vous permet aussi de recevoir les rapports, pointez rua vers une boîte aux lettres que vous lirez réellement, ou faites-les analyser par un analyseur DMARC.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul coche vert « Terminer la configuration » d'Apple — confirmez l'authentification sur un vrai message. Envoyez depuis votre nouvelle adresse iCloud vers un compte Gmail, ouvrez le message, et choisissez ⋮ → Afficher l'original : vous voulez SPF: PASS, DKIM: PASS avec signed-by: votredomaine.com et le sélecteur sig1, et DMARC: PASS — tous pointant vers votre domaine, pas vers icloud.com. Parce qu'iCloud est désormais aussi votre hôte de réception, envoyez également un message VERS l'adresse et assurez-vous qu'il arrive, ce qui prouve que la modification MX a bien été prise en compte. Pour une vérification brute, dig TXT votredomaine.com devrait afficher votre unique v=spf1 include:icloud.com ~all, dig CNAME sig1._domainkey.votredomaine.com devrait se résoudre en sig1.dkim.votredomaine.com.at.icloudmailadmin.com, et dig TXT _dmarc.votredomaine.com devrait renvoyer votre politique. Ensuite, passez le domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que chaque enregistrement se résout et — point important pour iCloud — que votre SPF reste sous la limite des 10 recherches compte tenu des 5 recherches que consomme include:icloud.com. Une fois les rapports agrégés arrivés, déposez-en un dans l'analyseur de rapports DMARC pour confirmer qu'iCloud apparaît comme une source alignée et entièrement conforme.
Pièges courants
- Casse l'authentification
include:icloud.com est coûteux : il coûte 5 de vos 10 recherches DNS SPF, pas 1. icloud.com redirige vers _spf.icloud.com, qui imbrique _nets0/_nets1/_nets2.icloud.com. Empilez-le avec Google Workspace ou Microsoft 365 et vous pouvez atteindre le PermError des 10 recherches — gardez le reste de votre SPF léger et surveillez le compteur.
- Couverture
C'est une migration complète de boîte aux lettres, pas seulement une signature sortante. Les enregistrements mx01/mx02.mail.icloud.com redirigent TOUT le courrier entrant du domaine vers iCloud. Vous ne pouvez pas héberger en split les mêmes adresses entre iCloud et un autre fournisseur — n'ajoutez les MX que lorsque vous êtes prêt à ce qu'iCloud reçoive ce courrier.
- Configuration DNS
Utilisez la forme include, pas redirect=icloud.com. redirect remplace toute votre politique SPF par celle d'Apple et abandonne silencieusement tous les autres expéditeurs — et il coûte les mêmes 5 recherches, il n'y a donc aucun avantage. Il n'est correct que lorsqu'iCloud est l'unique expéditeur exclusif du domaine ; sinon vos formulaires, newsletters et CRM commencent à échouer SPF.
- Configuration DNS
L'enregistrement DKIM est un CNAME que vous ne devez ni proxifier ni aplatir. Sur Cloudflare, réglez sig1._domainkey sur DNS only (nuage gris) ; un proxy nuage orange ou l'aplatissement de CNAME réécrit la cible et le DKIM cesse de signer. Apple détient la clé — vous ne collez ni ne faites jamais tourner de clé publique.
- Configuration DNS
Apple publie SPF et DKIM mais jamais DMARC. Sans votre propre enregistrement _dmarc, il n'y a aucune politique à appliquer et le domaine reste usurpable — ajoutez v=DMARC1; p=none pour commencer, puis durcissez.
- Configuration DNS
iCloud provisionne un seul sélecteur DKIM (sig1). Si un guide dit d'ajouter aussi sig2, ce n'est pas le flux actuel d'Apple — un unique CNAME sig1 est correct.
- Casse l'authentification
Conservez exactement un seul enregistrement TXT SPF. Fusionnez include:icloud.com dans votre ligne v=spf1 existante ; deux enregistrements SPF distincts constituent un PermError automatique qui fait totalement échouer SPF.
- Couverture
Le domaine de messagerie personnalisé d'iCloud+ est une boîte aux lettres personnelle / pour petite équipe, pas un ESP. Apple plafonne le volume d'envoi et interdit le courrier de masse en gros et commercial, alors ne faites pas passer par lui vos campagnes marketing ou transactionnelles à fort volume — utilisez pour cela une plateforme d'envoi dédiée.
- Configuration DNS
Ne supprimez pas le TXT apple-domain après la configuration. Apple revérifie périodiquement la propriété du domaine à partir de celui-ci ; le retirer peut désactiver le domaine et couper votre courrier.
Construisez votre enregistrement SPF
Apple iCloud+ Custom Email Domain est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Apple iCloud+ Custom Email Domain — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.