SPF, DKIM & DMARC para Apple iCloud+ Custom Email Domain.
O Domínio de E-mail Personalizado do iCloud+ da Apple permite que você envie e receba mensagens no seu próprio domínio (voce@seudominio.com) pelo iCloud Mail, autenticando esse tráfego com um conjunto de registros DNS que a Apple gera para você durante a configuração: dois registros MX que entregam toda a sua caixa de e-mail ao iCloud, um TXT apple-domain que comprova a propriedade do domínio, um registro SPF que adiciona o include:icloud.com compartilhado da Apple e um único CNAME de DKIM (sig1._domainkey) que delega a assinatura à Apple. Não há nenhuma chave pública de DKIM para colar e nada para rotacionar — a Apple mantém a chave privada por trás desse CNAME. O único registro que a Apple NÃO gera é o DMARC; essa é a peça que você adiciona por conta própria para transformar SPF e DKIM em proteção real contra spoofing.
Por que autenticar o Apple iCloud+ Custom Email Domain?
Acertar esses registros no iCloud tem risco maior do que em um serviço puramente de envio, porque o Domínio de E-mail Personalizado transforma o iCloud no host da sua caixa de e-mail, e não apenas em um relay de saída — a mesma mudança de MX que permite enviar também redireciona toda mensagem de entrada do domínio para a Apple. Configure errado e você não apenas cai no spam, você deixa de receber e-mails. No lado da entregabilidade, as regras modernas continuam valendo: desde fevereiro de 2024, Gmail e Yahoo exigem que todo remetente passe em SPF ou DKIM (e que remetentes em massa também publiquem DMARC com alinhamento), e a Microsoft começou a aplicar verificações semelhantes para remetentes de alto volume em 2025. O iCloud é um dos bons casos aqui — porque ele é o host real da sua caixa de e-mail, o tráfego de saída é assinado com DKIM como seu domínio e o SPF resolve pelos IPs autorizados da Apple, então ambos os mecanismos podem alinhar com seudominio.com e alimentar uma aprovação de DMARC. Mas a Apple só publica SPF e DKIM; até você adicionar o registro DMARC por conta própria, os receptores não têm política a aplicar e seu domínio continua passível de spoofing. Observe também que o Domínio de E-mail Personalizado do iCloud+ é uma caixa de e-mail pessoal / de equipe pequena (qualquer plano pago de armazenamento do iCloud+ o inclui), e não uma plataforma de marketing ou transacional — autentique-o como sua caixa de e-mail humana e mantenha os envios em massa em um ESP dedicado.
A realidade do SPF para o Apple iCloud+ Custom Email Domain
O iCloud é um provedor "include" genuíno: você adiciona um único mecanismo compartilhado, include:icloud.com, ao único registro SPF TXT do seu domínio raiz, e o assistente de configuração da Apple o escreve como v=spf1 include:icloud.com ~all. Essa parte é padrão. O que quase todo guia erra é o custo. include:icloud.com NÃO é um include barato de uma consulta — é um dos includes compartilhados mais caros de uso comum. Ao resolvê-lo, o registro SPF do icloud.com é v=spf1 redirect=_spf.icloud.com; esse redirect aponta para _spf.icloud.com, cujo registro é v=spf1 include:_nets0.icloud.com include:_nets1.icloud.com include:_nets2.icloud.com ~all (cada registro _nets contém apenas faixas ip4/ip6, então a cadeia para aí). Contabilizando pela RFC 7208, isso é o include em si (1) + o redirect (1) + três includes _nets aninhados (3) = CINCO das suas 10 consultas DNS de SPF permitidas, gastas só com o iCloud. Se você também envia pelo Google Workspace, Microsoft 365 ou SendGrid, pode estourar o PermError de 10 consultas rapidamente, então trate o include do iCloud como um item pesado no orçamento e mantenha o resto do seu SPF enxuto. Mais duas regras: mantenha exatamente um registro SPF no domínio (mescle include:icloud.com na sua linha v=spf1 existente em vez de publicar um segundo TXT — dois registros SPF geram um PermError automático) e não confunda a forma include com a forma redirect=icloud.com que alguns tutoriais mais antigos mostram. redirect=icloud.com substitui toda a sua política SPF pela da Apple e descarta silenciosamente qualquer outro remetente (e custa as mesmas 5 consultas, então não traz nenhum benefício), portanto só é correto se o iCloud for a ÚNICA coisa que envia como seu domínio. A Apple termina com ~all (softfail), que é o padrão certo enquanto você confirma que todo remetente está coberto.
Duas maneiras de configurar
include:icloud.com (padrão da Apple — mantém os outros remetentes)
- O que o assistente de configuração da Apple de fato gera: v=spf1 include:icloud.com ~all
- Coexiste com outros remetentes — você pode mesclar Google Workspace, M365, SendGrid, etc. na mesma linha
- Custa 5 das suas 10 consultas DNS de SPF (redirect + três includes _nets aninhados), então planeje-se de acordo
- Termina em ~all softfail, o padrão seguro enquanto você confirma que todo remetente está autorizado
redirect=icloud.com (apenas se o iCloud for seu ÚNICO remetente)
- Substitui TODA a sua política SPF pela da Apple — qualquer coisa que não esteja no registro do icloud.com sofre hard-fail
- Quebra silenciosamente qualquer outro serviço que envie como seu domínio (newsletters, formulários, CRM)
- Sem economia de consultas — resolve a mesma cadeia de 5 consultas do icloud.com, só que sem nenhuma flexibilidade
- Use apenas em um domínio onde o iCloud Mail é a única e exclusiva fonte de envio
Passo a passo
- 1
Confirme que você tem o iCloud+
O Domínio de E-mail Personalizado é um recurso do iCloud+, então você precisa de qualquer plano pago do iCloud+ (qualquer plano de armazenamento serve). O organizador da conta pode compartilhar um domínio com os membros do Compartilhamento Familiar, ou você pode configurá-lo só para você.
- 2
Abra o Domínio de E-mail Personalizado
Na web, faça login em icloud.com, abra as configurações de Conta/Mail e escolha Domínio de E-mail Personalizado (icloud.com/settings o lista diretamente). No iPhone/iPad: Ajustes → toque no seu nome → iCloud → role até Domínio de E-mail Personalizado em Recursos do iCloud+.
- 3
Adicione seu domínio
Escolha se o domínio é para "Apenas você" ou "Você e outras pessoas" (Compartilhamento Familiar), depois digite seu domínio, por exemplo seudominio.com. O iCloud+ permite até 5 domínios, com até 3 endereços por pessoa por domínio.
- 4
Crie os endereços de e-mail que você vai usar
Adicione as caixas de e-mail que você quer no domínio (voce@seudominio.com, ola@seudominio.com, …). A Apple não publica as instruções de DNS até você ter definido pelo menos um endereço — isso é uma migração de caixa de e-mail, não apenas assinatura de saída, então decida seus endereços de antemão.
- 5
Obtenha seus registros DNS
A Apple mostra os registros a adicionar — dois MX, um valor de verificação TXT apple-domain, a linha de SPF e o CNAME de DKIM sig1._domainkey. Use "Instruções por e-mail" para enviá-los a si mesmo, ou copie cada valor. As instruções da Apple listam um TTL de 3600 (1 hora); qualquer TTL padrão serve.
- 6
Reaponte o MX para o iCloud
No seu host de DNS, REMOVA quaisquer registros MX existentes e adicione mx01.mail.icloud.com e mx02.mail.icloud.com, ambos com prioridade 10. Este é o passo crítico: ele move TODO o e-mail de entrada do domínio para o iCloud, então só faça isso quando estiver pronto para tornar o iCloud a caixa de e-mail desses endereços.
- 7
Adicione o TXT de verificação e o registro SPF
Na raiz (host @): adicione um registro TXT com o valor de verificação apple-domain=… da Apple e adicione ou MESCLE o registro SPF v=spf1 include:icloud.com ~all. Se já existir um registro v=spf1, incorpore include:icloud.com nessa única linha — nunca publique um segundo TXT de SPF.
- 8
Adicione o CNAME de DKIM
Crie um CNAME com host sig1._domainkey e destino sig1.dkim.seudominio.com.at.icloudmailadmin.com (a Apple substitui seu domínio real no destino). Se seu DNS está na Cloudflare, deixe-o como DNS only (nuvem cinza) — um registro com proxy/nuvem laranja ou o CNAME flattening quebra a resolução do DKIM.
- 9
Publique seu próprio registro DMARC
A Apple não cria o DMARC. Adicione um registro TXT no host _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com. p=none é só de monitoramento, então nada é bloqueado enquanto você confirma que o e-mail do iCloud passa em SPF e DKIM alinhados.
- 10
Conclua a configuração e teste uma mensagem real
De volta ao iCloud, clique em Concluir Configuração para a Apple verificar os registros (a propagação pode levar de minutos a algumas horas). Depois envie uma mensagem do seu novo endereço para uma conta do Gmail, abra ⋮ → Mostrar original e confirme SPF: PASS, DKIM: PASS (signed-by seudominio.com, seletor sig1) e DMARC: PASS. Envie também uma mensagem PARA o endereço para confirmar que o iCloud já está recebendo.
Registros a adicionar
O Apple iCloud+ Custom Email Domain gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| MX | @ | mx01.mail.icloud.comPrioridade 10 — redireciona todo o e-mail de entrada para o iCloud (remova os MX existentes primeiro) |
| MX | @ | mx02.mail.icloud.comPrioridade 10 — segundo servidor de e-mail do iCloud |
| TXT | @ | apple-domain=Ab12Cd34Ef56Gh78Ilustrativo — a Apple gera um valor de verificação único por domínio; mantenha-o publicado, a Apple o reverifica |
| TXT | @ | v=spf1 include:icloud.com ~allMescle na sua única linha de SPF, se houver uma. include:icloud.com custa 5 consultas DNS (redirect + 3 includes _nets aninhados) |
| CNAME | sig1._domainkey | sig1.dkim.yourdomain.com.at.icloudmailadmin.comIlustrativo — a Apple insere seu domínio real. A chave DKIM é mantida/rotacionada pela Apple; mantenha DNS-only (sem proxy da Cloudflare) |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê adiciona este — a Apple não. Um registro DMARC por domínio; comece em p=none, depois aperte |
Mantenha exatamente um registro TXT de SPF (v=spf1) no seu domínio raiz — combine todos os remetentes nele. Ter dois registros SPF já é, por si só, um erro.
O limite de 10 consultas de DNS
O SPF tem um limite rígido de 10 consultas de DNS — se passar disso, ele retorna um permerror e para de validar em todo lugar. Veja quanto a configuração do Apple iCloud+ Custom Email Domain consome desse limite.
O Apple iCloud+ Custom Email Domain usa 5 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM do iCloud é delegado, não colado. A Apple pede que você publique um único CNAME — host sig1._domainkey.seudominio.com apontando para sig1.dkim.seudominio.com.at.icloudmailadmin.com (a Apple substitui seu domínio real nesse destino durante a configuração). Não há nenhuma chave pública v=DKIM1; p=… para você copiar e nenhum seletor para inventar: a Apple mantém a chave privada por trás desse CNAME, assina seu tráfego de saída do iCloud com d=seudominio.com usando o seletor sig1 e pode rotacionar a chave publicada do lado dela sem você jamais editar o DNS de novo. Dois pontos práticos. Primeiro, o iCloud provisiona exatamente UM seletor, sig1 — se um tutorial mandar adicionar também o sig2, isso não faz parte do fluxo atual da Apple; um único CNAME sig1 é correto e completo. Segundo, por ser um CNAME para o hostname da Apple, ele precisa resolver como um registro delegado normal: se seu DNS está na Cloudflare, deixe-o como DNS only (nuvem cinza) e evite o CNAME flattening ou qualquer proxy que reescreva o destino, pois isso quebra a delegação e o DKIM silenciosamente deixa de assinar. O DKIM é o mecanismo que mais confiavelmente alinha com o seu domínio aqui (o d= é seudominio.com), então é ele que sustenta uma aprovação de DMARC mesmo quando uma mensagem é encaminhada e o SPF quebra — acerte esse CNAME.
DMARC
O DMARC é o registro que a Apple nunca cria para você e, sem ele, o SPF e o DKIM que você acabou de publicar não somam nenhuma política aplicável. Adicione um registro TXT em _dmarc.seudominio.com com v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com. p=none é só de monitoramento — não muda nada na entrega, mas pede que os receptores enviem por e-mail relatórios agregados (rua) para você acompanhar a autenticação do e-mail do iCloud. Como o iCloud assina com DKIM como seu próprio domínio e envia pelos IPs autorizados no SPF da Apple, você deve ver aprovações limpas e alinhadas rapidamente. Deixe os relatórios rodarem por uma ou duas semanas, confirme que o iCloud mais quaisquer outros remetentes legítimos (uma ferramenta de newsletter, um formulário de contato, outro provedor de caixa de e-mail) estão todos passando alinhados e então aperte para p=quarantine e finalmente p=reject para de fato barrar o spoofing. Mantenha exatamente um registro _dmarc para todo o domínio, independentemente de quantos serviços você usa — nunca adicione um segundo registro DMARC especificamente para o iCloud. Se você hospeda o DNS em um lugar que também permite receber os relatórios, aponte rua para uma caixa de e-mail que você realmente vai ler ou alimente-os em um analisador de DMARC.
Confirme que funcionou de verdade
Não confie apenas no sinal verde de "Concluir Configuração" da Apple — confirme a autenticação em uma mensagem real. Envie do seu novo endereço iCloud para uma conta do Gmail, abra a mensagem e escolha ⋮ → Mostrar original: você quer SPF: PASS, DKIM: PASS com signed-by: seudominio.com e seletor sig1, e DMARC: PASS — todos apontando para o seu domínio, não para icloud.com. Como o iCloud agora também é o seu host de recebimento, envie uma mensagem PARA o endereço também e certifique-se de que ela chega, o que comprova que a mudança de MX pegou. Para uma verificação crua, dig TXT seudominio.com deve mostrar o seu único v=spf1 include:icloud.com ~all, dig CNAME sig1._domainkey.seudominio.com deve resolver para sig1.dkim.seudominio.com.at.icloudmailadmin.com e dig TXT _dmarc.seudominio.com deve retornar a sua política. Depois passe o domínio pela verificação de saúde de domínio da Qualisend para confirmar que todo registro resolve e — importante para o iCloud — que o seu SPF permanece abaixo do limite de 10 consultas, dadas as 5 consultas que include:icloud.com consome. Assim que os relatórios agregados chegarem, jogue um deles no analisador de relatórios DMARC para confirmar que o iCloud aparece como uma fonte alinhada e totalmente aprovada.
Pegadinhas comuns
- Quebra a autenticação
include:icloud.com é caro: custa 5 das suas 10 consultas DNS de SPF, não 1. icloud.com faz redirect para _spf.icloud.com, que aninha _nets0/_nets1/_nets2.icloud.com. Empilhe-o com Google Workspace ou Microsoft 365 e você pode estourar o PermError de 10 consultas — mantenha o resto do seu SPF enxuto e cheque o medidor.
- Cobertura
Isto é uma migração completa de caixa de e-mail, não apenas assinatura de saída. Os registros mx01/mx02.mail.icloud.com redirecionam TODO o e-mail de entrada do domínio para o iCloud. Você não pode hospedar os mesmos endereços divididos entre o iCloud e outro provedor — só adicione o MX quando estiver pronto para o iCloud receber esse e-mail.
- Configuração de DNS
Use a forma include, não redirect=icloud.com. redirect substitui toda a sua política SPF pela da Apple e descarta silenciosamente qualquer outro remetente — e custa as mesmas 5 consultas, então não há vantagem. Só é correto quando o iCloud é o único e exclusivo remetente do domínio; caso contrário, seus formulários, newsletters e CRM começam a falhar no SPF.
- Configuração de DNS
O registro DKIM é um CNAME que você não pode colocar em proxy nem achatar. Na Cloudflare, deixe sig1._domainkey como DNS only (nuvem cinza); um proxy de nuvem laranja ou o CNAME flattening reescreve o destino e o DKIM para de assinar. A Apple mantém a chave — você nunca cola nem rotaciona uma chave pública.
- Configuração de DNS
A Apple publica SPF e DKIM, mas nunca DMARC. Sem o seu próprio registro _dmarc não há política a aplicar e o domínio continua passível de spoofing — adicione v=DMARC1; p=none para começar, depois aperte.
- Configuração de DNS
O iCloud provisiona um único seletor de DKIM (sig1). Se um guia mandar adicionar também o sig2, isso não é o fluxo atual da Apple — um único CNAME sig1 é correto.
- Quebra a autenticação
Mantenha exatamente um registro SPF TXT. Mescle include:icloud.com na sua linha v=spf1 existente; dois registros SPF separados geram um PermError automático que reprova o SPF por completo.
- Cobertura
O Domínio de E-mail Personalizado do iCloud+ é uma caixa de e-mail pessoal / de equipe pequena, não um ESP. A Apple limita o volume de envio e proíbe e-mails em massa e comerciais, então não roteie campanhas de marketing ou transacionais de alto volume por ele — use uma plataforma de envio dedicada para isso.
- Configuração de DNS
Não apague o TXT apple-domain após a configuração. A Apple reverifica a propriedade do domínio periodicamente com base nele; removê-lo pode desativar o domínio e derrubar seu e-mail.
Monte seu registro SPF
O Apple iCloud+ Custom Email Domain já vem pré-selecionado abaixo. Adicione as outras plataformas pelas quais você envia e publique o registro único e combinado.
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 do Apple iCloud+ Custom Email Domain — Perguntas frequentes
Leituras relacionadas
Depois de publicado, confirme se tudo resolve corretamente com o verificação de saúde do domínio e, em seguida, veja quem está enviando em seu nome com o analisador de relatórios DMARC. Explore todas as fontes de envio no gerador. A autenticação, porém, é só metade da entregabilidade — um IP ou domínio de envio que esteja listado ainda te joga no spam por mais limpo que seu SPF esteja, então vale a pena acompanhar as blacklists com o monitoramento de blacklists.
Autenticado — agora mantenha a lista limpa
Passar em SPF, DKIM e DMARC te leva à caixa de entrada; uma lista limpa te mantém lá. Verifique a sua — comece grátis com 100 créditos, sem precisar de cartão.