O Campaign Monitor autentica um domínio de envio por meio de configuração de conta, DNS público e verificação. Use o domínio exato que aparecerá no endereço De, incluindo seu subdomínio. Esta é uma configuração específica do remetente: a autenticação do Campaign Monitor não autentica outro serviço que usa o mesmo domínio de marca.
Estabeleça a identidade e mude o proprietário
Confirme se a organização controla o domínio pretendido e se o operador DNS pode alterar a sua zona autoritativa. Salvar existente seletor, SPF e Registros DMARC. Identifique outros remetentes legítimos antes de aceitar qualquer sugestão de substituição de política. Mantenha a pessoa que configura as campanhas e a pessoa que publica DNS alinhadas no domínio completo, não apenas em um rótulo curto, como e-mail.
O guia de domínio de envio diz que autenticar um domínio de segundo nível não autentica seus subdomínios na plataforma. Se as campanhas usarem news.example.com , adicione esse domínio exato em vez de presumir example.com cobre a configuração da conta.
Configure o domínio e a chave gerada
Abra o menu do perfil, Configurações da conta e Envio de domínios. Escolha Configurar um domínio de envio ou Adicionar domínio, insira o domínio completo e continue. Publique o nome e o valor TXT gerado no DNS autoritativo, usando a convenção correta de nome completo ou nome relativo do editor. Retorne ao Campaign Monitor e selecione Adicionei os registros ou Verifique novamente o registro se retornar mais tarde.
Use uma chave recém-gerada para esta configuração em vez de importar uma chave privada existente por conveniência. Mantenha o material de assinatura privado fora de DNS , tickets e planilhas compartilhadas. Se um seletor gerado colidir com outro registro ativo, resolva o conflito antes de substituí-lo. Exemplos públicos não são a chave da sua conta.
Preserve DMARC e reconcilie SPF com cuidado
O fluxo de trabalho documentado aceita um documento válido existente DMARC configuração. Mantenha sua política de aplicação e destinos de relatórios, a menos que o proprietário do domínio aprove uma alteração separada. Onde nenhuma política se aplicar, estabeleça uma para o proprietário correto. UM p=none Um exemplo é uma solicitação de monitoramento, não uma aplicação e não uma razão para enfraquecer uma política herdada de um pai.
O Campaign Monitor recomenda autorização SPF opcional usando include:_spf.createsend.com. Se essa autorização for apropriada para sua configuração, mescle-a na única política SPF existente em vez de adicionar uma segunda. Preservar outros remetentes legítimos e verificar o caminho de dependência avaliado em relação ao limite de pesquisa do SPF . O provedor visão geral da autenticação de e-mail fornece contexto, mas o envelope recebido determina qual domínio o receptor realmente verifica.
Um passe SPF para um envelope de propriedade do serviço não está necessariamente alinhado com o seu De visível. Uma passagem alinhada Assinatura DKIM pode satisfazer DMARC mesmo quando o caminho SPF está desalinhado. Não prometa SPF estrito alinhamento apenas porque uma inclusão foi adicionada ao domínio De Registro TXT.
Verifique os registros antes do teste da campanha
Consulte o seletor gerado em cada servidor autoritativo e, em seguida, inspecione as respostas DMARC e SPF aplicáveis. Registre o proprietário completo, tipo, valor e carimbo de data/hora. Um editor DNS pode dividir um valor TXT longo em sequências de caracteres dentro de um registro; que difere da publicação de vários DKIM registros. Siga o tratamento do provedor DNS e compare o valor reconstruído.
Se o Campaign Monitor não puder verificar, verifique se há um sufixo de domínio duplicado, tipo de registro errado, caracteres-chave omitidos e discordância entre servidores autoritativos. O TTL é um controle de cache, não um horário garantido em que cada validador é atualizado. Uma resposta negativa armazenada em cache pode durar mais que o momento em que um novo registro é criado.
Confirme se a campanha real usa o domínio pretendido
Envie uma campanha de teste controlada com o endereço De recém-autenticado. Preservar a confiança Authentication-Results, De, Return-Path e todos os pares DKIM d=/s= . Confirme se uma assinatura de passagem está alinhada com o domínio De no modo configurado. Se o teste for aprovado, mas uma campanha posterior falhar, compare os endereços e as rotas dos remetentes antes de modificar DNS .
Caso ilustrativo: example.com está configurado, mas uma campanha utiliza news.example.com , que nunca foi adicionado à conta. Corrija a configuração do domínio para a identidade real da campanha; não substitua uma chave de domínio pai válida para resolver uma configuração de identidade diferente.
Retenha o remetente anterior em funcionamento até a aceitação, quando possível. Verifique novamente após alterações de conta, novos subdomínios de envio, migrações DNS ou rotação de chaves. Antes da desativação, interrompa as campanhas programadas e confirme que as dependências não são mais usadas. Este artigo é um guia documental e um plano de verificação proposto, não uma evidência de um teste ao vivo do Campaign Monitor ou entrega garantida.
Não confunda uma lacuna no escopo do produto com alinhamento estrito
O caso escrito CM-01 pressupõe que o produto tenha example.com configurado, mas a campanha From é news@news.example.com . Estipule separadamente uma assinatura DKIM de passagem confiável d=example.com, s=demo1. Com o alinhamento normal e relaxado do domínio organizacional, essa assinatura pode ser alinhada a news.example.com ; com adkim=s não corresponde exatamente. SPF e outras assinaturas são desconhecidos, portanto o veredicto geral do modo estrito não foi resolvido, e não uma falha estabelecida DMARC . Nenhuma das premissas prova que o Campaign Monitor tem o subdomínio pretendido configurado. O proprietário da campanha deve concluir a configuração do domínio exato e inspecionar a campanha controlada resultante antes do lançamento. Estes são contributos fictícios e não uma entrega capturada ou uma razão para afrouxar a política.
Preservar o limite de aplicação
RFC 9989 A Seção 7.4 exige DKIM válido, e não apenas SPF , para domínios que publicam p=reject, e 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.