2026 Salesforce: e-mails de teste não enviados? Como verificar o domínio de envio

Sintoma: o fluxo de teste executa, mas o e-mail não aparece na caixa de entrada.

Atalho: confira qual domínio o Salesforce usa como remetente e se ele está validado. Para um domínio próprio, a documentação prevê uma chave DKIM válida ou um domínio de e-mail autorizado e verificado; receber a mensagem em uma caixa de teste não substitui essa validação. A exigência oficial de validação de domínio pode variar conforme a configuração e a aplicabilidade à organização.

Salesforce — última atualização: 24 de outubro de 2026. As informações sobre requisitos, configuração e logs foram conferidas na documentação oficial do Salesforce disponível nesta data.

Para administradores: identificar os domínios usados por usuários, endereços de organização e automações, depois conferir o estado de validação.

Para responsáveis por DNS: escolher o método de validação e coordenar a publicação dos registros com quem administra a zona DNS.

Para desenvolvimento e QA: confirmar se o processo disparou, investigar os logs e testar a chegada da mensagem em um endereço controlado.

Salesforce: e-mails de teste não enviados — domínio, disparo e entrega

Antes de alterar a configuração, separe o problema em pontos distintos. A mensagem pode não ter sido acionada pela automação; o Salesforce pode recusá-la ou descartá-la; ou o envio pode ter avançado sem que a mensagem apareça na caixa de entrada. Essa divisão é um roteiro de diagnóstico, não a afirmação de que toda falha tem a mesma causa.

A validação do endereço de e-mail de um usuário e a validação do domínio usado para enviar mensagens são verificações diferentes. A primeira confirma um endereço individual. A segunda trata da autorização do domínio de envio. Portanto, um endereço de usuário marcado como verificado não prova que o domínio correspondente esteja validado para envio.

A documentação do Salesforce descreve duas opções para validar um domínio próprio: uma chave DKIM válida ou um domínio de e-mail autorizado e verificado. Os requisitos de autenticação do domínio explicam essas alternativas. SPF e DMARC podem fazer parte da configuração de autenticação e entregabilidade do domínio, mas não substituem, por si só, uma das opções de validação exigidas pelo Salesforce.

Também não presuma que todo tipo de e-mail, toda organização ou todo ambiente esteja sujeito à mesma regra. A documentação e o estado exibido na organização são a referência: podem existir diferenças de aplicabilidade, exceções ou etapas de disponibilização. Confirme a orientação atual antes de atribuir a falha à política de domínio.

Administrador: remetente individual e domínio da organização

Comece pelo endereço que efetivamente consta como remetente na mensagem esperada. Não se limite ao endereço do usuário que iniciou o teste: o fluxo pode usar um endereço de remetente diferente, definido na organização ou por outra configuração.

Faça o inventário das origens plausíveis na organização:

• Domínios associados aos endereços dos usuários que podem enviar a mensagem.
• Endereços de remetente definidos no escopo da organização.
• Endereços e processos usados por recursos como Email-to-Case ou Experience Cloud, quando estiverem ativos no ambiente.
• Endereços definidos no Apex, em fluxos, alertas ou outras automações que participem do cenário.

Use a orientação oficial para identificar os domínios de e-mail usados na organização. Compare o que a configuração mostra com o endereço From do e-mail que o teste deveria produzir. Se houver subdomínios, verifique cada um: não conclua que validar o domínio principal valida automaticamente qualquer subdomínio que apareça como remetente.

O endereço do usuário já foi verificado. Por que o Salesforce ainda pode não enviar?

Porque essa confirmação não resolve necessariamente a validação do domínio de envio. Confira o domínio que corresponde ao From real e o estado de validação desse domínio. Se o fluxo usa um endereço de remetente da organização, por exemplo, a verificação do endereço pessoal de quem executou o teste não responde se aquele domínio está autorizado.

O inventário reduz um risco operacional comum: publicar registros DNS para um domínio que não é o remetente do fluxo, enquanto o domínio realmente usado continua sem validação. Registre o endereço From observado e a origem da configuração. Isso dá à equipe de DNS um alvo concreto, em vez de um palpite baseado no usuário que acionou a automação.

Responsável por DNS: DKIM ou domínio de e-mail autorizado?

A escolha depende do que a equipe consegue administrar e do que já está configurado. As duas opções atendem ao requisito descrito pelo Salesforce, mas não são a mesma configuração.

