Defina o escopo da configuração para o recurso de remetente documentado do Moloni
A documentação de suporte em português da Moloni descreve o envio de documentos e notificações a partir do seu endereço padrão ou do próprio domínio de um cliente elegível. Este guia cobre esse recurso do Moloni, não o Moloni ON ou uma integração genérica Mailgun . Uma marca semelhante não torna aplicável a receita DNS de outro produto. Confirme a configuração real do produto, conta, plano e remetente atual antes de propor alterações. Um domínio de site ou caixa de correio hospedado em outro lugar não é automaticamente autorizado para a infraestrutura de envio do Moloni.
O guia de configuração do remetente identifica faturas@moloni.pt como endereço padrão e descreve o envio personalizado para clientes do Plano Pro que podem configurar o seu domínio. Exclui endereços em domínios que o cliente não controla, dando exemplos como Gmail , Sapo e Hotmail. Esses limites são requisitos do provedor e não um convite para criar registros DNS para um domínio de caixa de correio pública. Nenhuma elegibilidade da conta ou estado real de envio foi verificado aqui.
Estabeleça a elegibilidade antes de ativar o endereço personalizado
O guia diz que clientes fora do Plano Pro que já tinham o recurso ativado podem solicitar a reativação, com Moloni verificando SPF e elegibilidade. Essa exceção não é uma promessa geral de que todas as contas não-Pro possam ativar o recurso. Obtenha uma decisão de elegibilidade específica da conta atual por meio do processo normal de suporte aprovado da organização, se necessário. Este artigo não envia uma mensagem de suporte, não faz uma compra nem assume que uma atualização foi autorizada.
Faça um inventário das categorias de mensagens que usam o remetente configurado. Moloni lista documentos, modelos de identificação, clientes, listagens de vendas pendentes, eventos programados e alertas de estoque. Não se deve presumir que uma configuração testada apenas em um documento manual abrange todas as categorias programadas ou automatizadas. Atribua um proprietário para as consequências comerciais de uma alteração de remetente, especialmente quando os destinatários dependem de uma identidade de cobrança familiar. Mantenha essa preocupação operacional separada da questão técnica de saber se o domínio remetente é autenticado.
Revise os requisitos técnicos atuais com o proprietário DNS
Moloni's guia de autorização de servidor descreve SPF e DKIM e afirma que seus serviços técnicos realizam verificação prévia. Publica endereços IP de envio explícitos e um exemplo DKIM TXT para um seletor sob o domínio do cliente. Também orienta os usuários de serviços como Office 365 ou G Suite a entrar em contato com seus serviços técnicos antes de fazer alterações. Preserve esse requisito de coordenação específico do produto em vez de tratar a página como uma autorização incondicional de copiar e colar.
A página retida não estabelece que sua chave pública impressa e valores de IP sejam os valores corretos atuais para cada conta ou rota. Confirme a sua aplicabilidade antes da implementação. Não invente seletores gerados por contas, substitua materiais-chave existentes ou reutilize a inclusão de outro produto porque aparece em um guia de terceiros. O exemplo do artigo contém um sinalizador de teste DKIM ; não o remova ou reinterprete silenciosamente sem uma configuração atual revisada. A alteração real DNS deve usar o proprietário e o valor confirmados pelo provedor para a implantação pretendida.
Um valor DNS público não é uma chave de assinatura privada. Nunca peça a um administrador para colar uma chave privada nesta planilha ou em uma mensagem de suporte. O objetivo da revisão técnica é estabelecer qual autorização pública e consulta de chave o servidor receptor deve ver, quem controla o remetente correspondente e qual operador aprova a alteração. Essas decisões permanecem abertas até que os proprietários reais da conta e do domínio forneçam evidências.
Preservar uma política SPF coerente
O exemplo do guia Moloni adiciona autorização a um documento existente Registro SPF em vez de criar uma segunda política independente. Siga esse princípio estrutural ao analisar o conjunto real de remetentes legítimos. Não substitua a política da organização por um exemplo ilustrativo que omita a hospedagem de caixas de correio, outros aplicativos ou serviços transacionais aprovados. Por outro lado, evite reter para sempre uma autorização obsoleta apenas porque ela apareceu em um documento de migração.
RFC 7208 , seções 2.4, 3.2 e 4.6.4 governar o CORREIO DE identidade, vários registros SPF e limites de prazo dependentes de DNS avaliados. Avalie a identidade real do envelope usado pela rota Moloni selecionada em vez de assumir que o endereço do remetente visível é a identidade SPF . Os mecanismos de endereço literal e os mecanismos dependentes de DNS têm comportamentos de avaliação diferentes. Uma verificação de sintaxe válida é útil, mas não prova que a infraestrutura listada ainda seja o remetente autorizado correto para a conta.
Não repita as garantias de entrega da fonte como conclusões técnicas. A configuração de autenticação pode resolver um problema de autorização específico, mas os sistemas receptores ainda aplicam outras políticas. Uma política publicada corretamente não garante que uma fatura chegue à caixa de entrada, que o seu destinatário a leia ou que seja efetuado um pagamento. Esses resultados devem ser medidos separadamente das evidências SPF e DKIM .
Aplique o controle do remetente somente após seus pré-requisitos
A sequência documentada da interface do usuário é Configurações, Empresa, a guia E-mails e, em seguida, a configuração do remetente. O guia inclui um botão de confirmação denominado Confirmo que posso configurar o SPF antes de habilitar a opção, inserindo o endereço desejado e escolhendo Atualizar para salvar. Essa confirmação representa uma decisão pré-requisito; não deve ser tratado como um atalho que corrige automaticamente a configuração DNS .
Antes de salvar, compare o endereço pretendido com o domínio elegível e a configuração técnica aprovada. Registre a configuração anterior e reverta o proprietário. A interface atual e o direito exato da conta ainda precisam de confirmação porque um artigo de ajuda pública não expõe o locatário ativo. Uma alteração no remetente exibido pode afetar o reconhecimento do destinatário e o tratamento da resposta, portanto a aceitação deve incluir o caminho prático da correspondência sem alegar que o próprio roteamento da resposta prova a autenticação.
Valide a assinatura e o alinhamento com evidências seguras
Um exercício de aceitação proposto deve usar uma mensagem autorizada e inofensiva, e não uma fatura real ou detalhes financeiros do cliente. Retenha os diagnósticos mínimos de receptor confiável necessários para estabelecer a rota, o domínio do autor, a identidade do envelope, o domínio de assinatura e o seletor. RFC 6376 , seção 3.5 define os campos de assinatura relevantes. RFC 9989 , seção 4.4 explica o alinhamento relacionamento entre o domínio do autor visível e uma identidade de autenticação de passagem.
Uma verificação bem-sucedida do lado do provedor é uma prova dessa verificação, e não uma prova de que todas as categorias de mensagens assinam e se alinham. Distinguir um remetente Moloni padrão de um remetente de domínio personalizado no registro de aceitação. Se um teste usar o endereço padrão enquanto a produção usar o domínio da organização, ele não estabelecerá a prontidão do domínio personalizado. Nenhuma mensagem, consulta DNS , solicitação de suporte ou upload de diagnóstico externo foi realizada para este manuscrito.
Diagnóstico fictício: elegibilidade e DNS foram confundidos
Um atacadista fictício, Olive Harbor Supplies, habilita um remetente personalizado após presumir que seu acesso anterior ao recurso comprova a elegibilidade atual. O proprietário do DNS não revisou os valores técnicos e os alertas de estoque programados ainda precisam de um escopo de aceitação explícito. A equipe rotula a configuração como concluída porque o endereço fica visível na tela de configurações.
A correção proposta é separar a decisão de elegibilidade, a configuração técnica confirmada pelo provedor, o estado do remetente salvo e a evidência em nível de mensagem. O revisor mantém as categorias programadas abertas até que seu comportamento seja examinado por meio de um exercício autorizado. Este é um problema fictício de fluxo de trabalho, não uma alegação de que qualquer conta Moloni real falhou ou que o serviço do provedor não é confiável.
Planilha de aceitação em branco e limite de publicação
- Elegibilidade de produto, conta, plano e recurso confirmado: ______
- Remetente padrão ou personalizado e categorias de mensagens afetadas: ______
- Requisitos atuais SPF e DKIM confirmados pelo provedor: ______
- Office 365 ou outra coordenação de provedor, se aplicável: ______
- Proprietário oficial DNS , aprovação de alteração e valores anteriores: ______
- Revisão completa SPF e evidência de proprietário/valor da chave pública: ______
- Estado do remetente salvo, proprietário da reversão e revisão do caminho de resposta: ______
- Autenticação de mensagens confiáveis e resultados de alinhamento por categoria: ______
- Restantes exceções e decisão de liberação: ______
Evidências originais de implementação, aplicabilidade atual, revisão de assuntos humanos, rotas de produção, acessibilidade visual e liberação do proprietário permanecem em aberto. Este artigo com escopo de origem não certifica os valores históricos impressos de um locatário nem reivindica uma implantação de domínio personalizado bem-sucedida. O requisito mais amplo de implementação do catálogo permanece insatisfeito até que evidências operacionais autorizadas estejam disponíveis.