Escopo: hospedagem compartilhada Afrihost e cPanel
Afrihost publica instruções separadas para obter registros de autenticação no cPanel e adicioná-los através do Editor DNS de hospedagem compartilhada do ClientZone. Este guia segue essa rota documentada. Isso não implica que o Afrihost Pure Mail, um provedor de caixa de correio externo ou todos os pacotes de hospedagem usem registros ou controles de assinatura idênticos. Estabeleça o produto de e-mail real e o serviço DNS oficial antes de preparar uma alteração. Os valores específicos da conta e a aplicabilidade atual da interface permanecem não verificados.
O provedor SPF as instruções de geração usam a área Email Deliverability do cPanel: selecione Gerenciar ao lado do domínio, encontre SPF e copie seu valor. Isso é DKIM As instruções usam a mesma área e a ação Instalar o registro sugerido. Estas são etapas propostas pelo operador, não ações realizadas para este manuscrito. Geração SPF Afrihost Geração Afrihost DKIM
Geração, publicação e assinatura separadas
Um registro sugerido é uma evidência do que uma interface de configuração específica recomenda. Não há evidência de que a zona de autoridade pública contenha esse valor ou que uma mensagem tenha sido assinada e verificada com êxito. Preserve o contexto do domínio junto com o registro sugerido. Um administrador que copia um valor da conta de hospedagem errada pode produzir uma solicitação de alteração aparentemente plausível, mas irrelevante.
Para DKIM , diferencie o material de verificação pública de qualquer material de assinatura privada. O registro DNS contém informações de chave pública. As chaves privadas não devem ser coletadas na planilha de aceitação ou coladas em ticket. O protocolo conecta a assinatura de uma mensagem a um domínio de assinatura e seletor; esses identificadores determinam onde um verificador procura a chave. Um domínio visualmente semelhante ou um rótulo de conta genérico não podem substituí-los. RFC 6376 , DKIM-Signature e armazenamento de chaves
O artigo de criação DKIM da Afrihost diz que o registro pode ser copiado para o cluster DNS do domínio após a instalação do registro sugerido. Trate isso como uma razão para estabelecer quem realmente serve DNS autoritativo. Uma visualização de hospedagem local e uma zona pública operada externamente podem exigir propriedade de publicação diferente. Não conclua que o registro público mudou apenas porque uma interface local exibiu uma notificação de sucesso. Geração Afrihost DKIM
Prepare a alteração SPF sem descartar outros remetentes
O caminho documentado da ClientZone é Hosting, o domínio em Shared Hosting, Hosting Settings, DNS Editor e, em seguida, Create New Record. Para SPF , o artigo especifica TXT , um campo de prioridade em branco, o conteúdo SPF copiado e TTL 7200. Essa receita de interface não justifica a criação de uma segunda política SPF quando já existe uma. Revise a política existente e mescle apenas as alterações de autorização aprovadas. Publicação Afrihost SPF
SPF avalia a identidade SMTP , incluindo CORREIO DE, em vez de simplesmente confiar no campo From legível por humanos. Aplicativos de inventário que enviam a identidade relevante antes de modificar sua política. Envios de caixas de correio hospedadas, notificações de sites e uma ferramenta de marketing externa podem ter envelopes e infraestrutura diferentes. Não presuma que o padrão do cPanel inclui todos os serviços que a organização adotou. Identidades RFC 7208 , HELO e MAIL FROM
Mantenha uma política SPF aplicável em nome do proprietário. Revise as inclusões aninhadas e outros termos de consulta de DNS em relação ao limite de prazo avaliado do protocolo. Uma política curta de nível superior ainda pode ter um caminho de dependência excessiva. Registre o método de revisão e o tempo de evidência, mas não rotule um plano não executado como uma avaliação real bem-sucedida. Uma resposta armazenada em cache não dispensa as regras de avaliação. RFC 7208 , múltiplos registros e limites de pesquisa DNS
Resolva a ambiguidade do nome do proprietário DKIM antes da publicação
A página de publicação DKIM da Afrihost descreve a rota ClientZone e cola um valor DKIM TXT . No entanto, seu texto inclui um cabeçalho de instrução rotulado como SPF e um campo genérico de nome de domínio, em vez de um proprietário completo do seletor específico da conta. Esses detalhes não são uma base segura para inventar um registro DKIM de ponta. Obtenha e revise o nome e o valor completo gerado para o domínio real e resolva a convenção de nomenclatura do editor antes de autorizar a publicação. Publicação Afrihost DKIM
No DKIM , o seletor e o domínio de assinatura formam o nome de pesquisa da chave abaixo de _domainkey . O seletor real deve vir da configuração suportada da conta e corresponder às mensagens que estão sendo assinadas. Não forneça um seletor adivinhado apenas porque outro serviço o utiliza. A mesma regra se aplica a uma chave pública copiada: a sua sintaxe por si só não estabelece que o signatário pretendido detém a chave privada correspondente. RFC 6376 , armazenamento de chaves
Confirme se o editor espera um rótulo relativo ou um nome completo do proprietário. As convenções de arquivo mestre DNS incluem uma origem atual, mas os editores gráficos são interfaces de produtos e precisam de sua própria interpretação. O critério de aceitação é o nome do proprietário totalmente qualificado resultante, e não se o operador digitou uma abreviatura familiar. RFC 1035 , formato de arquivo mestre
Interprete os resultados da autenticação de forma restrita
Algumas palavras introdutórias do fornecedor descrevem DKIM como prevenção de spam ou melhoria da entrega. Não transforme essa descrição em uma garantia. DKIM fornece uma assinatura criptográfica e uma identidade de assinatura atribuível; não é a criptografia do corpo da mensagem e não estabelece que todas as instruções comerciais da mensagem sejam seguras. Uma assinatura válida também é distinta de DMARC alinhamento. RFC 6376 , introdução
Para a rota de envio real, uma revisão de aceitação deve relacionar uma identidade SPF ou DKIM aprovada ao domínio visível do autor. DMARC pode passar por qualquer mecanismo alinhado de qualificação. Um registro DNS existente isoladamente não estabelece esse relacionamento para uma mensagem. A autenticação também não garante a entrega, ignora a filtragem de destinatários ou prova que uma conta não foi abusada. RFC 9989 , alinhamento e escopo do identificador
Diagnóstico fictício: o dono da publicação errado
Imagine uma associação fictícia chamada Cedar Trail Club. Seu voluntário obtém um registro DKIM sugerido do domínio cPanel correto e depois copia apenas o valor em uma solicitação de alteração DNS . Outro operador assume que o registro pertence à raiz porque a solicitação não contém nenhum proprietário do seletor. Este é um cenário de planejamento inventado, não uma afirmação sobre um cliente Afrihost ou um teste realizado aqui.
O revisor rejeita a solicitação incompleta sem adivinhar um seletor. O proprietário do aplicativo deve fornecer o registro público gerado completo e identificar a rota de assinatura pretendida. O operador DNS deve confirmar a zona autoritativa e o nome do proprietário resultante. O proprietário da liberação exige então evidências reais da mensagem, obtidas por meio de um processo autorizado, antes de aceitar a assinatura e o alinhamento. A lição corretiva é preservar o relacionamento entre o contexto gerado, a localização da chave pública e a identidade da mensagem, em vez de tratar um valor colado como uma configuração completa.
Planilha de aceitação operacional em branco
Esta planilha é uma proposta. Nenhuma célula é preenchida previamente com um resultado de conta inventado.
- Produto de hospedagem, pacote e contexto de domínio: ______
- Operador cPanel autorizado e referência de aprovação: ______
- Provedor DNS oficial e proprietário da zona: ______
- Política SPF existente e inventário de remetente legítimo: ______
- Valor SPF sugerido e política mesclada revisada: ______
- Nome completo do proprietário DKIM gerado e valor público: ______
- Interpretação do nome do editor e verificação de conflitos: ______
- Observação de registros públicos, carimbo de data/hora e escopo: ______
- Seletor de mensagem real, domínio de assinatura e identidade de envelope: ______
- Evidência de autenticação e alinhamento: ______
- Reversão, proprietário responsável e decisão de liberação: ______
Publicação e retenções operacionais
A aplicabilidade da conta, os controles atuais do produto, a publicação DNS , a ativação da assinatura e a verificação das mensagens recebidas permanecem em aberto. Nenhuma conta foi acessada, nenhum registro sugerido foi instalado, nenhum registro DNS foi criado e nenhuma mensagem de teste foi enviada. A revisão do material humano, a aplicabilidade da fonte, a evidência do catálogo original, as rotas de produção, a acessibilidade visual e a liberação do proprietário também estão abertas. O rascunho não substitui as evidências de implementação exigidas pelo catálogo por este diagnóstico fictício ou pela redação do sucesso instrucional do fornecedor.