• DKIM: considere esse caminho quando a equipe consegue gerar ou administrar uma chave DKIM válida e publicar os registros DNS exigidos. Confirme no Salesforce o estado da chave e se ela corresponde ao domínio usado como remetente.
• Domínio de e-mail autorizado: considere essa opção quando a equipe precisa validar o domínio conforme o procedimento específico do Salesforce. Siga a documentação de configuração, incluindo as etapas que dependem de acesso à zona DNS e de confirmação dentro da organização.

Qual opção deve ser usada?

Escolha com base no controle disponível, não na tentativa de contornar uma falha. Se a equipe responsável controla DNS e já opera DKIM para o domínio, verifique se a configuração atende ao procedimento do Salesforce antes de criar registros adicionais. Se não controla DNS, encaminhe o domínio exato e o método escolhido à pessoa ou equipe que o administra. Não peça a publicação de registros até confirmar no Salesforce o formato e os valores atuais.

A documentação oficial detalha a configuração de um domínio de e-mail autorizado. Use essa página como referência para conferir cada registro e etapa. Não copie valores de um exemplo para outro domínio nem assuma que um registro publicado esteja correto só porque existe na zona DNS: compare o valor, o nome e o domínio com o que a organização solicita.

Responsável pelo sandbox: configuração de teste ou suposição herdada?

Um sandbox precisa ser verificado como ambiente próprio. A configuração de domínio que funciona na produção não permite concluir automaticamente que o ambiente de teste esteja pronto para enviar. Confira no sandbox o estado da validação, o remetente escolhido e os recursos habilitados nele. A orientação oficial do Salesforce inclui a necessidade de verificar as configurações do sandbox; confirme o procedimento vigente para a organização e o ambiente.

O que verificar primeiro quando o Salesforce sandbox não envia e-mails de teste?

Comece pelo endereço From usado pelo cenário no sandbox. Identifique o domínio, confira o estado de DKIM ou do domínio autorizado naquele ambiente e confirme que a automação realmente executou. Em seguida, consulte os logs e só então examine a caixa de recebimento. Esse caminho evita gastar tempo ajustando a caixa de QA quando a mensagem ainda não foi aceita para envio.

Se o ambiente usa um endereço alternativo de remetente, consulte a documentação oficial para confirmar se esse recurso está habilitado e quais são seus limites na organização. Não trate a alternativa como um atalho universal para dispensar a validação. Também não enfraqueça as proteções da produção para fazer um teste funcionar: prefira corrigir a configuração autorizada do sandbox e manter os ambientes separados.

Para evitar alterações improvisadas, registre em conjunto o nome do ambiente, o From esperado, o domínio identificado e o resultado da verificação. Ao entregar o caso à equipe de DNS, inclua esses dados e a tela ou estado relevante do Salesforce. Assim, a equipe pode verificar o domínio certo sem inferir que produção e sandbox compartilham a mesma configuração.

Desenvolvimento: automação executada ou mensagem recusada?

Depois de confirmar o domínio e a configuração do ambiente, investigue o caminho que deveria disparar o e-mail. No cenário de teste da própria organização, confirme se o Apex, o Flow, o alerta ou a automação correspondente foi acionado e se chegou à etapa de envio. Uma execução bem-sucedida de uma parte do fluxo não prova, por si só, que a ação de e-mail ocorreu.

Confira também qual endereço o código ou a configuração usa como remetente. O domínio do usuário conectado pode não coincidir com o domínio do endereço From configurado. Essa diferença é particularmente importante quando uma automação envia com um endereço de organização ou com um remetente alternativo.

Depois, procure evidências de processamento nos logs de e-mail. A documentação oficial explica o formato dos logs de e-mail do Salesforce. Leia o resultado no contexto do fluxo, do destinatário, do remetente e do horário da execução; uma linha isolada não prova que todos os e-mails que falham tenham a mesma causa.

Como reconhecer uma falha ligada ao domínio nos logs?

Procure uma rejeição ou falha permanente e compare o texto do erro com as mensagens e os requisitos de domínio documentados pelo Salesforce. A documentação de erros relacionados à validação de domínio ajuda a interpretar mensagens específicas. Se o log indicar outro tipo de falha, investigue essa evidência em vez de classificá-la automaticamente como problema de domínio.

