O aplicativo registra o envio como concluído, mas a caixa de destino continua vazia.

Solução mais rápida: confira se a origem real do e-mail está cadastrada para o relay privado da Apple e se SPF e/ou DKIM atendem às exigências aplicáveis; depois verifique o encaminhamento do endereço de teste e a caixa de destino. Um log de envio ou uma notificação de falha ajuda a localizar o trecho do fluxo, mas não prova, por si só, que a mensagem chegou à caixa pessoal.

Este guia é para quem mantém o fluxo de e-mail de um site ou aplicativo próprio integrado ao Sign in with Apple.
Também serve para QA que valida login e verificação de endereço, e para quem administra os domínios de envio.
O diagnóstico abaixo se limita a testes de produtos próprios ou a contas usadas com autorização.

E-mails encaminhados pelo Sign in with Apple não chegam: identifique o trecho que falhou

“Enviado” pode descrever etapas diferentes. A aplicação pode ter criado a mensagem; o serviço de envio pode tê-la aceitado; o relay privado da Apple pode tê-la processado ou recusado; e a caixa pessoal pode tê-la recebido, filtrado ou rejeitado. Tratar esses eventos como sinônimos transforma uma investigação simples em tentativa e erro.

Comece reunindo evidências para cada etapa, sem concluir que a mensagem chegou só porque a aplicação não apresentou erro. A documentação da Apple explica que mensagens destinadas a usuários que escolheram ocultar o e-mail dependem da configuração do serviço de relay privado e das origens de envio cadastradas (orientações oficiais para configurar o relay privado).

Essa separação também evita um falso positivo em QA: uma tela de sucesso pode confirmar apenas que a aplicação concluiu uma etapa interna. Para fechar o teste, associe o evento de envio à observação do endereço de destino e ao estado esperado da conta.

Origem cadastrada e endereço real: compare antes de alterar o fluxo

A primeira verificação de configuração é confrontar o endereço e o domínio efetivamente usados no envio com as origens informadas no ambiente de desenvolvedor da Apple. Não basta olhar apenas o endereço que aparece na interface do produto. Um sistema pode enviar por um domínio, subdomínio ou endereço específico diferente daquele esperado pela equipe.

Na configuração do relay, confira se a origem de envio cadastrada corresponde à rota real usada pela aplicação e pelo serviço de e-mail. A Apple documenta o cadastro de origens para encaminhar mensagens a usuários que ocultaram seus endereços; consulte a configuração oficial do serviço de relay privado e compare os valores atuais no ambiente da sua conta.

A associação com uma conta ou ambiente não autoriza concluir que qualquer endereço remetente será aceito. Também não é seguro deduzir uma mensagem de erro específica quando uma origem não corresponde: registre a configuração e os eventos disponíveis, corrija o que estiver inconsistente e execute novamente o teste autorizado.

A documentação de configuração do ambiente do Sign in with Apple ajuda a entender como as definições do ambiente se relacionam com a integração. Use-a como referência para revisar a configuração, não como prova de que uma mensagem específica foi encaminhada.

SPF ou DKIM: autenticação correta depende da rota de envio

Uma origem cadastrada ainda pode falhar na verificação de autenticação. A Apple informa que o envio para usuários que optaram por ocultar o endereço requer o cadastro das origens e a validação por SPF e/ou DKIM conforme os requisitos documentados. Portanto, não trate a existência de um registro DNS como prova suficiente: confronte a mensagem real, a rota de saída e os domínios envolvidos com a orientação oficial do relay.

Se a aplicação delega o envio a uma infraestrutura de terceiros, investigue o que essa infraestrutura realmente colocou na mensagem e como assinou o e-mail. A configuração planejada pode não corresponder ao tráfego produzido. Examine os cabeçalhos completos da mensagem de teste, os resultados de autenticação registrados e o domínio relacionado à assinatura ou à política SPF. Compare esses dados com o guia oficial de configuração do relay privado.

Não altere SPF e DKIM às cegas para “forçar” a entrega. Registre o estado anterior, identifique qual sistema enviou a mensagem e valide a mudança com uma nova mensagem de teste; assim, a equipe consegue relacionar a alteração ao resultado observado.

Para investigar private.icloud.com em testes de e-mail, preserve o contexto da mensagem e confira o que aparece nos cabeçalhos e nos registros do seu ambiente. A Apple anunciou uma atualização relacionada ao novo domínio do serviço de relay em sua notícia oficial para desenvolvedores. Esse anúncio não deve ser interpretado como prova de que todos os endereços antigos foram migrados, nem como confirmação de que um endereço específico recebeu uma mensagem. Não transforme uma mudança de domínio em atalho para diagnosticar falhas de autenticação.

Notificação de falha e caixa vazia: use cada pista no limite certo

Quando a Apple informa que não conseguiu entregar uma mensagem, trate a notificação como uma pista da rota de relay, não como recibo da caixa pessoal. A documentação da Apple descreve as notificações de mensagens não entregues e o funcionamento do relay; a página de ajuda sobre e-mails ocultos no Sign in with Apple também ajuda a contextualizar o endereço privado e o encaminhamento.

