Identifique a plataforma atual e a conta de envio
O atual centro de ajuda primário afirma que Manago AI é o novo nome do SALESmanago. Este artigo mantém o nome do catálogo para que as equipes existentes possam encontrá-lo, enquanto usam as páginas de ajuda atuais junto com o PDF de autenticação do provedor. Uma mudança de nome de marca não é permissão para alterar alvos DNS em funcionamento. Confirme as instruções atuais da conta antes de substituir qualquer registro com nome herdado. Orientação Manago AI DKIM
Comece identificando a conta do remetente realmente selecionada pela mensagem. A plataforma distingue uma conta de Email Marketing utilizando infraestrutura de envio própria de uma conta SMTP Externa utilizando infraestrutura selecionada pelo cliente. As configurações relevantes estão documentadas em Canais > Email Marketing > Configurações. Contas de remetentes do Manago AI
Esta distinção altera quem é responsável pela assinatura final e identidade do envelope. Os registros de autenticação de plataforma não devem ser considerados para reparar uma mensagem entregue a um serviço SMTP separado. Campanhas de inventário, automações, mensagens acionadas por API e confirmações de assinatura que usam cada conta. Inclua fluxos de trabalho inativos, mas agendados, para que um teste único aprovado não deixe um remetente antigo ativo na próxima execução de automação.
Crie um inventário de domínio e propriedade
Liste todos os domínios e subdomínios visíveis, a equipe responsável e a conta que o seleciona. Não reduza domínios distintos ao nome do site principal. Se um campo de remetente personalizado puder produzir vários domínios, cada domínio pertencerá à revisão. Registre o remetente substituto usado quando faltam dados de personalização, porque essa é outra identidade que um destinatário real pode ver.
O provedor documenta a substituição opcional dos detalhes do remetente nos campos padrão de um contato. Suas instruções de conta do remetente também distinguem o remetente visível do endereço de resposta. Teste as combinações realmente habilitadas, sem presumir que uma caixa de correio de resposta funcional autentica o endereço De visível. Contas de remetentes do Manago AI
Use contatos de teste inofensivos com permissão explícita para receber os cheques. Não altere os detalhes do remetente de um segmento de cliente inteiro para diagnóstico. Preserve a seleção de conta existente e a configuração do modelo para que um administrador possa restaurá-los se um teste expor uma incompatibilidade. Mantenha senhas SMTP , segredos de API e chaves privadas fora da planilha e de quaisquer capturas de tela de suporte.
Prepare os registros da plataforma suportada
O PDF de autenticação do provedor documenta o SPF mecanismo include:_spf.jupiter.salesmanago.pl e dois DKIM CNAME seletores, salesmanago e salesmanago2. Seus destinos documentados são os correspondentes seletor nomes em _domainkey.smgrid.com . Aplique-os somente após confirmar que a conta corrente usa esta rota de plataforma suportada. A página de ajuda atual DKIM também orienta os administradores a coordenar a preparação do domínio com o provedor. PDF de autenticação SALESmanago Orientação Manago AI DKIM
Para cada seletor, obtenha o proprietário e o destino completos nas instruções do provedor. Traduza-os cuidadosamente para o formato de nomenclatura do console DNS . Um console que acrescenta o nome da zona poderá criar um sufixo duplicado se um proprietário totalmente qualificado for colado em um campo de nome relativo. Inspecione o resultado público em vez de confiar na aparência do texto no editor. Os dados existentes de um proprietário CNAME proposto precisam de revisão antes da substituição.
Mantenha uma política SPF aplicável no proprietário relevante. Mesclar apenas a autorização necessária no inventário existente, preservando outros remetentes aprovados e o mecanismo de terminal pretendido. Avalie o orçamento de pesquisa de DNS com inclusões aninhadas e outros termos que causam pesquisa. A sintaxe e a autorização SPF são separadas de DMARC alinhamento; um recorde no domínio From visível não altera o domínio do envelope selecionado pelo serviço de envio. SPF RFC 7208
Não copie uma política inteira de amostra em uma zona de produção. A organização pode usar correio da equipe, um sistema de pedidos e outras plataformas desse domínio. Um guia de autenticação para um provedor não pode determinar quais desses sistemas devem permanecer autorizados. Da mesma forma, um endereço IP observado não é um substituto estável para o mecanismo de autorização mantido por um provedor.
Verificação completa de propriedade de domínio
O PDF separa a publicação DNS DKIM da verificação de propriedade. Ele documenta um opcional Registro TXT contendo smv= seguido do ID do cliente da conta, com esse ID disponível em Integration Center > API > API v2. Ele também fornece verificação assistida por suporte quando o registro opcional não é usado. Confirme o procedimento da conta corrente e obtenha os comprovativos da sua conclusão. PDF de autenticação SALESmanago
O ID do cliente usado para esse registro de verificação pública documentado não é uma solicitação para publicar um segredo de API. Copie apenas o campo exigido pelo provedor. Se a interface expor credenciais adjacentes, edite-as de capturas de tela e transferências. Não crie um novo acesso à API apenas para encontrar um identificador de verificação já associado à conta.
O guia atual da conta do remetente exige separadamente a verificação do Suporte para cada nova conta de remetente destinada a mais de 1.000 contatos. Trate a revisão da conta como um pré-requisito de lançamento, além da verificação de propriedade do domínio; publicar o registro smv opcional não o substitui. Confirme a conclusão com o proprietário da conta antes de agendar esse público. Contas de remetentes do Manago AI
Trate a verificação como uma etapa de controle da conta. Uma pesquisa DNS mostrando ambos os CNAMEs não pode, por si só, provar que a conta de cliente correta tem permissão para usar o domínio. Guarde a referência da conta, o horário de confirmação e o revisor. Se a verificação permanecer incompleta, resolva esse problema com o provedor em vez de alternar entre seletores arbitrários ou alterar a política DMARC para ocultar a falha.
Verifique a plataforma e as mensagens SMTP externas separadamente
Envie uma mensagem controlada através de cada rota dentro do escopo e capture seus cabeçalhos originais em um receptor confiável. Registre a conta selecionada, De visível, identidade do envelope, cada domínio e seletor de assinatura DKIM e resultados de autenticação do receptor. Compare o domínio de assinatura com o inventário de domínio autorizado. Os valores DKIM 'sd= e s= identificam o domínio de assinatura e o seletor usado para a pesquisa. DKIM RFC 6376
Para uma conta SMTP externa, primeiro identifique o provedor de correio real e seu procedimento de assinatura documentado. Não presuma que os seletores SALESmanago se aplicam a ele. Uma conexão bem-sucedida ou um envio SMTP aceito não prova nem uma assinatura aprovada nem um envelope alinhado. Aguarde a implementação específica da rota até que o administrador desse serviço forneça configurações suportadas e um resultado de mensagem recebida.
Para uma conta de plataforma com personalização, teste um contato preenchido comum e um contato que invoque o substituto. Repita qualquer domínio de remetente distinto em vez de amostrar apenas nomes de exibição. Se uma versão falhar, compare o endereço De emitido com o domínio configurado para assinatura. A questão relevante é qual identidade saiu do sistema, e não qual identidade o editor de modelo parecia exibir.
DMARC é aprovado quando pelo menos um caminho de autenticação bem-sucedido se alinha com o domínio De visível sob a política efetiva. Uma passagem de domínio do provedor que não está alinhada é insuficiente. Aplique a especificação atual às identidades observadas e preserve o resultado ao lado da evidência bruta. DMARC RFC 9989
Revise DMARC sem adotar uma política de amostra
O PDF do provedor inclui um exemplo DMARC orientado para aplicação e endereços de relatório a serem substituídos. Esses são exemplos, não uma decisão para toda a organização. Revise a política existente e todos os remetentes legítimos antes de alterar a aplicação. Não faça downgrade de uma política estabelecida apenas para acomodar uma conta de marketing não verificada e não atualize um domínio não revisado apenas porque um exemplo de campanha foi aprovado.
Selecione os destinos dos relatórios deliberadamente. Relatórios agregados pode revelar infraestrutura de envio e padrões de tráfego; relatórios mais detalhados podem ter implicações adicionais de privacidade. Use apenas destinatários aprovados e mantenha a configuração do relatório separada do registro TXT de verificação de conta do provedor. Um destino de relatório não é uma chave DKIM e um token de propriedade não é uma política DMARC .
Exemplo fictício envolvendo um remetente substituto
Somente caso escrito fictício: SM-01 estipula que os contatos preenchidos produzam offers@shop.example com a passagem d=shop.example, enquanto os campos de personalização ausentes retornam para offers@brand.example . A verificação de propriedade de brand.example está incompleta e seus resultados SPF / DKIM são desconhecidos. O proprietário do marketing deve aprovar e verificar esse domínio substituto antes de liberar esses contatos. Uma conta SMTP externa separada permanece fora do resultado da plataforma. Nenhum contato, conta ou mensagem foi acessado; essas identidades são suposições de ensino.
Planilha de implementação e limites de liberação
- Escopo da conta: nome da plataforma atual, identificador da conta, tipo de conta do remetente selecionado e proprietário do fluxo de trabalho.
- Inventário de identidade: De padrão, domínios personalizados, valores alternativos e destinos de resposta monitorados.
- Evidência DNS : registros públicos emitidos, política SPF existente, expansão do proprietário CNAME , TTLs e tempos de pesquisa autorizados.
- Propriedade: método de verificação escolhido, identificador público aprovado, se usado, confirmação do fornecedor e tempo de conclusão.
- Testes de rota: plataforma ou SMTP externo, referência de fluxo de trabalho, De, domínio de envelope, todos os pares DKIM d=/s= e resultados confiáveis.
- Recuperação: remetente com suporte anterior, automações afetadas, autoridade de pausa e critérios de reteste.
Os registros atuais do locatário, o status de propriedade, as configurações SMTP externo, DNS ativo e as mensagens recebidas não foram inspecionados. A revisão visual, a aprovação humana pelas PME e a publicação permanecem pendentes. O guia permanece inédito; a configuração de serviço externo e qualquer desvio específico da conta das instruções públicas são restrições de escopo explícitas.
Separe uma mensagem passageira da prontidão para aplicação
RFC 9989 A seção 7.4 exige DKIM válido para publicação de domínio p=reject e alertas sobre a interoperabilidade de correio indireto. Um único resultado alinhado SPF não justifica, por si só, uma implementação de política de rejeição. Revise todas as rotas legítimas e propriedade de políticas separadamente da configuração deste provedor.