Skip to content
Inizia con 100 crediti di verifica gratuiti
Qualisend
Guida alla configurazione SPF

SPF, DKIM e DMARC per Apple iCloud+ Custom Email Domain.

Custom Email Domain di iCloud+ ti permette di inviare e ricevere posta con il tuo dominio (you@yourdomain.com) tramite iCloud Mail, e autentica quella posta con una serie di record DNS che Apple genera per te durante la configurazione: due record MX che affidano a iCloud l'intera casella, un TXT apple-domain che dimostra che il dominio è tuo, un record SPF che aggiunge l'include condiviso di Apple include:icloud.com e un unico CNAME DKIM (sig1._domainkey) che delega la firma ad Apple. Non c'è una chiave pubblica DKIM da incollare né nulla da ruotare: la chiave privata dietro quel CNAME la conserva Apple. L'unico record che Apple NON genera è DMARC: è il tassello che aggiungi tu per trasformare SPF e DKIM in una vera protezione contro lo spoofing.

Include SPF
Your DNSAdd the CNAME / TXT records
Apple iCloud+ Custom Email DomainSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Perché autenticare Apple iCloud+ Custom Email Domain?

Configurare correttamente questi record su iCloud conta più che su un semplice servizio di invio, perché Custom Email Domain rende iCloud il provider della tua casella, non solo un relay in uscita: la stessa modifica MX che ti permette di inviare reindirizza ad Apple anche ogni messaggio in arrivo per il dominio. Se sbagli la configurazione non finisci soltanto nello spam: smetti di ricevere posta. Sul fronte della deliverability valgono comunque le regole attuali: da febbraio 2024 Gmail e Yahoo richiedono a ogni mittente di superare SPF o DKIM (e ai mittenti di grandi volumi di pubblicare anche DMARC con allineamento), e nel 2025 Microsoft ha iniziato ad applicare controlli simili ai mittenti di grandi volumi. iCloud è uno dei casi favorevoli: poiché è il vero provider della tua casella, la posta in uscita viene firmata con DKIM a nome del tuo dominio e SPF si risolve tramite gli IP autorizzati di Apple, quindi entrambi i meccanismi possono allinearsi a yourdomain.com e far superare DMARC. Apple però pubblica soltanto SPF e DKIM: finché non aggiungi tu il record DMARC, i server riceventi non hanno alcuna policy da applicare e il tuo dominio resta esposto allo spoofing. Tieni presente anche che Custom Email Domain di iCloud+ è una casella per uso personale o per piccoli team (è inclusa in qualsiasi piano di archiviazione iCloud+ a pagamento), non una piattaforma di marketing o transazionale: autenticala come casella personale e lascia gli invii di massa a un ESP dedicato.

Come funziona davvero SPF con Apple iCloud+ Custom Email Domain

iCloud è un vero provider “include”: aggiungi un unico meccanismo condiviso, include:icloud.com, all'unico record TXT SPF del dominio radice, e la procedura guidata di Apple lo scrive come v=spf1 include:icloud.com ~all. Questa parte è standard. Quello che quasi tutte le guide sbagliano è il costo. include:icloud.com NON è un include economico da una sola ricerca: è uno degli include condivisi più costosi tra quelli di uso comune. Se lo risolvi, scopri che il record SPF di icloud.com è v=spf1 redirect=_spf.icloud.com; quel redirect punta a _spf.icloud.com, il cui record è v=spf1 include:_nets0.icloud.com include:_nets1.icloud.com include:_nets2.icloud.com ~all (ogni record _nets contiene solo intervalli ip4/ip6, quindi la catena si ferma lì). Contando secondo la RFC 7208, sono l'include stesso (1) + il redirect (1) + tre include _nets annidati (3) = CINQUE delle 10 ricerche DNS SPF consentite, spese solo per iCloud. Se invii anche tramite Google Workspace, Microsoft 365 o SendGrid, puoi sforare rapidamente il limite di 10 ricerche e ottenere un PermError: considera quindi l'include di iCloud una voce pesante e mantieni snello il resto del tuo SPF. Altre due regole: tieni esattamente un record SPF sul dominio (unisci include:icloud.com alla riga v=spf1 esistente invece di pubblicare un secondo TXT, perché due record SPF producono automaticamente un PermError) e non confondere la forma include con la forma redirect=icloud.com che mostrano alcuni tutorial più vecchi. redirect=icloud.com sostituisce l'intera policy SPF con quella di Apple ed esclude silenziosamente tutti gli altri mittenti (e costa le stesse 5 ricerche, quindi non ti fa guadagnare nulla): è corretto solo se iCloud è l'UNICO servizio che invia a nome del tuo dominio. Apple termina con ~all (softfail), l'impostazione predefinita giusta mentre verifichi che ogni mittente sia coperto.