Em seguida, inspecione o destino configurado para o endereço de relay usado no teste. Verifique se o encaminhamento continua ativo, se o endereço pessoal associado está correto e se regras locais não estão movendo ou descartando a mensagem. Confira também a pasta de spam e os filtros definidos na caixa de destino. Uma caixa vazia pode refletir filtros ou configuração do destino, mas não permite afirmar, sem evidência adicional, qual foi a causa.

Para a verificação de recebimento em endereços privaterelay.appleid.com, registre qual endereço foi usado, qual mensagem foi gerada e quais eventos de envio ou notificação apareceram. Se a equipe alterou recentemente a conta ou o endereço associado, a documentação da Apple sobre processamento de mudanças em contas do Sign in with Apple é uma referência para entender as mudanças que podem afetar os dados da conta. Não conclua que uma mudança ocorreu apenas porque a entrega falhou.

A distinção operacional é direta: uma notificação de não entrega informa algo sobre o processamento do relay; um log do seu sistema informa o que ele observou no envio; e a mensagem visível na caixa de destino comprova o recebimento naquela caixa. Se faltar a última evidência, mantenha o caso como não confirmado e continue a investigação.

Roteiro de triagem: corrija uma variável por vez

A sequência abaixo reduz o risco de mudar várias configurações e perder a causa do problema. Execute-a em conta de teste própria ou autorizada e guarde evidências sem expor dados pessoais desnecessários.

  • [ ] Reproduza o problema no fluxo de teste e anote a conta autorizada, o endereço de relay usado e o tipo de mensagem.
  • [ ] Registre o horário observado nos sistemas envolvidos e o identificador disponível para correlacionar o evento, sem inventar um prazo de entrega esperado.
  • [ ] Confirme se a aplicação gerou a mensagem e se o sistema de envio registrou aceitação, rejeição ou outro resultado.
  • [ ] Compare o remetente efetivo, o domínio de envio e a origem cadastrada no ambiente da Apple.
  • [ ] Examine os cabeçalhos completos e os resultados de SPF e DKIM da mensagem que falhou.
  • [ ] Procure uma notificação de não entrega e preserve seu conteúdo como pista, sem tratá-la como confirmação de entrega à caixa pessoal.
  • [ ] Revise o estado de encaminhamento do endereço e procure a mensagem na caixa de destino, incluindo spam e filtros.
  • [ ] Altere somente a configuração sustentada pelas evidências e execute novamente o mesmo cenário controlado.
  • [ ] Feche o caso apenas quando os registros do fluxo e a observação da caixa de destino sustentarem o resultado esperado.

A lista também ajuda a separar problemas diferentes: origem não cadastrada, autenticação inconsistente, falha no encaminhamento ou filtro no destino. Se as evidências apontarem para a configuração da conta, confira a documentação atual da Apple antes de mudar o fluxo de login. Se apontarem para autenticação, trabalhe com quem administra o domínio e o sistema de envio; uma correção feita apenas no código da aplicação pode não mudar a assinatura ou o resultado SPF.

Recupere o fluxo sem confundir teste auxiliar com validação Apple

Depois da correção, repita o cenário com a mesma conta de teste autorizada e o mesmo tipo de mensagem. Correlacione o evento de envio da aplicação com os registros do sistema de envio, o estado relevante do relay e a mensagem efetivamente observada no destino. Se algum elo não estiver disponível, documente a lacuna: “o serviço aceitou” e “o destinatário recebeu” são conclusões diferentes.

Um endereço de teste controlado pode ajudar a verificar outros trechos do seu sistema de e-mail, como a geração de notificações ou o funcionamento de um fluxo de confirmação. Mas ele não substitui o teste real com o endereço privado da Apple e não demonstra que o relay da Apple aceitou ou encaminhou uma mensagem. Para reduzir a exposição do e-mail principal em testes que não dependem do relay, você também pode avaliar como criar e testar um alias de e-mail. Para investigar outra falha de recebimento, consulte o diagnóstico de e-mail de verificação que não chega.

A separação entre desenvolvimento e produção também importa. Em um ambiente de teste, use dados controlados e evite registrar endereços pessoais em logs acessíveis além da equipe necessária. Na produção, não trate um teste bem-sucedido como garantia para todas as contas: mantenha observabilidade suficiente para relacionar tentativa, resultado de envio e sinal de recebimento, respeitando as regras de acesso e retenção da sua organização.

Última atualização: 8 de novembro de 2026. Os requisitos e o contexto do domínio foram conferidos nas páginas oficiais da Apple sobre configuração do relay privado e atualização do domínio do serviço (anúncio oficial para desenvolvedores). Se a Apple alterar requisitos, domínios ou a configuração disponível, valide novamente essas referências antes de aplicar o roteiro.

Quando o objetivo é apenas testar um formulário próprio ou receber uma mensagem de teste sem expor a caixa principal, o Temp88 pode ser uma opção de recebimento temporário: o acesso é imediato e não exige cadastro. Use esse recurso para os testes compatíveis com uma caixa temporária, não como substituto do endereço privado da Apple nem como prova de que o relay encaminhou uma mensagem. Para revisar o fluxo de teste, acesse o Temp88 e mantenha a validação do Sign in with Apple baseada no endereço autorizado e na evidência real de recebimento.

Leia também