Os logs também têm condições próprias de solicitação e disponibilidade. Consulte as considerações oficiais para solicitar logs de e-mail antes de depender deles como registro permanente. O Salesforce documenta uma janela de 30 dias para os dados de e-mail disponíveis nos logs; solicite e salve a evidência dentro desse limite, conforme as instruções oficiais. Esse prazo não equivale à retenção de mensagens na caixa de teste.

Após corrigir a configuração, execute novamente o fluxo da própria organização. Guarde o resultado da automação e o log correspondente à nova tentativa. Se o erro persistir, compare o remetente real e o domínio verificado antes de mudar a hipótese.

QA: confirmação de envio ou confirmação de recebimento?

O QA deve tratar o envio e a chegada como evidências diferentes. Primeiro, confirme que a automação foi disparada e que o Salesforce aceitou ou tentou processar o e-mail. Depois, consulte o log e verifique a caixa de recebimento controlada. Se não houver mensagem na caixa, volte ao resultado de envio: a ausência na caixa, sozinha, não mostra em que etapa a falha ocorreu.

Um endereço de teste é útil para observar recebimento, conteúdo e legibilidade sem envolver uma caixa pessoal ou corporativa usada no trabalho diário. Mas ele não comprova que o domínio do remetente foi autenticado, nem corrige configuração de DKIM, domínio autorizado ou automação. Mantenha separados estes registros:

• Evidência do domínio: remetente identificado e estado de validação no Salesforce.
• Evidência do disparo: resultado da execução de Apex, Flow ou outra automação.
• Evidência do processamento: resultado relevante no log de e-mail.
• Evidência de recebimento: se a mensagem chegou ao endereço controlado e se o conteúdo esperado estava legível.

Se a mensagem não chegar, anote o ambiente, o From, o destinatário controlado e o resultado observado. Não conclua que o endereço de teste causou a falha antes de conferir se o Salesforce aceitou e tentou enviar a mensagem. Para outros pontos de falha entre disparo e recebimento, consulte também nosso guia sobre reenvio de códigos de verificação e mensagens antigas.

Marco de verificação: checklist antes de encerrar o incidente

Use esta lista para fechar o diagnóstico com evidências, não apenas com a impressão de que o fluxo “rodou”.

• [ ] Identifique o endereço From efetivamente usado pela mensagem.
• [ ] Registre o domínio desse endereço, incluindo eventual subdomínio.
• [ ] Confira no ambiente afetado se esse domínio está validado por DKIM válido ou por domínio de e-mail autorizado.
• [ ] Diferencie a verificação do endereço individual de usuário da validação do domínio de envio.
• [ ] Confirme que o Apex, o Flow ou a automação esperada chegou à ação de envio.
• [ ] Consulte o log de e-mail e guarde a mensagem de erro ou o resultado pertinente.
• [ ] Depois da correção, repita o teste no ambiente autorizado e registre o resultado da automação e do recebimento separadamente.

Se a equipe precisar alinhar quem administra a caixa controlada e quem recebe encaminhamentos, nossa página sobre encaminhamento de e-mails explica essa opção. Use-a para organizar o recebimento, não como prova de que o Salesforce validou o domínio de envio.

Quando uma caixa temporária ajuda — e quando não ajuda

Depois que o Salesforce confirma a configuração do remetente e a automação tenta enviar, uma caixa de teste controlada pode ajudar o QA a verificar se a mensagem chegou e se o conteúdo está legível. O benefício é separar os testes do endereço principal e reduzir o risco de misturar mensagens de QA com a correspondência de trabalho. Para conhecer essa alternativa, veja como funciona o recebimento temporário de e-mails.

Essa solução não substitui o endereço de recuperação de uma conta importante, nem serve como escolha padrão para contas bancárias, pagamentos, serviços públicos ou qualquer conta que precise de acesso duradouro e recuperação futura. Também não valida o domínio de envio, não comprova que o Salesforce disparou a mensagem e não repara um fluxo que falhou antes da entrega.

Se a falha estiver no domínio, corrija a configuração com a equipe responsável por DNS e confirme o resultado no Salesforce. Se a configuração já estiver validada e o objetivo for apenas inspecionar uma mensagem de teste, Tempsender pode funcionar como uma opção de recebimento sem expor a caixa principal. A caixa controlada ajuda a avaliar o que chegou; a evidência de autenticação continua sendo o estado do domínio na organização e o registro do envio.