Due modi per configurarlo

Consigliato

include:icloud.com (predefinito di Apple, mantiene gli altri mittenti)

  • Quello che la procedura guidata di Apple genera davvero: v=spf1 include:icloud.com ~all
  • Convive con gli altri mittenti: puoi unire Google Workspace, M365, SendGrid ecc. nella stessa riga
  • Costa 5 delle tue 10 ricerche DNS SPF (redirect + tre include _nets annidati): pianifica di conseguenza
  • Termina con ~all (softfail), l'impostazione predefinita sicura mentre verifichi che ogni mittente sia autorizzato
Legacy

redirect=icloud.com (solo se iCloud è il tuo UNICO mittente)

  • Sostituisce TUTTA la tua policy SPF con quella di Apple: tutto ciò che non è nel record di icloud.com va in hard fail
  • Rompe silenziosamente qualsiasi altro servizio che invia a nome del tuo dominio (newsletter, moduli, CRM)
  • Nessun risparmio di ricerche: risolve la stessa catena da 5 ricerche di icloud.com, solo senza alcuna flessibilità
  • Usalo solo su un dominio in cui iCloud Mail è l'unica ed esclusiva fonte di invio

Passo dopo passo

Nelle impostazioni di iCloud
  1. 1

    Controlla di avere iCloud+

    Custom Email Domain è una funzione di iCloud+, quindi ti serve un qualsiasi piano iCloud+ a pagamento (va bene qualunque piano di archiviazione). L'organizzatore dell'account può condividere un dominio con i membri di Family Sharing, oppure puoi configurarlo solo per te.

  2. 2

    Apri Custom Email Domain

    Sul web, accedi a icloud.com, apri le impostazioni Account/Mail e scegli Custom Email Domain (icloud.com/settings la mostra direttamente). Su iPhone/iPad: Settings → tocca il tuo nome → iCloud → scorri fino a Custom Email Domain sotto iCloud+ Features.

  3. 3

    Aggiungi il dominio

    Scegli se il dominio è per “Only you” o per “You and other people” (Family Sharing), poi digita il dominio, ad esempio yourdomain.com. iCloud+ consente fino a 5 domini, e fino a 3 indirizzi per persona su ciascun dominio.

  4. 4

    Crea gli indirizzi email che userai

    Aggiungi le caselle che vuoi sul dominio (you@yourdomain.com, hello@yourdomain.com, …). Apple non pubblica le istruzioni DNS finché non hai definito almeno un indirizzo: si tratta di una migrazione della casella, non solo della firma della posta in uscita, quindi decidi gli indirizzi fin dall'inizio.

  5. 5

    Ottieni i record DNS

    Apple mostra i record da aggiungere: due MX, un valore TXT di verifica apple-domain, la riga SPF e il CNAME DKIM sig1._domainkey. Usa “Email instructions” per inviarteli via email, oppure copia ogni valore. Le istruzioni di Apple indicano un TTL di 3600 (1 ora); va bene qualsiasi TTL standard.

