Identifique a rota do Cloud SMTP Relay
Check Point Harmony Email inclui várias funções de segurança e fluxo de correio. Este guia aborda a configuração documentada do Cloud SMTP Relay, e não a suposição de que a ativação da inspeção de entrada assina automaticamente as mensagens de saída. O fluxo de trabalho relevante utiliza configuração de domínio, verificação DNS e uma fonte de retransmissão habilitada. Confirme se o locatário realmente oferece e usa essa rota antes de aplicar suas instruções. O licenciamento, a disponibilidade regional e a configuração da conta atual não foram verificados aqui.
As instruções de domínio do provedor usam Configurações de Segurança, Retransmissão e Domínios. Suas instruções de ativação separadas usam fontes de retransmissão. Essa separação é operacionalmente importante: um domínio verificado e uma fonte autorizada a enviar mensagens de saída são controles relacionados, mas não são o mesmo controle. Não informe que a retransmissão está pronta apenas porque um valor DNS foi copiado em uma solicitação de alteração. Configuração do Check Point DKIM Ativação do relé Check Point
Mapeie cada identidade e seu proprietário
Antes de obter os registros, identifique o aplicativo ou servidor de correio que será enviado por meio da retransmissão. Registre sua equipe responsável, o domínio visível do autor pretendido e o domínio utilizado para o envelope SMTP . Não infira esses valores a partir de uma configuração de caixa de correio de entrada ou do nome de uma política de segurança. O inventário deve distinguir uma configuração de conta conhecida de uma expectativa que aguarda confirmação.
SPF avalia identidades SMTP em vez de simplesmente o campo De visível. DKIM associa uma assinatura a um domínio de assinatura e seletor. DMARC em seguida, avalia se um identificador autenticado qualificado está alinhado com o domínio do autor visível. Esses relacionamentos de protocolo explicam por que a configuração da retransmissão deve ser avaliada em relação às identidades reais das mensagens, e não apenas a um painel de segurança de marca. RFC 7208 , identidades SMTP RFC 9989 , alinhamento de identificador
Atribua um proprietário DNS e um proprietário de aplicativo antes da alteração. O operador DNS precisa de valores de registros públicos e dos nomes de proprietários totalmente qualificados pretendidos. Eles não precisam de credenciais SMTP , material de assinatura privada ou dados de usuário não relacionados. Qualquer acesso futuro à conta ou ativação de retransmissão deve seguir o processo de aprovação da organização. Este manuscrito não executa nenhuma dessas ações.
Resolva o defeito do exemplo SPF em vez de copiá-lo
A página SPF de agosto de 2026 do provedor orienta a operadora a selecionar o domínio, abrir Configurar SPF , adicionar ou atualizar o registro e usar o Verify. Sua amostra contém include:spfr.cpmails.com, mas a tabela rotula o tipo de registro MX enquanto apresenta um valor de texto SPF . Isso é uma inconsistência de fonte, não uma instrução válida para publicar SPF como um Registro MX. Obtenha as instruções DNS suportadas pela conta atual e resolva a incompatibilidade antes de alterar a produção. Configuração SPF do ponto de verificação
RFC 7208 exige publicação SPF no DNS Registros TXT. Um registro MX identifica trocadores de e-mail e não pode carregar uma política SPF da maneira sugerida pelo exemplo. Mantenha a inclusão documentada como um exemplo de provedor com escopo definido, e não como prova de que ele se aplica universalmente a todas as implantações ou regiões do Harmony. O nome real do proprietário e a apólice completa permanecem sujeitos à confirmação da conta. RFC 7208 , registros de recursos DNS
Revise a política SPF existente antes de propor uma adição. Preserve aplicativos ainda autorizados, mantenha uma política aplicável e avalie dependências aninhadas. O limite de termos de consulta de DNS avaliados não é simplesmente uma contagem de palavras incluídas de nível superior. Não altere um mecanismo político final existente apenas para o tornar semelhante a uma amostra. Registre a decisão de segurança pretendida e a política completa de antes e depois separadamente de qualquer resultado de verificação do provedor. RFC 7208 , múltiplos registros e limites de pesquisa
Publique todo o conjunto DKIM fornecido pela conta
O guia DKIM usa Configurar DKIM no domínio selecionado e exige explicitamente que todos os cinco registros DKIM sejam inseridos no DNS . Sua tabela ilustrativa mostra uma CNAME, mas o exemplo não é uma configuração completa de conta com cinco registros. Não crie apenas um exemplo visível, extrapole os outros nomes ou reutilize um destino de exemplo de outro domínio. Preserve o conjunto completo gerado para o locatário e o domínio reais. Configuração do Check Point DKIM
Para cada alias fornecido, revise o nome do proprietário, o destino, o tipo de registro e os conflitos de registro existentes. Confirme o tratamento dos sufixos de domínio pelo editor. A verificação deve estabelecer o nome DNS resultante em vez de assumir que cada interface espera um rótulo relativo ou um nome totalmente qualificado. Uma captura de tela com aparência correta pode ocultar um sufixo duplicado ou uma entrada na zona errada.
O provedor instrui o operador a usar o Verify após a publicação e descreve a mudança do domínio para Verified. Preserve esse resultado como evidência da etapa de validação do produto. Ele não substitui uma avaliação posterior de qual domínio de assinatura e seletor aparece no e-mail real, ou se um destinatário verificou e alinhou essa assinatura com sucesso. Configuração do Check Point DKIM RFC 6376 , assinatura e armazenamento de chaves
Revise a ativação da fonte de retransmissão separadamente
A página de ativação de novembro de 2026 diz para ativar a fonte pretendida, inspecionar o host e a porta de retransmissão exibidos, verificar o domínio configurado e os endereços IP de envio e, em seguida, ativar a retransmissão. Sua porta padrão é 25 com STARTTLS apoiar. Use os detalhes reais da conexão regional exibidos em vez de inventar um terminal universal. Não converta o suporte STARTTLS em uma afirmação de que cada conexão downstream foi criptografada ou que uma mensagem específica foi entregue. Ativação do relé Check Point
Trate a ativação da fonte como uma mudança operacional consequente que exige aprovação apropriada e plano de reversão. Uma tarefa de verificação de domínio não autoriza automaticamente a ampliação do acesso de retransmissão para endereços ou aplicativos adicionais. Mantenha a lista de fontes aprovadas restrita e explique como cada entrada se relaciona a um remetente comercial real. O pacote de aceitação final deve distinguir a prontidão DNS , o estado da fonte habilitada e a evidência de envio bem-sucedido.
Diagnóstico fictício: dois atalhos em uma mudança
Imagine uma empresa fictícia, a Birchline Repairs, preparando notificações de seu aplicativo de serviço. Sua solicitação de alteração copia o rótulo MX do exemplo SPF e inclui apenas o único alias DKIM visível na tabela pública. A solicitação então descreve todo o relé como pronto. Este cenário é fictício e nenhum registro ou mensagem DNS foi testado.
O revisor interrompe a solicitação incompleta. A política SPF deve usar TXT e ser reconciliada com os remetentes existentes no domínio. O proprietário do aplicativo deve obter o conjunto DKIM completo de cinco registros da configuração de domínio correta. O proprietário da fonte de retransmissão deve confirmar separadamente o sistema de envio pretendido e o status de ativação. O problema não é uma interrupção de autenticação observada; é uma cadeia de evidências incompleta que tornaria prematura qualquer alegação de prontidão.
Planilha de aceitação em branco
- Produto Harmony exato, rota de retransmissão e aplicabilidade do locatário: ______
- Inscrição, fonte do envio e proprietário responsável: ______
- Autor visível e identidade real do envelope: ______
- Instruções SPF da conta corrente e resolução de incompatibilidade de tipo: ______
- Política SPF completa existente e proposta: ______
- Todos os cinco registros DKIM , proprietários e alvos: ______
- Observações DNS e carimbos de data/hora oficiais: ______
- Resultado e limitações da verificação de domínio: ______
- Fonte de retransmissão, host regional e porta aprovados: ______
- Aprovação de ativação, reversão e status observado: ______
- Assinatura de mensagem recebida e alinhamento evidência: ______
A aceitação permanece aberta
A planilha não está preenchida com valores presumidos de locatário. Nenhum registro foi publicado, fonte habilitada, credenciais tratadas ou mensagens enviadas. Evidências originais do catálogo, revisão de assuntos humanos, aplicabilidade da fonte, rotas de produção, acessibilidade visual e liberação do proprietário permanecem em aberto. A autenticação pode suportar a validação de identidade, mas não garante a colocação na caixa de entrada nem estabelece que o conteúdo de uma mensagem é inofensivo.