Verificando o seu domínio de envio de e-mails

A REDA roda sobre o Salesforce, e o Salesforce agora se recusa a entregar e-mails cujo domínio de envio não tenha sido comprovadamente ligado a você. Se os endereços da sua equipe terminam em @suaempresa.com, alguém precisa publicar um registro DNS provando que a sua empresa é dona de suaempresa.com — caso contrário, os usuários não conseguem definir um endereço corporativo como o endereço de e-mail deles no Salesforce, e os e-mails que a REDA envia em nome deles são descartados. Este artigo explica o requisito desde o princípio, entrega o registro exato a publicar, responde à pergunta que a sua equipe de TI vai fazer antes de publicá-lo e percorre toda a sequência, da Configuração até um domínio verificado e funcionando. Ele foi escrito para quem configura uma organização da REDA durante a implantação — você não precisa saber nada de DNS de antemão.

O que é um "domínio de envio de e-mails" e por que o Salesforce agora o verifica

Um domínio de envio de e-mails é simplesmente a parte do endereço de e-mail que vem depois do sinal @. Em ana.silva@suaempresa.com, o domínio de envio é suaempresa.com. Quando o Salesforce envia um e-mail que parece vir daquele endereço — um e-mail em massa que um usuário disparou a partir de um registro da REDA, uma notificação, um extrato do proprietário, um alerta automático —, o Salesforce está enviando e-mail como a sua empresa.

Historicamente, o Salesforce só verificava o endereço individual: enviava um link por e-mail ao usuário, o usuário clicava nele e o endereço era marcado como verificado. Isso prova que uma pessoa consegue ler aquela caixa de entrada. Não prova que a organização dona da organização do Salesforce tenha qualquer direito de enviar e-mail como aquele domínio. Como, sem isso, qualquer pessoa capaz de criar usuários em uma organização do Salesforce poderia criar um endereço em qualquer domínio e enviar e-mail como ele, o Salesforce acrescentou uma segunda verificação, de nível mais alto.

Portanto, agora existem dois níveis de verificação independentes, e os dois importam:

O Salesforce introduziu isso por fases, como o requisito de verificação do domínio de envio de e-mails do Spring '26. As organizações já existentes receberam uma lista temporária de permissões com os domínios dos quais já enviavam, e esse período de carência venceu durante 2026 — ou seja, é um requisito em vigor, não algo por vir. Vale tanto para sandboxes quanto para a produção, e é independente para cada domínio e cada subdomínio: verificar suaempresa.com não cobre mail.suaempresa.com.

Como o problema se manifesta

O requisito raramente se anuncia. Ele aparece como um destes sintomas, e nenhum deles menciona DNS:

Duas formas de provar que o domínio é seu

O Salesforce aceita exatamente duas provas, e você precisa de apenas uma delas por domínio. No fundo, as duas funcionam do mesmo jeito: você publica no DNS do seu domínio um registro que só o dono do domínio poderia publicar, e o Salesforce faz a consulta.

O restante deste artigo cobre o caminho do domínio de e-mail autorizado, porque é um único registro DNS e é o que a maioria das implantações da REDA usa para desbloquear a integração dos usuários. Se a sua organização já tem uma chave DKIM ativa para o domínio, o domínio já está verificado e você não precisa fazer nada — verifique Configuração → Chaves DKIM antes de criar qualquer coisa.

Passo 1 — Adicione o domínio e obtenha a chave de verificação dele

Passo 2 — Publique um registro DNS do tipo TXT

O DNS é o diretório público que associa nomes de domínio a informações sobre eles. Um registro TXT é uma entrada de texto livre nesse diretório, e é o que as verificações de propriedade de domínio usam universalmente: só quem controla o domínio pode colocar texto no DNS dele, então encontrar ali o texto esperado é prova de controle. Quem administra o DNS da sua empresa — a sua equipe de TI ou um registrador como Cloudflare, GoDaddy ou Route 53 — é quem o cria.

O Salesforce aceita o registro em três localizações válidas. O valor é idêntico nas três; só muda o nome do registro.

