Resolver a propriedade da conta antes DNS
Este guia se refere a domínios de remetente no Elastic Email Marketing e Email API, que não recebem mensagens por meio do produto Inbox. Comece com a conta pretendida, o domínio de envio, o proprietário do aplicativo e o administrador DNS autorizado. Confirme qual conta possui atualmente o domínio antes de gerar um novo plano de implantação.
E-mails elásticos guia de verificação de domínio diz que um domínio de remetente pode ser associado a apenas uma conta de Email Marketing ou Email API por vez. Se outra conta o possuir, resolva primeiro essa propriedade. Um administrador não deve excluir um domínio de produção de uma conta antiga sem identificar os aplicativos que ainda enviam por meio dela. Quando o acesso não estiver disponível ou a conta não puder removê-lo, siga o processo de suporte e verificação de propriedade do provedor.
Use o fluxo de trabalho de verificação da conta
O caminho documentado é Configurações > Domínios > Gerenciar Domínios > Iniciar Verificação. Selecione verificação de domínio, insira o domínio que você possui, publique os registros apresentados e use Verificar registro. Nos detalhes do domínio, inspecione os status dos registros individuais em vez de tratar a entrada geral da lista como prova de que todos os recursos opcionais funcionam.
Para SPF, o provedor identifica include:_spf.elasticemail.com. Integre a autorização necessária à política SPF TXT aplicável existente em vez de criar uma segunda. Revise toda a política, incluindo outros serviços autorizados e custos de pesquisa DNS . Não copie mecanismos amplos a ou mx de um exemplo, a menos que correspondam à autorização pretendida do domínio.
Para DKIM, use o Nome e o Valor mostrados na seção DKIM atual da conta. Elastic Email gera o par de chaves e publica o componente público por meio do seu DNS Registro TXT. Um tutorial antigo seletor ou a chave pública não é um substituto. Se o serviço informar que DKIM válido não foi encontrado, compare a resposta oficial com o valor da conta atual antes de alterar registros não relacionados.
Trate o comportamento do remetente padrão como uma escolha política
O provedor descreve a marca substituta com base na existência de um domínio de remetente padrão e observa que as subcontas podem herdar o uso do domínio de remetente verificado padrão da conta principal. Registre qual padrão está selecionado e se essa herança é apropriada para os aplicativos que usam a conta. A verificação de domínio e a autorização de aplicação não são a mesma decisão administrativa.
Não confie no comportamento de fallback para tornar aceitável um domínio De não aprovado. Exija que cada aplicativo de produção use sua identidade aprovada e teste o que é realmente entregue. Uma plataforma pode enviar uma mensagem com êxito usando um domínio inesperado, o que é operacionalmente diferente de concluir a configuração pretendida do domínio personalizado.
Rastreamento e roteamento de e-mail separados da assinatura
Os detalhes do domínio também expõem rastreamento, MX e DMARC status. Revise a finalidade de cada registro antes da publicação. Um rastreamento CNAME diz respeito ao comportamento do link; uma instrução MX do domínio do remetente não é uma permissão geral para substituir o roteamento da caixa de entrada da organização. Preservar a política DMARC atual para todo o domínio, a menos que seu proprietário aprove uma alteração deliberada com base em todos os remetentes legítimos.
Design de teste original: use uma mensagem de aplicativo inofensiva e, quando relevante, um teste de subconta. Registre a identidade do remetente solicitada, conta selecionada/padrão, remetente real recebido, remetente do envelope, domínio e seletor DKIM e resultados de autenticação do receptor. DMARC requer um resultado SPF ou DKIM aprovado alinhado com o De visível. Compare a identidade pretendida com a identidade recebida antes de decidir se o substituto é aceitável.
Diagnosticar e recuperar na camada com falha
Cenário ilustrativo: DNS corresponde exatamente à chave da nova conta, mas um aplicativo legado ainda é enviado por meio de uma conta diferente. Substituir repetidamente a mesma chave pública não corrigirá essa incompatibilidade de roteamento. Confirme a associação de conta e domínio do aplicativo e escolha um caminho de migração ou restauração aprovado.
Salve configurações e registros anteriores. Pause o aplicativo afetado durante um problema de propriedade ou identidade não resolvido e restaure a última configuração aprovada sempre que possível. Verifique novamente após migração de conta, alterações de domínio padrão ou substituição de chave. A documentação foi revisada em 8 de novembro de 2026; nenhuma conta, registro DNS ou mensagem recebida foi testada aqui.
Decida a movimentação da conta antes de regenerar as chaves
O caso escrito EE-01 pressupõe que receipts@example.com pertence a um aplicativo de recibo ativo na conta Antiga, enquanto uma nova equipe tenta verificar example.com na conta Nova. A nova conta reporta um conflito de propriedade; os resultados atuais DNS e mensagens são desconhecidos. O proprietário do aplicativo deve inventariar o Antigo antes de aprovar uma transferência coordenada. Remover o domínio apenas para limpar o aviso de New coloca em risco a rota existente. A operadora deverá resolver o acesso ou seguir o processo de suporte à verificação de propriedade do provedor, preservando a configuração atual exata e uma decisão de recuperação. Nenhuma remoção de conta, contato de suporte ou alteração DNS ocorreu aqui. Após uma transferência aprovada, exija um recibo controlado com o remetente pretendido e a identidade de assinatura real, e não apenas um crachá de domínio verificado.
Preservar o limite de aplicação
RFC 9989 A Seção 7.4 exige DKIM válido, e não apenas SPF , para publicação de domínios p=rejecte alerta sobre a interoperabilidade de correio indireto e listas de discussão. Um único teste bem-sucedido de mensagem direta não é prova de que todas as rotas legítimas estejam prontas para políticas mais fortes. Mantenha a proteção aprovada existente enquanto diagnostica a lacuna real; qualquer mudança política necessita da sua própria decisão.