Nel tuo DNS
  1. 6

    Fai puntare gli MX a iCloud

    Presso il tuo provider DNS, RIMUOVI tutti i record MX esistenti e aggiungi mx01.mail.icloud.com e mx02.mail.icloud.com, entrambi con priorità 10. Questo è il passaggio più importante: sposta su iCloud TUTTA la posta in arrivo del dominio, quindi fallo solo quando vuoi che iCloud diventi la casella per questi indirizzi.

  2. 7

    Aggiungi il TXT di verifica e il record SPF

    Sul dominio radice (host @) aggiungi un record TXT con il valore di verifica apple-domain=… di Apple, e aggiungi o UNISCI il record SPF v=spf1 include:icloud.com ~all. Se esiste già un record v=spf1, inserisci include:icloud.com in quell'unica riga: non pubblicare mai un secondo TXT SPF.

  3. 8

    Aggiungi il CNAME DKIM

    Crea un CNAME con host sig1._domainkey e destinazione sig1.dkim.yourdomain.com.at.icloudmailadmin.com (Apple inserisce il tuo vero dominio nella destinazione). Se il tuo DNS è su Cloudflare, impostalo su DNS only (nuvola grigia): un record con proxy attivo (nuvola arancione) o il CNAME flattening impediscono la risoluzione di DKIM.

  4. 9

    Pubblica il tuo record DMARC

    Apple non crea DMARC. Aggiungi un record TXT sull'host _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio, quindi non viene bloccato nulla mentre verifichi che la posta iCloud superi SPF e DKIM con allineamento.

Verifica
  1. 10

    Completa la configurazione e prova un messaggio reale

    Torna in iCloud e fai clic su Finish Setup per far verificare i record ad Apple (la propagazione può richiedere da pochi minuti a qualche ora). Poi invia un messaggio dal tuo nuovo indirizzo a un account Gmail, apri ⋮ → Show original e controlla SPF: PASS, DKIM: PASS (signed-by yourdomain.com, selettore sig1) e DMARC: PASS. Invia anche un messaggio A quell'indirizzo per confermare che ora iCloud riceve la posta.

Record da aggiungere

Apple iCloud+ Custom Email Domain genera i valori esatti nella sua procedura guidata di configurazione: questi mostrano la struttura di ciò che aggiungerai presso il tuo provider DNS.

TipoHostValore
MX@mx01.mail.icloud.comPriorità 10: reindirizza a iCloud tutta la posta in arrivo (rimuovi prima gli MX esistenti)
MX@mx02.mail.icloud.comPriorità 10: secondo server di posta (mail exchanger) di iCloud
TXT@apple-domain=Ab12Cd34Ef56Gh78Valore di esempio: Apple genera un valore di verifica univoco per ogni dominio; lascialo pubblicato, perché Apple lo ricontrolla
TXT@v=spf1 include:icloud.com ~allUniscilo alla tua unica riga SPF, se esiste già. include:icloud.com costa 5 ricerche DNS (redirect + 3 include _nets annidati)
CNAMEsig1._domainkeysig1.dkim.yourdomain.com.at.icloudmailadmin.comValore di esempio: Apple inserisce il tuo vero dominio. La chiave DKIM è conservata e ruotata da Apple; lascia il record in DNS only (niente proxy Cloudflare)
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comQuesto lo aggiungi tu, Apple no. Un solo record DMARC per dominio; parti da p=none, poi rendilo più restrittivo

Tieni esattamente un record TXT SPF (v=spf1) sul dominio radice e unisci al suo interno tutti i mittenti. Avere due record SPF è di per sé un errore.

Il limite di 10 ricerche DNS

SPF ha un tetto fisso di 10 ricerche DNS: se lo superi, restituisce un permerror e smette di essere valido ovunque. Ecco quanto consuma di questo budget la configurazione di Apple iCloud+ Custom Email Domain.

SPF 10-lookup budget5 used · 5 free

Apple iCloud+ Custom Email Domain occupa 5 delle tue 10 ricerche; i meccanismi ip4: e ip6: non consumano ricerche.

DKIM

Su iCloud DKIM è delegato, non incollato. Apple ti fa pubblicare un unico CNAME: l'host sig1._domainkey.yourdomain.com che punta a sig1.dkim.yourdomain.com.at.icloudmailadmin.com (durante la configurazione Apple inserisce il tuo vero dominio in quella destinazione). Non c'è una chiave pubblica v=DKIM1; p=… da copiare né un selettore da inventare: Apple conserva la chiave privata dietro quel CNAME, firma la tua posta iCloud in uscita con d=yourdomain.com usando il selettore sig1 e può ruotare la chiave pubblicata dal proprio lato senza che tu debba più modificare il DNS. Due aspetti pratici. Primo: iCloud crea esattamente UN selettore, sig1. Se un tutorial ti dice di aggiungere anche sig2, non fa parte dell'attuale procedura di Apple: un solo CNAME sig1 è corretto e completo. Secondo: poiché è un CNAME verso un hostname di Apple, deve risolversi come un normale record delegato. Se il tuo DNS è su Cloudflare impostalo su DNS only (nuvola grigia) ed evita il CNAME flattening o qualsiasi proxy che riscriva la destinazione: romperebbe la delega e DKIM smetterebbe di firmare senza alcun avviso. Qui DKIM è il meccanismo che si allinea al tuo dominio in modo più affidabile (il d= è yourdomain.com), quindi è quello che permette di superare DMARC anche quando un messaggio viene inoltrato e SPF si rompe: assicurati che questo CNAME sia corretto.

