Confirme o produto e a rota exatos do GoodData
O procedimento primário que dá suporte a este guia é denominado GoodData Legacy Growth, Configure DKIM para e-mail de saída. Trata-se de correspondência de saída com etiqueta branca e requer trabalho tanto por parte do cliente quanto da GoodData. Não aplique-o automaticamente ao GoodData Cloud atual, a outro plano ou a um serviço de notificação diferente.
Comece confirmando o produto, o domínio com etiqueta em branco, os endereços De pretendidos e os fluxos de trabalho reais de mensagens com o proprietário da conta. Identifique o administrador DNS e o proprietário do suporte GoodData que cuida da configuração de marca branca. Um URL de aplicativo personalizado ou tema de marca não é prova de que o e-mail enviado esteja assinado com o mesmo domínio.
A tarefa do leitor é estabelecer um acordo de assinatura compatível e então testar a correspondência pretendida. O amplo rótulo de fornecedor do catálogo não justifica afirmar que todos os produtos GoodData suportam o mesmo seletor, retransmissão ou processo de gerenciamento de chaves. Se o escopo herdado documentado não corresponder ao seu locatário, obtenha o procedimento primário correspondente antes de alterar DNS .
Escolha um arranjo de teclas compatível
A documentação do Legacy Growth descreve o uso de uma chave privada específica, com uma chave exclusiva gerada pelo GoodData como alternativa, ou o uso de uma chave compartilhada do GoodData. Na rota da chave compartilhada, o Support fornece um registro DNS contendo a chave pública. Na rota de chave específica, as partes coordenam o seletor e o domínio com a configuração de assinatura. Nenhum seletor universal ou valor de chave pública é fornecido para os clientes copiarem deste guia.
Prefira um acordo que se ajuste à política de propriedade de chaves de assinatura da organização e minimize a exposição desnecessária. Esclareça quem gera a chave, quem pode usá-la, como a rotação é coordenada e como a autoridade de assinatura do provedor será removida quando o serviço for desativado. Um registro DNS público pode ser amplamente visível; uma chave privada não pode ser tratada da mesma maneira.
A documentação do provedor descreve a transferência criptografada quando uma chave privada fornecida pelo cliente é usada. Não cole uma chave privada no chat, um comentário de suporte comum, um documento público ou DNS . Peça ao proprietário autorizado do título que verifique o destinatário pretendido e o processo de transferência seguro. Solicitar ou aceitar uma alternativa gerada pelo fornecedor ainda requer a compreensão de quem detém e controla o material de assinatura privada.
Publique apenas o material de verificação pública
Obtenha o tipo de registro exato, proprietário completo, seletor e valor público da configuração suportada. Compare-os com o domínio de assinatura aprovado. Registre o rótulo do editor de DNS necessário separadamente porque um campo de nome relativo pode anexar a zona automaticamente. Verifique se um seletor existente já pertence a outro serviço de correio antes de fazer uma alteração.
A Assinatura DKIM com d=example.com e s=analytics1 procura sua chave em analytics1._domainkey.example.com . Este é um exemplo de construção de nome sintético, não um padrão GoodData. Uma chave publicada corretamente em um seletor ou domínio diferente não verificará essa assinatura. Preservar o valor público completo e os limites do registro quando o editor representa um longo Registro TXT como múltiplas strings.
Após a publicação, consulte DNS oficial para saber o proprietário exato. Preserve as respostas e confirme se a delegação ativa está atendendo ao registro que você editou. Em seguida, peça ao proprietário do suporte que conclua a configuração do GoodData. A publicação DNS sem ativação de assinatura é apenas metade da tarefa.
Mantenha SPF opcional distinto do alinhamento
As listas de páginas Legacy Growth include:relays.gooddata.com como opcional SPF além de autorizar seus retransmissores de correio. Confirme se esta é a rota aplicável antes de usá-la. Não adicione-o apenas porque existe um fluxo de trabalho GoodData não relacionado na organização e não crie uma segunda política SPF no mesmo proprietário.
Revise qualquer atualização SPF necessária como um todo: preserve os remetentes aprovados existentes, verifique as dependências de pesquisa de DNS da política e confirme o comportamento do terminal. Evite copiar endereços IP de retransmissão em uma lista de permissões estática sem um plano de manutenção explícito. Uma meta de autorização gerenciada pelo provedor e uma lista congelada das respostas atuais têm consequências operacionais diferentes.
O sucesso SPF por si só não demonstra DMARC alinhamento. A identidade avaliada é a remetente do envelope domínio. Se uma mensagem usar um envelope de propriedade do provedor enquanto mostra seu domínio em De, um passe SPF para esse domínio do provedor não se alinha ao seu domínio. Uma assinatura DKIM de passagem alinhada com o From visível pode fornecer o caminho necessário.
Teste uma mensagem real com etiqueta em branco
Acione cada fluxo de trabalho de material no escopo para uma caixa de correio de teste autorizada e controlada. Retenha a mensagem recebida bruta e anote o fluxo de trabalho, a configuração do remetente e o tempo de teste. Registre o De visível, a identidade do envelope, cada domínio e seletor de assinatura DKIM e os resultados da autenticação do receptor confiável. Não infira esses valores apenas do URL com etiqueta em branco ou de um display assinado por.
Exemplo de aceitação sintética: De é reports@example.com , a assinatura DKIM da mensagem é verificada com d=example.com e o receptor avalia DMARC com sucesso nesse caminho alinhado. Mesmo que SPF passe apenas para um domínio de envelope não relacionado, DKIM alinhado exatamente pode fornecer o caminho DMARC . Se a assinatura usar um domínio diferente e não relacionado, um passe DKIM por si só não será suficiente para apoiar esta conclusão de aceitação.
Repita a amostra após a rotação da chave ou uma alteração no transporte de correio. Se a assinatura esperada estiver ausente, verifique a ativação do GoodData e o fluxo de trabalho real antes de adicionar mais registros. Se a assinatura estiver presente, mas for inválida, compare o seletor, o domínio, a chave pública e qualquer modificação da mensagem. Se a autenticação for aprovada, mas a entrega for ruim, investigue outros fatores do receptor e da reputação separadamente.
Planeje rotação, aposentadoria e recuperação
Mantenha o conjunto de registros pré-mudança e um proprietário documentado para cada parte do acordo de assinatura. Coordene o momento em que o provedor começa a assinar com um novo seletor e o momento em que a chave pública fica disponível. Não presuma que a exclusão de um único registro revoga todos os recursos ou que a exclusão imediata de uma chave antiga é segura para mensagens já enviadas que ainda estão sendo entregues.
Ao descontinuar a integração, verifique se nenhum fluxo de trabalho ainda precisa dela antes de remover seletores ou permissões SPF . Reconcilie a retenção de chave privada e o acesso à assinatura do fornecedor no processo de segurança da organização. Se uma chave tiver sido exposta, use um processo de incidente e rotação em vez de tratar a preocupação como um atraso normal do cache DNS .
Este é um guia documental para um produto legado especificamente rotulado. Os exemplos são sintéticos. Nenhuma chave privada, configuração de locatário, alteração DNS , troca de suporte ou mensagem GoodData entregue foi acessada ou testada. A verificação da produção e qualquer decisão mais ampla sobre o escopo do produto permanecem com os proprietários da conta e dos títulos.
Use um livro de ativação antes de concluir a rota
O caso escrito GD-01 pressupõe que o inquilino tenha o Legacy Growth confirmado, o De aprovado é reports@example.com e o seletor ilustrativo acordado é analytics1. O proprietário DNS tem uma chave pública estipulada em analytics1._domainkey.example.com , enquanto a ativação da assinatura do lado do provedor permanece não confirmada. DNS sozinho não pode fechar a tarefa. Peça ao proprietário da marca branca para obter a confirmação da configuração de assinatura suportada e, em seguida, inspecione uma notificação autorizada inofensiva. Uma passagem DKIM confiável hipotética posterior com d=example.com, s=analytics1 forneceria o alinhamento exato, mas até que exista essa evidência, o resultado da mensagem permanece desconhecido. Nenhuma chave privada, solicitação de suporte, pesquisa DNS ou ação de locatário foi usada aqui.
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.