Comece com a notificação em vez do nome da marca
Um lembrete de funcionário e um e-mail de candidato podem parecer vir da mesma organização, embora usem configurações de remetente ou rotas de entrega diferentes. Comece com a notificação que a empresa precisa entregar. Registre seu módulo SuccessFactors, ID da empresa, datacenter, endereço De configurado e qualquer retransmissão de cliente. Adicione uma linha de inventário separada sempre que um desses limites for alterado. Este guia aborda a rota de notificação do SuccessFactors HCM descrita na documentação de suporte público da SAP, e não todos os produtos que levam o nome SAP.
O alvo é uma mensagem recebida que preserva a identidade visível pretendida e possui um passe de autenticação alinhado. Publicação um recorde é uma etapa intermediária. Uma entrega interna bem-sucedida também pode ser enganosa se o gateway da organização tiver uma exceção especial para o tráfego SAP. Mantenha o teste de aceitação interno e o teste de autenticação externo separados.
Prepare a solicitação de suporte e a mudança DNS juntos
Em SAP KBA 2688533, “Como solicitar/habilitar a implementação DKIM ou SPF ?”, a SAP direciona DKIM solicitações ao componente LOD-SF-PLT-NOT com ID da empresa, datacenter e lista completa de domínios. Suas notas tornam a configuração no escopo do datacenter e permitem até 48 horas após a adição da chave. O mesmo KBA lista A, SPF e pré-requisitos MX para o serviço SAP. Trate-os como requisitos do fornecedor e não como uma definição universal de DKIM .
Designe uma pessoa para o caso SAP e outra para a zona DNS autoritativa se essas responsabilidades forem divididas. A transferência deve conter o domínio exato, a identidade de assinatura solicitada, o proprietário DNS , o tipo de registro, o valor público, o TTL e as expectativas de ativação acordadas. Mantenha as chaves privadas e as credenciais fora da planilha. Não infira o seletor de outra implementação SAP ou de uma captura de tela antiga.
Antes de editar DNS , exporte os registros atuais e identifique quem possui qualquer registro existente no nome DKIM proposto. Uma colisão de seletores é uma condição de parada, não uma permissão para substituir um serviço ativo. Peça à SAP para resolver isso. Se um formulário DNS adicionar o sufixo de domínio automaticamente, insira o proprietário no formato que produz o nome totalmente qualificado necessário e verifique o resultado publicado posteriormente.
Selecione a entrada SPF do datacenter atual
Usar SAP KBA 2087468, “ SPF ” e “Entradas SuccessFactors DC SPF ”, não uma lista genérica copiada de outra conta. A SAP alerta contra a inclusão de grandes datacenters. Sua tabela também identifica entradas de substituição para datacenters migrados, portanto, uma inclusão historicamente correta não é suficiente para estabelecer a configuração atual. Confirme o local de hospedagem real com o proprietário do inquilino antes de escolher uma entrada.
Mantenha o remetente visível configurado no inventário. O mesmo KBA discute endereços de remetente único e específicos de módulo, mas um endereço exibido ao usuário não informa qual domínio um servidor receptor avalia para SPF . RFC 7208 , seção 2.3 especifica o CORREIO DE identidade. Obtenha-o a partir de uma mensagem recebida controlada ou da evidência de entrega relevante antes de decidir o que uma passagem SPF prova.
Mesclar apenas a autorização necessária na política existente do proprietário apropriado. Preservar outros remetentes legítimos. Não crie uma segunda política SPF , substitua o qualificador final atual da organização sem revisão ou copie uma amostra que omite os serviços existentes. As seções 4.5 e 4.6.4 da RFC 7208 cobrem a seleção de registros e o limite de dez prazos para mecanismos e modificadores de consulta de DNS. Contar pesquisas aninhadas, não apenas o número de inclusões visíveis na sequência de nível superior.
O registro de mudança útil é uma política de antes e depois, além de sua revisão de avaliação. Deve explicar por que cada nova autorização SAP é necessária e qual evento desencadeará sua remoção. Uma migração de datacenter merece uma nova verificação, em vez de uma lista cada vez maior de entradas antigas e novas.
Trate uma retransmissão do cliente como uma rota diferente
Se o seu locatário usar uma retransmissão de cliente, peça ao proprietário do email para desenhar o caminho completo, incluindo qualquer gateway de saída final. A seção “Retransmitir correspondência através dos servidores de correio de um cliente” do SAP KBA descreve um arranjo alternativo. Suas restrições atuais não são motivo para introduzir um relé casualmente. Confirme a configuração suportada e a responsabilidade pela entrega com a SAP e a equipe de recebimento de correspondência antes de propor uma alteração de roteamento.
Um relé pode alterar o IP de envio, a identidade do envelope, o conjunto de assinaturas DKIM e o ponto onde o conteúdo é modificado. Um teste enviado pela rota padrão do SAP não pode validar um caminho de produção retransmitido. Da mesma forma, uma assinatura criada no início da rota pode não sobreviver a alterações posteriores. Registre qual serviço deverá fornecer o resultado final da autenticação alinhada.
Não coloque credenciais de retransmissão em um anexo de ticket ou registro DNS público. Use o processo de credenciais aprovado pela organização e o canal seguro designado pela SAP quando uma configuração de retransmissão separada for autorizada. Este guia não configura credenciais, altera roteamento ou afirma que um serviço personalizado universal Return-Path existe controle.
Publicar e verificar o registro público emitido
Compare a resposta oficial ao vivo com o registro fornecido para a solicitação. Confirme se o proprietário não está duplicado, se a chave pública completa está presente e se o tipo de registro está correto. Verifique o resultado em mais de um resolvedor quando as respostas armazenadas em cache discordam e retenha os tempos de observação. Um console DNS mostrando “salvo” não é a evidência que um receptor usa.
Peça à SAP para confirmar a ativação dos domínios e datacenter listados. Registre a referência do caso e o tempo de ativação sem tratar a passagem de 48 horas como prova. Se um novo teste não tiver a assinatura esperada, primeiro verifique se ele foi gerado após a ativação e veio da rota pretendida. A regeneração repetida de chaves pode criar incerteza adicional enquanto o problema de roteamento original permanece sem solução.
RFC 6376 , seção 3.5 define os campos de domínio de assinatura e seletor usados para localizar uma chave de verificação. Capture cada par DKIM d= e s= da mensagem final. Uma assinatura de domínio de provedor pode ser tecnicamente válida, mas não se alinha com o domínio De escolhido.
Teste cada caminho de notificação significativo
Use conteúdo inofensivo e destinatários controlados. Evite detalhes reais de candidatos, registros de funcionários, anexos de inscrições ou anúncios de toda a produção. Quando a empresa precisar de vários tipos de notificação, selecione mensagens representativas sem presumir que um sucesso abrange todas elas. Mantenha o identificador da mensagem e o horário de envio UTC para que a mesma entrega possa ser rastreada através do SAP e do sistema de recebimento.
Para cada mensagem, registre o domínio De visível, a identidade do envelope relatada pelo destinatário, todas as identidades DKIM , resultado SPF , resultados DKIM e DMARC resultado. Use o confiável do destinatário final Authentication-Results, não cabeçalhos arbitrários com nomes semelhantes transportados pela mensagem. Registre a política e alinhamento modo que o receptor avaliou.
RFC 9989 , seção 4.4, “Alinhamento do identificador explicado” requer um resultado SPF ou DKIM aprovado alinhado para DMARC . A planilha deve identificar o mecanismo que fornece essa passagem. “Entregue”, “ TLS usado” e “SAP aparece em nossa lista de permissões” são observações diferentes e não devem ocupar o campo de evidências DMARC .
Se SPF passar em um domínio de envelope não relacionado, adicionar mais autorizações SPF ao domínio De visível não alinhará esse passe específico. Investigue a identidade DKIM pretendida e a rota suportada. Se DKIM falhar, diferencie a chave ausente, o seletor incompatível, o registro público malformado e a modificação pós-assinatura antes de alterar a política.
Use a planilha de aceitação de rota
Crie um registro de revisão separado para a planilha de domínio e datacenter do SuccessFactors usando os campos abaixo. Complete uma cópia por rota de envio significativa. Inclui o caso SAP, registro DNS emitido, autorização do datacenter, confirmação de ativação, identidades do receptor, decisão de alinhamento e proprietário de recuperação. Deixe os campos não observados em branco e marque a próxima ação em vez de substituir um valor de amostra.
O registro de aceitação deve responder a três perguntas: a SAP ativou a identidade pretendida, DNS público a suporta e o destinatário validou uma mensagem dessa rota exata? Exija todos os três. Registre resultados separados para o teste externo e o gateway interno da organização para que um desvio não esconda a diferença.
Exemplo fictício: a suposição errada do datacenter
Somente caso escrito fictício: SF-01 pressupõe o pretendido From hiring@careers.example , mas a primeira notificação usa um provedor cujo endereço exato é desconhecido. Os resultados de DKIM , seletor e envelope/ SPF são desconhecidos. Uma solicitação de datacenter antigo não é evidência do locatário atual. O proprietário dos sistemas de RH deve confirmar o datacenter atual e o remetente da notificação, obter a ativação para essa rota e, em seguida, inspecionar uma nova mensagem externa inofensiva. Nenhum veredicto DMARC é inferido e nenhum locatário, DNS ou mensagem foi testado.
Recuperar sem ampliar a falha
Pause a alteração da notificação afetada quando os testes críticos para os negócios falharem e use a rota de entrega aprovada anteriormente, se existir. Coordene qualquer reversão com a SAP e o proprietário da correspondência. Não exclua uma chave pública enquanto mensagens recém-enviadas ou enfileiradas ainda exigirem isso, e não enfraqueça a política DMARC de toda a organização apenas para fazer uma rota parecer bem-sucedida.
Teste novamente após a migração do datacenter, alterações no domínio do remetente, alterações na retransmissão e alterações no roteamento de notificações. Este continua a ser um rascunho de implementação não publicado: a revisão do inquilino em tempo real, os registros emitidos pela conta, as observações DNS , a evidência de identidade das mensagens recebidas, a revisão visual e a aprovação humana das PME estão pendentes. Preserve-os como portas de aceitação, em vez de tratar silenciosamente a pesquisa documental como uma implantação concluída.
Disponibilidade de fonte e confirmação de implementação
As duas páginas SAP KB foram recuperadas como texto público nos instantâneos de origem preservados de 8 de novembro de 2026. Durante esta revisão, a abertura inicial identificou novamente o conteúdo de resolução pública, mas a seção posterior abriu visualizações com necessidade de login. As instruções detalhadas acima, portanto, baseiam-se nas cópias preservadas da fonte primária, e não na afirmação de que as páginas completas permanecem legíveis publicamente. Confirme a entrada atual do datacenter, os pré-requisitos de serviço e o fluxo de trabalho de ativação com a SAP antes de fazer alterações. Nenhum login ou desvio de acesso foi tentado.
Separe uma mensagem passageira da prontidão para aplicação
RFC 9989 A seção 7.4 exige DKIM válido para publicação de domínio p=reject e alertas sobre a interoperabilidade de correio indireto. Um único resultado alinhado SPF não justifica, por si só, uma implementação de política de rejeição. Revise todas as rotas legítimas e propriedade de políticas separadamente da configuração deste provedor.