DMARC

DMARC è il record che Apple non crea mai per te, e senza di esso SPF e DKIM appena pubblicati non si traducono in alcuna policy applicabile. Aggiungi un record TXT su _dmarc.yourdomain.com con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio: non cambia nulla nel recapito, ma chiede ai server riceventi di inviarti i report aggregati (rua), così puoi vedere la posta iCloud superare l'autenticazione. Poiché iCloud firma con DKIM a nome del tuo dominio e invia tramite gli IP autorizzati dal record SPF di Apple, dovresti vedere presto risultati puliti e allineati. Lascia scorrere i report per una o due settimane, verifica che iCloud e tutti gli altri mittenti legittimi (uno strumento per newsletter, un modulo di contatto, un altro provider di posta) superino i controlli con allineamento, poi passa a p=quarantine e infine a p=reject per bloccare davvero lo spoofing. Tieni esattamente un record _dmarc per l'intero dominio, a prescindere da quanti servizi usi: non aggiungere mai un secondo record DMARC apposta per iCloud. Se il tuo DNS è ospitato presso un servizio che ti permette anche di ricevere i report, fai puntare rua a una casella che leggerai davvero, oppure invia i report a un analizzatore DMARC.

Verifica che funzioni davvero

Non fidarti solo della spunta verde di “Finish Setup” di Apple: conferma l'autenticazione su un messaggio reale. Invia un'email dal tuo nuovo indirizzo iCloud a un account Gmail, apri il messaggio e scegli ⋮ → Show original: devi vedere SPF: PASS, DKIM: PASS con signed-by: yourdomain.com e selettore sig1, e DMARC: PASS, tutti riferiti al tuo dominio e non a icloud.com. Poiché ora iCloud riceve anche la tua posta, invia pure un messaggio A quell'indirizzo e controlla che arrivi: è la prova che la modifica MX è andata a buon fine. Per un controllo diretto, dig TXT yourdomain.com deve mostrare il tuo unico v=spf1 include:icloud.com ~all, dig CNAME sig1._domainkey.yourdomain.com deve risolversi in sig1.dkim.yourdomain.com.at.icloudmailadmin.com e dig TXT _dmarc.yourdomain.com deve restituire la tua policy. Poi analizza il dominio con il check-up del dominio di Qualisend per confermare che ogni record si risolva e, cosa importante per iCloud, che il tuo SPF resti sotto il limite di 10 ricerche, viste le 5 consumate da include:icloud.com. Quando arrivano i report aggregati, caricane uno nell'Analizzatore di report DMARC per confermare che iCloud compaia come sorgente allineata che supera tutti i controlli.

