Estabeleça que o correio realmente usa o serviço de saída
Herói de Spam SPF e DKIM guia diz explicitamente respeito ao seu serviço SMTP de saída. A página é datada de 6 de novembro de 2026 e foi revisada para este manuscrito em 9 de novembro de 2026. Sua visão geral de saída distingue maneiras de rotear correspondências de saída por meio do serviço. Uma organização que usa o SpamHero apenas para filtragem de entrada não deve presumir que suas mensagens enviadas serão automaticamente cobertas.
Registre a conta, o domínio, o sistema de correio de origem e o caminho de retransmissão pretendido. Identifique se a organização é um cliente direto ou trabalha através de um revendedor, pois as instruções documentadas SPF distinguem esses casos. Registre também quais categorias de correio ignoram a retransmissão, se houver; uma rota funcional para uma origem não estabelece todos os remetentes na organização.
Esta é uma orientação documental e um processo de aceitação proposto. Nenhuma credencial de retransmissão, configuração de conta, conector ou registro DNS foi criada ou alterada. A aplicabilidade da conta corrente e o requisito mais amplo de implementação do catálogo permanecem em aberto. Guia de autenticação de saída; Visão geral do serviço de saída
Aplicar a instrução SPF apropriada a uma política completa
Para uma conta direta com uma política SPF existente, o guia instrui os administradores a adicionar include:spf.spamhero.com antes do mecanismo de encerramento de todos. Ele diz explicitamente aos revendedores para usarem a inclusão publicada na área do revendedor. Essa distinção deve permanecer visível na solicitação de mudança, em vez de ser perdida quando um exemplo é copiado.
A página também fornece uma política inicial para um domínio sem SPF , incluindo um mecanismo a e encerramento softfail . Não trate esse ponto de partida como uma decisão de autorização automática para todas as organizações. Revise se cada mecanismo proposto representa um remetente pretendido e conta para outros serviços de saída legítimos.
Vários selecionados Registros SPF produzir um erro, portanto, não crie uma política separada apenas para o SpamHero quando já existir uma. Preservar a ordem dos mecanismos e revisar os termos de avaliação dependentes do DNS aninhados. Uma edição de texto bem-sucedida não é prova de que o caminho da mensagem relevante esteja autorizado ou alinhado. Habilitando SPF; RFC 7208 , seção 3.2; RFC 7208 , seção 4.6.4
Distinguir a ativação DKIM da assinatura de domínio personalizado
O caminho documentado do provedor é Saída > Configurações de saída. Em Outras configurações, selecione Habilitar assinatura DKIM para mensagens de saída. O guia então descreve os opcionais exibidos CNAME registros: configurá-los faz com que o serviço assine usando o domínio do cliente; caso contrário, ele assina usando um domínio interno.
Essa distinção é central para a aceitação. Uma mensagem pode conter uma assinatura válida enquanto usa uma identidade diferente do domínio de autor visível da organização. Registre se o resultado pretendido é apenas assinatura de provedor ou assinatura de domínio personalizado e retenha os aliases exatos exibidos na conta para o último. Não invente um seletor ou presumir que as metas de outro cliente se aplicam.
Antes da publicação, compare os nomes emitidos com os registros existentes e o comportamento real do sufixo do editor DNS . Revise os conflitos e preserve um estado anterior. O guia público fornece o fluxo de trabalho, mas não prova que a alternância de assinatura de qualquer conta esteja habilitada ou que seus aliases tenham sido publicados. Habilitando DKIM
Mantenha a filtragem de entrada e a autorização de saída separadas
Receber mensagens por meio de um gateway de filtragem e enviar mensagens por meio de uma retransmissão de saída são caminhos diferentes. O inventário proposto deve mostrar ambos quando relevante, mas a alteração na autenticação de saída deve ser justificada pelo caminho de envio. Não adicione autorização de remetente apenas porque o endereço IP de um provedor aparece em um salto de entrada.
SPF avalia o remetente da conexão em relação à política para sua identidade SMTP especificada, incluindo CORREIO DE. O endereço De visível não é automaticamente o domínio de pesquisa de política. DMARC adiciona um alinhamento comparação com o domínio do autor, portanto, um resultado aprovado para uma identidade de serviço não relacionada pode não satisfazer o resultado pretendido pela organização.
Se um sistema de correio já assina mensagens antes da retransmissão, preserve e inspecione as assinaturas resultantes em vez de presumir que elas permanecem válidas durante cada transformação. A aceitação proposta deve identificar o conteúdo final assinado e os resultados do receptor confiável. Este manuscrito não desativa as verificações de entrada nem altera os controles de segurança para fazer uma mensagem passar. RFC 7208 , seção 2.4; RFC 6376 , seção 3.5; RFC 9989 , seção 4.4
Verifique a rota recebida e suas identidades
A verificação final proposta é uma mensagem de representante autorizado que realmente atravessou a rota de saída pretendida. Retenha uma extração de cabeçalho minimizada com seu domínio de autor, identidade de envelope quando disponível, domínio e seletor de assinatura DKIM e resultados confiáveis do sistema de recebimento. Registre a hora de envio e o sistema de origem para que a evidência de outro caminho não possa ser substituída acidentalmente.
Compare o domínio de assinatura observado com a configuração de domínio personalizado pretendida. Se continuar sendo um domínio de serviço interno, revise se os aliases exibidos e a configuração de assinatura da conta correspondem ao design proposto. Não conclua que toda a autenticação falhou apenas porque uma assinatura não está alinhada; examinar as identidades de passagem relevantes de acordo com as regras do DMARC .
Separe a aceitação de autenticação dos eventos de entrega de retransmissão, posicionamento na caixa de entrada e envolvimento do destinatário. A linguagem de entregabilidade do provedor não é uma garantia de que todos os destinos aceitarão ou exibirão a mensagem. Da mesma forma, uma mensagem autenticada não estabelece que sua solicitação comercial seja legítima. RFC 9989 , seção 4.4; Assinatura personalizada versus assinatura interna
Planilha de aceitação para uma transferência de retransmissão de saída
Use esta planilha proposta original para conectar o sistema de origem, o tipo de conta e a identidade final recebida.
- Escopo da rota: conta, relacionamento direto ou com revendedor, sistema de correio de origem e caminho real de retransmissão de saída.
- Cobertura: categorias de mensagens incluídas, rotas de desvio e proprietários responsáveis por quaisquer exceções.
- Solicitação SPF : inclusão direta ou do revendedor correta, política afetada completa e fontes legítimas preservadas.
- Intenção DKIM : assinatura de domínio interno ou domínio personalizado, configuração de conta relevante e registros CNAME exibidos exatos.
- Revisão DNS : nomes de proprietários pretendidos, alvos de alias, conflitos existentes e escopo de publicação aprovado.
- Evidência de mensagem: amostra autorizada, carimbo de data/hora da rota, autor e domínios de assinatura, seletor e resultados confiáveis.
- Controles de segurança: confirmação de que a filtragem de entrada, os conectores e as credenciais não foram alterados fora da tarefa aprovada.
- Liberação: revisor, proprietário da reversão e evidência de produção ou conta corrente não resolvida.
Esta planilha é uma orientação de planejamento em branco. Ele não contém senhas, segredos de API, corpos de mensagens reais ou resultados de verificação executados.
Diagnóstico fictício: DKIM passou para um domínio interno
Uma organização fictícia habilita DKIM de saída e vê um resultado DKIM aprovado em uma amostra. Anuncia que seu próprio domínio agora está autenticado sem comparar o domínio de assinatura da assinatura com o endereço visível do autor. Em vez disso, a amostra mostra uma identidade de serviço interna.
A revisão proposta distingue a assinatura bem-sucedida do provedor do alinhamento de domínio personalizado desejado. A equipe verifica a etapa CNAME documentada e os valores reais da conta, preservando ao mesmo tempo a política SPF existente e os remetentes não relacionados. Ele também verifica se a amostra atravessou a retransmissão de saída pretendida em vez de outra origem de correio.
Nenhuma política é enfraquecida simplesmente para alterar a aparência do painel, e nenhuma regra de filtragem de entrada é alterada para reparar uma lacuna na configuração de saída. A entrega final registra as evidências que ainda precisam ser coletadas após uma alteração autorizada. Este é um diagnóstico fictício, não um incidente real do SpamHero ou um teste de e-mail executado.