Usando a opção 2, este é o registro completo — um registro TXT cujo nome é o subdomínio _sfdv e cujo valor é a chave de verificação do Passo 1. O TTL padrão está bom.

Name                    TTL   CLASS   TYPE    VALUE
--------------------------------------------------------------------
_sfdv.suaempresa.com.   600   IN      TXT     "00D000000000P08=1TB00000000000B"

Nada mais muda: nenhuma alteração de roteamento de e-mail, nenhuma alteração nas entradas SPF, DKIM ou DMARC existentes, nenhum efeito na entrega de e-mail atual da sua empresa. É um único registro aditivo.

O que o registro dá — e o que não dá — ao Salesforce

Esta é a pergunta que toda equipe de TI ou de segurança faz antes de publicar, e ela merece uma resposta direta.

A verificação é uma consulta de DNS somente leitura. O Salesforce consulta o DNS público em busca do registro TXT com o nome que você escolheu, compara o texto que encontra com a chave que gerou e registra o resultado. Esse é o mecanismo inteiro.

Passo 3 — Verifique a propriedade no Salesforce

As alterações de DNS se propagam pela internet com atraso. Na prática, um registro novo costuma ficar visível em minutos, mas a orientação do próprio Salesforce é aguardar até 72 horas, e o tempo real depende do TTL dos registros que já estavam lá. Planeje a solicitação com isso em mente — esta é a única parte da sequência que você não consegue comprimir.

Passo 4 — Decida sobre "Exigir verificação de e-mail"

Cada domínio de e-mail autorizado traz uma segunda configuração, Exigir verificação de e-mail, que vem ativada por padrão. Ela controla a verificação de nível de usuário descrita no começo deste artigo: se cada pessoa daquele domínio ainda precisa clicar em um link de verificação antes de o Salesforce enviar como o endereço dela.

Uma vez verificada a propriedade, você tem uma escolha real a fazer, e ela é uma decisão de segurança, não um detalhe de configuração:

Para alterá-la: Configuração → Domínios de e-mail autorizados → Editar ao lado do domínio → desmarque Exigir verificação de e-mail → Salvar. Existe também um equivalente para toda a organização, referente ao DKIM, na página Capacidade de entrega (Verificar a propriedade dos domínios de envio de e-mail por meio de chaves DKIM), que se aplica de uma só vez a todos os domínios com uma chave ativa — a configuração por domínio do domínio de e-mail autorizado é o instrumento mais preciso.

Como contornar o caso de um usuário travado enquanto o DNS está pendente

Se alguém precisa ter o endereço alterado antes de o registro DNS estar no ar, o link de verificação costuma falhar simplesmente porque é aberto fora de uma sessão autenticada — o navegador não tem sessão do Salesforce, então o link cai na página de login e a alteração é abandonada. Esta sequência normalmente resolve o caso de um único usuário:

Outras duas configurações da organização produzem o mesmo sintoma da página de login e vale conferir se o procedimento acima não funcionar: Exigir verificação de identidade para alterações de endereço de e-mail (Configuração → Verificação de identidade), que pede ao usuário para confirmar a partir do endereço antigo e deixa preso quem não tem mais acesso a ele; e o logon único (SSO), em que um cookie de página inicial do SSO armazenado pode forçar um logout que descarta o destino do link.

Solução de problemas

Referências oficiais do Salesforce

A verificação de domínio é um requisito da plataforma Salesforce, não uma configuração da REDA, então a documentação oficial é a do Salesforce. As URLs da Ajuda do Salesforce mudam de uma versão para outra — se um link sair do lugar, pesquise no portal de Ajuda pelo título ou pelo ID do artigo.

O que vem a seguir

1. Criando usuários e concedendo acesso à REDA — a tarefa de integração que este requisito interrompe.
2. Configurações de e-mail em massa — onde são escolhidos os endereços de envio de toda a organização, todos eles precisando de um domínio verificado.
3. Envio de e-mail pelo REDA — o lado do usuário final do e-mail de saída.
4. REDA Email Services: Visão geral — o processamento de e-mails de entrada, que este requisito não afeta.
5. Protegendo a sua organização REDA — a configuração de segurança mais ampla na qual isto se insere.

Perguntas frequentes