Insidie comuni

  • Fa fallire l'autenticazione

    include:icloud.com è costoso: occupa 5 delle tue 10 ricerche DNS SPF, non 1. icloud.com fa un redirect a _spf.icloud.com, che annida _nets0/_nets1/_nets2.icloud.com. Combinalo con Google Workspace o Microsoft 365 e rischi di sforare il limite di 10 ricerche con un PermError: mantieni snello il resto del tuo SPF e tieni d'occhio il contatore.

  • Copertura

    Si tratta di una migrazione completa della casella, non solo della firma della posta in uscita. I record mx01/mx02.mail.icloud.com reindirizzano a iCloud TUTTA la posta in arrivo del dominio. Non puoi dividere gli stessi indirizzi tra iCloud e un altro provider: aggiungi gli MX solo quando vuoi che sia iCloud a ricevere quella posta.

  • Configurazione DNS

    Usa la forma include, non redirect=icloud.com. redirect sostituisce l'intera policy SPF con quella di Apple ed esclude silenziosamente tutti gli altri mittenti; inoltre costa le stesse 5 ricerche, quindi non porta alcun vantaggio. È corretto solo quando iCloud è l'unico ed esclusivo mittente del dominio; altrimenti moduli, newsletter e CRM iniziano a non superare SPF.

  • Configurazione DNS

    Il record DKIM è un CNAME che non devi mettere dietro proxy né appiattire. Su Cloudflare imposta sig1._domainkey su DNS only (nuvola grigia): un proxy a nuvola arancione o il CNAME flattening riscrivono la destinazione e DKIM smette di firmare. La chiave la conserva Apple: non devi mai incollare né ruotare una chiave pubblica.

  • Configurazione DNS

    Apple pubblica SPF e DKIM, ma mai DMARC. Senza un tuo record _dmarc non c'è alcuna policy da applicare e il dominio resta esposto allo spoofing: aggiungi v=DMARC1; p=none per iniziare, poi rendilo più restrittivo.

  • Configurazione DNS

    iCloud crea un solo selettore DKIM (sig1). Se una guida dice di aggiungere anche sig2, non è l'attuale procedura di Apple: un solo CNAME sig1 è corretto.

  • Fa fallire l'autenticazione

    Tieni esattamente un record TXT SPF. Unisci include:icloud.com alla riga v=spf1 esistente: due record SPF separati producono automaticamente un PermError che fa fallire del tutto SPF.

  • Copertura

    Custom Email Domain di iCloud+ è una casella per uso personale o per piccoli team, non un ESP. Apple limita il volume di invio e vieta gli invii di massa e commerciali, quindi non far passare da lì campagne di marketing o transazionali ad alto volume: usa una piattaforma di invio dedicata.

  • Configurazione DNS

    Non eliminare il TXT apple-domain dopo la configurazione. Apple ricontrolla periodicamente la proprietà del dominio in base a quel record; rimuoverlo può disattivare il dominio e bloccare la tua posta.

Crea il tuo record SPF

Apple iCloud+ Custom Email Domain è già preselezionato qui sotto. Aggiungi le altre piattaforme con cui invii, poi pubblica l'unico record unificato.

1

Fonti di invio

Cerca ogni piattaforma con cui invii email e selezionala.

Selezionati
Guida →
2

Server propri del dominio

Autorizza il dominio stesso, se invia posta direttamente (non tramite una delle piattaforme sopra).

3

Altri mittenti e IP

Tutto ciò che non è nella lista: l'host SPF di un altro provider o indirizzi IP specifici.

Aggiungiamo noi il prefisso include:. Inserisci l'hostname indicato nella documentazione del provider.

4

Policy per tutti gli altri

Cosa devono fare i server riceventi con la posta proveniente da server non elencati sopra (il meccanismo all).

Il tuo record SPF1/10 ricerche DNS
v=spf1 include:icloud.com ~all
  • Pubblicalo come record TXT sul dominio radice: host @ (il dominio senza prefissi), come valore l'intera stringa qui sopra.
  • Tieni un solo record SPF per dominio. Unisci tutte le fonti di invio in quest'unica riga. Un secondo record TXT che inizia con v=spf1 li rende entrambi non validi.
  • Resta entro le 10 ricerche DNS. Contano come ricerche include:, a e mx, e un include può innescarne altre al suo interno; ip4: e ip6: sono gratuiti.

Autenticazione pubblicata? Il passo successivo è inviare a una lista pulita e verificata.

Verifica una lista

SPF per Apple iCloud+ Custom Email Domain: domande frequenti

Letture correlate

Dopo la pubblicazione, controlla con il check-up del dominio che tutti i record vengano risolti correttamente, poi scopri con l'analizzatore di report DMARC chi invia a tuo nome. Sfoglia tutte le fonti di invio nel generatore. L'autenticazione, però, è solo metà della deliverability: un IP o un dominio di invio in blacklist ti manda comunque nello spam, per quanto pulito sia il tuo SPF, quindi conviene tenere d'occhio le blacklist con il monitoraggio blacklist.

Dominio autenticato: ora mantieni pulita la lista

Superare SPF, DKIM e DMARC ti porta nella posta in arrivo; una lista pulita ti ci fa restare. Verifica la tua: inizia gratis con 100 crediti, senza carta di credito.

Inizia a verificare