Le domaine personnalisé d’iCloud+ se configure en quelques enregistrements, dont un qui mérite qu’on s’y arrête : l’assistant d’Apple propose un SPF en redirect=, un mécanisme qui ne se comporte pas du tout comme un include.
MX
@ MX 10 mx01.mail.icloud.com
@ MX 10 mx02.mail.icloud.comSPF, et le piège du redirect
Apple propose : v=spf1 redirect=icloud.com. Ça fonctionne — si iCloud est votre seul expéditeur. Car redirect= ne s’ajoute pas aux autres mécanismes : il remplace l’évaluation entière par celle du domaine visé. Tout ce que vous auriez listé à côté est ignoré, et vos autres services d’envoi tombent.
Dès qu’un second expéditeur existe — facturation, newsletter, formulaire du site — passez à la forme additive :
v=spf1 include:icloud.com ~allDKIM
Un CNAME, dont la valeur contient votre propre domaine :
sig1._domainkey CNAME sig1.dkim.votredomaine.com.at.icloudmailadmin.comDMARC
Publiez la politique en observation sur _dmarc.votredomaine.com :
v=DMARC1; p=none; rua=mailto:votre-adresse@votredomaine.comDurcissez seulement une fois tous vos expéditeurs identifiés. La progression, palier par palier.
Erreurs fréquentes avec iCloud Mail
- Le
redirect=conservé alors qu’un autre service envoie. L’erreur est invisible dans l’enregistrement — il est syntaxiquement parfait — et ne se voit que dans les rapports. - Une durée de vie autre que 3600. Apple exige exactement une heure sur ses enregistrements ; une autre valeur fait échouer la validation, sans message explicite.
- Le proxy Cloudflare laissé actif sur le CNAME DKIM. Le nuage orange doit être désactivé, sinon la cible renvoyée n’est pas celle d’Apple.
- Confondre alias et domaine personnalisé. Les adresses masquées d’iCloud n’utilisent pas votre domaine et ne relèvent pas de votre DMARC.
Une fois en place, Clarsend lit vos rapports et vous montre ce qui passe, ce qui échoue, et qui envoie sans que vous le sachiez.