Use o fluxo de trabalho de serviço aprimorado para o domínio do remetente real
O serviço aprimorado de entrega de e-mail do Sage Intacct possui um fluxo de trabalho de domínio que inclui registros DNS gerados pela conta e uma etapa de validação separada. Comece com a comunicação financeira que a organização precisa enviar, como uma fatura controlada ou um teste de notificação de pagamento, e depois identifique o domínio do remetente pretendido. Não assuma um velho SPF autorização ou chave do remetente do e-mail prova que a rota aprimorada está pronta. Este guia cobre registro de domínio, revisão de registro e aceitação em nível de mensagem, com verificação de conta ativa ainda pendente.
O actual guia de configurações de domínio diz explicitamente que os domínios principais e subdomínios precisam de autenticação separada. Também distingue Autenticado de Validado: o primeiro ainda requer validação antes que o envio autenticado esteja pronto. Use essas instruções de fluxo de trabalho em vez de interpretar um nome de domínio familiar ou um e-mail anterior bem-sucedido como conclusão. As descrições genéricas dos campos da mesma página também mencionam o envio de subdomínios; como esse texto difere de suas instruções explícitas de autenticação separada, resolva qualquer ambigüidade específica do locatário com o Sage em vez de assumir a autenticação de subdomínio herdada.
Faça um inventário dos endereços de remetentes usados por cada empresa e fluxo de trabalho relevante. Registre qual administrador possui a configuração, qual pessoa pode alterar DNS e quem pode aprovar um teste inofensivo do sistema financeiro. Evite enviar faturas reais ou instruções de pagamento apenas para testar a autenticação. Um teste deve exercitar a rota real do aplicativo usando destinatários controlados e conteúdo de amostra não confidencial.
Estabeleça a propriedade da empresa e do console antes de editar
Abra Empresa, Configuração, Empresa e, em seguida, a guia Segurança e as configurações do domínio do remetente do e-mail, conforme descrito no guia do provedor. Verifique qual empresa ou console possui a configuração do domínio. A documentação atual descreve a herança gerenciada pelo console, portanto, um domínio mostrado em uma empresa pode ser gerenciado em níveis mais altos na hierarquia. Não crie configurações duplicadas no nível da empresa nem remova registros antes de identificar o proprietário.
Registre o estado exato exibido e a data. Se a conta for diferente das instruções públicas, pare na incompatibilidade e pergunte ao administrador autorizado ou ao suporte da Sage sobre o fluxo de trabalho atual. Um artigo de produto não pode estabelecer as permissões ou a hierarquia do locatário da organização. Mantenha as configurações herdadas, as configurações independentes da empresa e os registros mais antigos distinguíveis na solicitação de alteração.
Planeje a reversão com o proprietário financeiro. Pausar um teste é diferente de interromper a execução de uma fatura, e alterar um remetente pode afetar o reconhecimento do cliente ou o tratamento da resposta. Preserve a configuração aprovada anteriormente e escolha uma janela que evite atividades críticas de faturamento. A limpeza da autenticação não deve alterar silenciosamente quem parece ter enviado um aviso financeiro.
Gere e preserve a tabela de registros específicos do domínio
Para um novo domínio aprovado, use o fluxo de trabalho documentado de adição e autenticação e salve a tabela DNS gerada para esse domínio. O guia público descreve uma tabela com um SPF CNAME, dois DKIM CNAMEs, entradas TXT de segurança do remetente e uma entrada SPF legada para compatibilidade. Copie os proprietários reais da conta, tipos de registro e valores. Nenhuma amostra seletor, o token longo ou o valor da captura de tela neste artigo são uma configuração reutilizável.
Mantenha a tabela gerada com o ticket de alteração e anote a finalidade de cada linha. Distinguir o proprietário SPF delegado do serviço aprimorado da política SPF mais antiga no domínio principal. Trate o valor TXT de verificação da empresa como seu próprio registro, em vez de dobrá-lo em uma string SPF . Diferentes controles podem compartilhar a zona DNS sem compartilhar uma sintaxe ou finalidade operacional.
O Guia de validação DNS explica a verificação das alternativas de segurança do remetente e observa que uma dessas entradas é suficiente para a verificação descrita. Confirme a escolha apropriada na tabela gerada, especialmente para configuração gerenciada pelo console. Preservar a incerteza se a conta real exigir um arranjo diferente; não use um exemplo para substituir suas instruções atuais.
Publique registros preservando os serviços de correio existentes
Exporte primeiro os registros DNS afetados. Compare cada proprietário emitido com registros e delegações existentes. Um conflito CNAME precisa de uma resolução suportada pelo administrador, e não de um segundo registro de outro tipo no mesmo proprietário. Verifique se o editor DNS espera um rótulo relativo ou um nome totalmente qualificado e verifique o nome público resultante após salvar. A resposta final DNS é a evidência que importa.
Quando a entrada SPF de compatibilidade com versões anteriores exigir uma alteração em uma política existente, revise a política completa em RFC 7208. Mantenha uma política SPF no proprietário avaliado, preserve outros remetentes ativos e leve em conta os termos de consulta de DNS aninhados. Não cole um adicional Registro SPF ao lado do existente. Não remova a autorização herdada simplesmente porque os registros aprimorados estão presentes; primeiro estabeleça se algum fluxo de trabalho ativo ainda depende dele.
Mantenha os registros públicos separados das credenciais e dos segredos do aplicativo. A tabela DNS é adequada para o administrador DNS autorizado, mas um pacote de evidências não precisa de exportações irrestritas de locatários ou dados de clientes. Edite detalhes desnecessários da transação enquanto preserva contexto suficiente para associar um teste ao seu fluxo de trabalho e à empresa.
Verifique os proprietários emitidos e conclua a validação
Verifique o proprietário e o destino exatos de cada CNAME e, em seguida, verifique se a pesquisa delegada é resolvida conforme o esperado. Verifique DKIM usando os seletores reais mostrados na tabela gerada. O guia de validação do provedor contém formatos de seletores ilustrativos; copiar esses exemplos para um locatário diferente não é um teste válido. Registre o tempo de pesquisa, o resolvedor e o valor retornado para que um revisor posterior possa distinguir dados obsoletos de um erro de transcrição.
Retorne ao domínio selecionado nas configurações do domínio do remetente de e-mail e use Validar domínio. Preservar o estado ou erro resultante. Os caches DNS e as verificações do provedor podem atrasar o reconhecimento, portanto, evite regenerar repetidamente a configuração enquanto os registros ainda estão sendo estabelecidos. Se a validação falhar, compare primeiro os nomes, tipos e valores publicados e, em seguida, investigue a linha precisa que não está resolvida.
Um estado Validado é uma prova de inscrição útil, mas não prova que a fatura ou notificação pretendida utilizou essa identidade. Mantenha o próximo teste de nível de mensagem como uma porta separada. Um administrador deve ser capaz de mostrar a prontidão do domínio e o resultado do destinatário para uma mensagem representativa do fluxo de trabalho comercial.
Verifique mensagens financeiras em um receptor externo controlado
Acione um teste autorizado de cada empresa materialmente diferente ou fluxo de trabalho de envio. Salve o ID da mensagem, a hora UTC, o remetente pretendido e a ação do aplicativo que produziu a mensagem. Registre também para onde vai a resposta. Um endereço de resposta pode ser operacionalmente importante sem ser o domínio que SPF avalia ou assina DKIM .
Inspecione os resultados de autenticação confiável do sistema receptor. Grave o visível de, Return-Path e cada DKIM d= domínio de assinatura e s= seletor. RFC 6376 define o relacionamento entre esses campos DKIM e a chave de verificação DNS . Uma verificação DNS bem-sucedida para um seletor configurado não estabelece que a mensagem o utilizou; a assinatura real resolve essa questão.
Sob RFC 9989, DMARC requer um resultado SPF ou DKIM aprovado com o relacionamento apropriado com o domínio De. Aplique o configurado do domínio alinhamento modo e registre qual mecanismo fornece a passagem alinhada. Uma notificação de pagamento recebida em uma caixa de entrada não prova alinhamento e a autenticação não prova a exatidão ou legitimidade de uma instrução financeira. Esses são controles de negócios separados.
Investigue falhas usando a evidência do aplicativo e da mensagem
Se nenhuma mensagem de teste chegar, estabeleça se o aplicativo tentou enviá-la antes de alterar DNS . Preserve a entrada ou erro relevante do histórico de entrega. O guia do domínio identifica diferentes visualizações do histórico dependendo do estado de validação do domínio; use a visão apropriada para esse estado em vez de interpretar uma visão vazia como prova de que nada aconteceu.
Se a mensagem chegar com um De inesperado, reconcilie a seleção do remetente do fluxo de trabalho com o inventário de domínio autenticado. Se DKIM estiver ausente ou falhar, compare o seletor real e a resposta pública e verifique se um gateway downstream modificou a mensagem. Se SPF for aprovado, mas DMARC falhar, examine o alinhamento. Uma autorização root adicional não reparará todas as incompatibilidades de domínio de envelope.
Escale com o identificador da empresa ou do console, estado do domínio, linhas DNS afetadas, tempo de teste e evidência de autenticação editada. Mantenha os detalhes financeiros reais do cliente fora do exemplo de suporte. Preservar a política DMARC existente, a menos que o seu proprietário aprove uma mudança mais ampla que abranja todos os remetentes legítimos.
Planilha de domínio Sage Intacct
- Proprietário da Empresa ou Console e administradores responsáveis: ____.
- Fluxo de trabalho comercial, remetente pretendido e caixa de correio de resposta: ____.
- Domínio principal ou subdomínio registrado separadamente: ____.
- Referência da tabela DNS gerada e data de instrução: ____.
- Delegação SPF aprimorada e verificações de registro DKIM : ____.
- Escolha de segurança do remetente e revisão de dependência SPF legado: ____.
- Estado do domínio exibido antes e depois da validação: ____.
- Teste o ID da mensagem, a hora UTC e a referência do histórico de entrega: ____.
- Identidades observadas de, Return-Path , DKIM e resultado alinhado: ____.
- Exceções, recuperação aprovada e revisor: ____.
Exemplo fictício de parar no status errado
Apenas casos escritos fictícios: SI-01 assume que o domínio pai example.org é validado no console proprietário, mas o fluxo de trabalho da fatura pretende From invoices@billing.example.org . A inscrição em billing.example.org é desconhecida e não existem resultados recebidos. O administrador financeiro deve verificar o subdomínio autenticado separadamente e o fluxo de trabalho real antes de agendar o teste inofensivo; o status do domínio pai não pode estabelecer cobertura. Se o status exibido for apenas Autenticado, conclua primeiro a validação DNS . Nenhuma fatura, inquilino ou transação real foi inspecionada.
Guarde os portões de liberação restantes
A inspeção atual do inquilino, a revisão dos registros gerados, DNS ao vivo e a verificação do cabeçalho, a revisão visual e a aprovação humana do PME permanecem pendentes. Resolva qualquer discrepância entre a documentação pública e a empresa ou Console real antes da publicação. Este artigo é um rascunho de implementação não publicado e não uma confirmação de que as mensagens financeiras de uma organização estão prontas para produção.
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.